Title: Message
Can you elaborate on how you see the difference between (3) and (4) in
the definitions below?
-----Original Message-----
From: Shankar
Ramaswamy [mailto:]
Sent: Monday, July 29, 2002
11:54 AM
To: ;
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
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>
