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: [wsia][wsia-wsrp joint interfaces] Some ideas



All,

In reading my previous note again - I feel I rambled on quite a bit and
might have unneccessarily
confused a lot of you for no reason whatsoever and I apologize for this. I
should have clearly said
that what I posted was my own attempt to digest Draft 0.22 in terms of the
requirements picture I
have developed in my mind over these past few months (read my "Definitions"
and "Typical Lifecycle"
as this) and was only making a couple of minor suggestions to try to bring
WSIA/WSRP together.

I also realize I was most ungracious not congratulating everyone who has
worked on Draft 0.22 - the
interfaces have become remarkably clean and simple since we started on this
process.

Regards,

shankar

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


                                                                                                                                         
                      Shankar                                                                                                            
                      Ramaswamy/Pittsburg        To:       wsrp-interfaces@lists.oasis-open.org, wsia@lists.oasis-open.org               
                      h/IBM@IBMUS                cc:                                                                                     
                                                 Subject:  [wsrp-interfaces] [wsia][wsia-wsrp joint interfaces] Some ideas               
                      07/29/2002 11:54 AM                                                                                                
                                                                                                                                         
                                                                                                                                         



In the paragraphs below, I have tried to summarize my understanding of
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 was
absent.

Definitions:

1. Service: represents one or more logical functions.
2. Entity: represents a single logical function within a service. Every
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 to
first use of the entity, but could be done at intermediate stages as well).
    Configuration may need to be done each time the consumer connects to
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 entity
implementation in order to work correctly ? the consumer has a
    responsibility to co-operate with the producer in this regard; the
degree of responsibility can vary as described below. The producer entity
    is responsible for creating and maintaining the state. Depending on the
type of state (types listed below), if required, the producer may also
    elect to store the state. If the producer does not do so, this poses
additional responsibilities on the consumer. Also, note that the state
itself
    can be completely opaque to the consumer or alternately, the producer
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 producer
that is independent of any specific producer entity and has to do with
    issues like security, user agent characteristics, device
characteristics, user identity, etc.
7. Property: a name, type, value triplet. All information shared between
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 used
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, but
should be easy to figure that out.

API:

      1. Connecting to a service: draft 0.22 does a good job.
      2. Connecting to and configuring an entity: draft 0.22 does a good
job except:
            a. It has nothing for discovering entities ? should we have
something for this or postpone for post 1.0 ?
            b. It does not have the notion of a defaultEntity ? this would
be very useful for services with a single entity. Consumers can
                simply ask for the defaultEntity without doing anything
else.
      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 state
bucket, but there may be other session related properties in the bucket
that a
                producer could expose to allow for adaptation. The nice
thing is that the producer can select any buckets for exposing
                            properties, allowing for various types of
adaptations.
            c. We can also have an extensible set of buckets ? the standard
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 instead
replace it with requestContext ? i.e. the producer may modify the
                requestContext when processing an interaction. This way,
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 include
it in the requestContext and make the consumer responsible for storage.

Regards,

shankar

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



----------------------------------------------------------------
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