[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
Eilon, 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. Regards, shankar ____________________________________________________ Shankar Ramaswamy, PhD shankar4@us.ibm.com Senior Software Engineer (919) 254-1072/TL 444 WebSphere Portal fax: (919) 486-0872 Eilon Reshef <eilon.reshef@webc To: Shankar Ramaswamy/Pittsburgh/IBM@IBMUS, wsrp-interfaces@lists.oasis-open.org, ollage.com> wsia@lists.oasis-open.org cc: 07/29/2002 01:25 Subject: RE: [wsrp-interfaces] [wsia][wsia-wsrp joint interfaces] Some ideas PM 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 ideas 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