Browse Prior Art Database

System for Service Level Identification in a Client/Server WWW/Java Environment

IP.com Disclosure Number: IPCOM000123288D
Original Publication Date: 1998-Aug-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 4 page(s) / 200K

Publishing Venue

IBM

Related People

Fisher, BA: AUTHOR [+3]

Abstract

Disclosed is a system that describes a service level model in a client/server World Wide Web (WWW)/Java environment that will provide service level information for product components.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 29% of the total text.

System for Service Level Identification in a Client/Server WWW/Java
Environment

   Disclosed is a system that describes a service level
model in a client/server World Wide Web (WWW)/Java environment that
will provide service level information for product components.

   Problem Description: Web-based Java products ship with
many different components to them; Java code, Hypertext Markup
Language (HTML), server native code, supporting products, etc.  Each
of the product components either has no way to provide a service
level, or has it's own method for providing a service level.  As new
product releases and fixes are delivered to customers, it will become
increasingly difficult for service personnel to work on field
problems without being able to detect the service level of the
different product components.  It quickly becomes necessary to
provide a scheme for maintaining a service level for product
components and a mechanism to determine the service level of the
product components.

   Products also generally ship a full replacement version
of the product to provide service/updates.  This gets quite costly
and lengthy, when you consider the distribution mechanisms.  Cutting
CD's or disks and mailing is costly.  The preferred method is to
download the necessary fixes from the WWW.  Putting a whole product
on the WWW for an administrator to download is time consuming.  A
better solution would be to provide more granular fix packages which
contain only the product components that have changed.

   Assumption 1: It is anticipated that the service model
that will be used is similar to the following:
  Original Install/                          CSD1
  _______________________________________________
  Upgrade (FPR)    Fix1  Fix2  Fix3        (FPR)     Fix1  Fix2
  _____________________________________________________________
       t0           t1    t2    t3           t4       t5    t6
  time ---->
  FPR = Full Product Replace (all product components)

   An original install or version upgrade will be a full
product replace.  CSD's will also be a full product replace.  Any
intermediate fixes provided (Fix{n}) will only contain the
components that needs service.  As an example, after an original
install of a product, a problem is found in component {x} and
component {y}.  The fix is put out as Fix1 and contains only the
parts of component {x} and component {y}.

   At some time later, a problem is found in component
{z}.  The fix is put out as Fix2, which contains only the parts of
the {z} component, as well as the contents of Fix1.  And so on until
the next full product replace, either a CSD or upgrade.  Therefore
each fix will also include all previous fixes and includes only the
components affected.

   The goal is to be able to provide intermediate fixes to
customers without them having to get a full product replacement.

   Assumption...