OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [wsrp-interfaces] [wsia][wsia-wsrp joint interfaces] Some ideas


For configuration, I view there being a separate step for doing the
customization. For instance, in the 0.22 draft,
I envision setting properties on the entityContext to be act of configuring
the entity. As an example, a consumer
may configure a stock quote producer to display a quote for a specific
ticker - say IBM using the Reuter's service
may always ask for an IBM quote.

For adaptation (or what we've been calling Customization - we can reject
this change if it causes more confusion
instead of less), I view it as being customization during the use of the
service. In the 0.22 draft with the changes I
proposed, I envision setting properties on one or more property buckets in
the requestContext to be the act of
adapting the entity. As an example, a consumer may provide a number of
stocks and purchase price to the
stock quote producer to get an additional "gain/loss" column with the quote
- say IBM providing information
about an employee's stock options and strike price to show them how much
they're making on their options.
This can be done for instance, via additional properties in the Action
state property bucket of the requestContext.
The producer would specify the names for these properties and the consumer
would create and set the
appropriate values in the requestContext before invoking getMarkup.

I hope I'm being clear.



Shankar Ramaswamy, PhD                       shankar4@us.ibm.com
Senior Software Engineer                          (919) 254-1072/TL 444
WebSphere Portal                                           fax: (919)

                      Eilon Reshef                                                                                                      
                      <eilon.reshef@webc        To:       Shankar Ramaswamy/Pittsburgh/IBM@IBMUS, wsrp-interfaces@lists.oasis-open.org, 
                      ollage.com>                wsia@lists.oasis-open.org                                                              
                      07/29/2002 01:25          Subject:  RE: [wsrp-interfaces] [wsia][wsia-wsrp joint interfaces] Some ideas           

Can you elaborate on how you see the difference between (3) and (4) in the
definitions below?
      -----Original Message-----
      From: Shankar Ramaswamy [mailto:shankar4@us.ibm.com]
      Sent: Monday, July 29, 2002 11:54 AM
      To: wsrp-interfaces@lists.oasis-open.org; wsia@lists.oasis-open.org
      Subject: [wsrp-interfaces] [wsia][wsia-wsrp joint interfaces] Some

      In the paragraphs below, I have tried to summarize my understanding
      where we are with respect to the Joint interface
      and have made some suggestions for modifying draft 0.22 to better
      meet the
      requirements. Forgive my ignorance if some
      of what I'm proposing has already been discussed in a forum where I


      1. Service: represents one or more logical functions.
      2. Entity: represents a single logical function within a service.
      service has at least one entity.
      3. Configuration: is one process by which the consumer customizes the

      behavior of an entity. Configuration is performed via a distinct
          step separate from    the normal use of the entity (usually prior
      first use of the entity, but could be done at intermediate stages as
          Configuration may need to be done each time the consumer connects
      the producer service and uses the entity or alternately, the
          producer service can permanently remember the configured entity.
      4. Adaptation (I thought I'd propose this new term as opposed to the
      current use of customization because configuration is also a type of
          customization): is another process by which the consumer
      customizes the
      behavior of an entity. Adaptation involves customization by the
          consumer that is integrated with normal use of the entity.
      5. State: this is information specific to and required by a producer
      implementation in order to work correctly ? the consumer has a
          responsibility to co-operate with the producer in this regard;
      degree of responsibility can vary as described below. The producer
          is responsible for creating and maintaining the state. Depending
      on the
      type of state (types listed below), if required, the producer may
          elect to store the state. If the producer does not do so, this
      additional responsibilities on the consumer. Also, note that the
          can be completely opaque to the consumer or alternately, the
      may elect to describe some of it to allow the consumer to manipulate
          the state for Adaptation purposes. The categories of state are
      (following Mike Freedman's classification):
            a. Navigational state
            b. Session state
            c. Action state
            d. Request state
      6. Context: this is information supplied by the consumer to the
      that is independent of any specific producer entity and has to do
          issues like security, user agent characteristics, device
      characteristics, user identity, etc.
      7. Property: a name, type, value triplet. All information shared
      consumer and producer is via lists of such properties.

      Typical lifecycle:

      1. Consumer finds one or more producer services via UDDI or other
      means. At
      this stage, consumer could also discover the set of entities offered
          by the service or it could come at a later stage. (Could be
      skipped if
      consumer has previously connected).
      2. Consumer connects to service.
      3. Consumer discovers the set of entities offered by a service.
      (Could be
      skipped if consumer already knows about entities from Step 1 or a
          previous connection)
      4. Consumer connects to one or more entities.
      5. Consumer configures the entities. (Could be skipped if consumer
      persistent handles from a previous connection in Step 4)
      6. Consumer uses the entities, adapting their behavior if desired.

            There is some disconnect/destroy type stuff which is missing,
      should be easy to figure that out.


            1. Connecting to a service: draft 0.22 does a good job.
            2. Connecting to and configuring an entity: draft 0.22 does a
      job except:
                  a. It has nothing for discovering entities ? should we
      something for this or postpone for post 1.0 ?
                  b. It does not have the notion of a defaultEntity ? this
      be very useful for services with a single entity. Consumers can
                      simply ask for the defaultEntity without doing
            3. Using and adapting the entities: draft 0.22 seems a bit
      complicated. I propose the following:
                  a. Let requestContext be hierarchically structured into
      buckets, for example:
                        i. Navigational state
                        ii. Session state
                        iii. Action state
                        iv. Request state
                        v. Security context
                        vi. User agent identity
                        vii. User identity
                        viii. Device identity
                        ix. etc.
                  b. Each bucket above would have its own set of
      properties. For
      some buckets, the set of allowable properties could be
                      standardized across services ? for example, for
      things like
      security and user identity. For other buckets, some properties
                      could be standardized while others can be producer
      service/entity specific. For example, we may have a standard property

                                  called "session_handle" in the session
      bucket, but there may be other session related properties in the
      that a
                      producer could expose to allow for adaptation. The
      thing is that the producer can select any buckets for exposing
                                  properties, allowing for various types of

                  c. We can also have an extensible set of buckets ? the
      can specify a set (which itself can evolve) as well as allow
                      producers to add their own buckets.
                  d. Let us do away with the interactionResponse and
      replace it with requestContext ? i.e. the producer may modify the
                      requestContext when processing an interaction. This
      the consumer can further modify it for adaptation purposes before
                                  calling getMarkup.
                  e. We can impose responsibilities on the consumer wrt the

      requestContext. This way, we can cover the cases when producer
                      does not want to store any information ? they can
      it in the requestContext and make the consumer responsible for



      Shankar Ramaswamy, PhD                       shankar4@us.ibm.com
      Senior Software Engineer                          (919) 254-1072/TL
      WebSphere Portal                                           fax: (919)


      To subscribe or unsubscribe from this elist use the subscription
      manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC