MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec0.43]createEntity/createTemplate/createPortlet
As an aside to this discussion, could people please delete the individuals
when repling to these emails. Since we all subscribe to the mailing
list(s), it just makes for yet one more copy of each email in the inbox.
Thanks.
The suggestion I had made relative to "Heterogeneous vs Homogeneous"
services was to exploit the power of URL pattern matching that AppServers
supply to reduce these issues to the container always getting the network
invocations, but then using the remaining path information to disambiguate
which hosted object the invocation should be routed to (along wth whatever
other processing was appropriate). While this is clearly doable in a
servlet environment, the 2 other dominate environments that would need to
enable this are Axis (basis of many Java web service stacks) and .Net. I
have explored the Axis environment and can report that this pattern
matching is not available, but rather the match (after the AppServer match
to the Axis servlet pattern) is directly to the name of the deployed
service. As such, here is a suggestion starting with the issue needing to
be addressed through how things could get created in an explicit manner.
Issue:
There are scenarios (Portal sharing the portlets it hosts is one) where
the useful service to deploy is effectively a container for the
'thingys' that a Consumer may request output from. The degenerate case
is when there is exactly one 'thingy' at this service endpoint and
therefore there is no container.
Much of the discussion (in particular the wsxl & iws contributions) are
focussed on this degenerate case as the perspective was that WSDL service
endpoints would be used to disambiguate between the 'thingys' regardless of
whether they were locally deployed in some container or not. I think WSRP
has brought in several scenarios that are quite difficult to manage unless
one explicitly introduces a container-level concept into the architecture.
Proposal:
1. Once there are multiple types of thingys available at a service
endpoint, the ability to distinguish between them is critical. I would
propose calling each thingy a "transient entity". It represents the
thing that will generate output and process actions according to its
internal application logic. In general this is a stateful thingy such
that all calls to getOutput while it is in a particular state will
return the same markup while any change in state may result in a change
in the generated markup.
2. It is useful to support persisting a transient entity such that the
persistable subset of the current state may be reused when creating
transient entities in the future. I suggest calling this a "persistent
entity".
3. While 1&2 are Producer oriented, there is also value to transient
data that is most cleanly associated with the User. I propose calling
this a "session". I think it is important that the spec scope these to
the WSDL service endpoint, though we should include simple features (if
possible) that would allow a Consumer to mediate larger scopes. This
would allow a container oriented service endpoint great flexibility in
how sessions are shared by the entities it hosts.
If we have all 3 of these, the next question is what are the relationships
between them:
Sessions -> Entities:
A common usage will be that a session is directly related to exactly
one transient entity which may in turn be directly related to exactly
one persistent entity. This breaks down for sessions shared by
multiple entities at the service endpoint as there is now a 1:N
relationship. This leads me to propose carring the session reference
separate from any entity reference in the interface.
Entities -> Entities
For me this breaks down into 2 questions:
1. Is a transient entity required to get output from a Producer?
Deciding yes may simplify Consumer coding (either implicit or
explicit lifecycle of a transient entity will always be involved),
but may be an arbitrary requirement on the Producer.
2. Are all 4 possible relationships interesting?
a. Persistent from Transient: This seems like a fundamental way to
persist state.
b. Persistent from Persistent: This would allow creating a new
persistent entity by sending deltas from an existing one. The
relationship between the entities could be either by reference
(long-lived) or by value (effectively a clone +delta operation).
Are both interesting? Would the Consumer be able to either read or
control betweenthem?
c. Transient from Persistent: This seems like the means to use
persistent state as a starting point for a set of interactions
that might be quite independent of the persistent state once
initialized.
d. Transient from Transient: Like case b, this is a copy though I
would think the by reference value is dramtically reduced when
dealing with transient entities.
The other issue this design raises is how to carry the disambiguation of
the entities available at the service endpoint. I would prefer to see this
as an explicit parameter in the interface.
Given the above, the minimum create oriented calls would appear to be (we
would still need to discuss whether other parameters are required):
entityHandle createEntity(bPersistent, entityHandle, entityType,
updateValues)
bPersistent - a boolean to indicate whether this is a persistent or
transient entity
entityHandle - reference to an entity to use as a base
entityType - if no handle is supplied, this identifies the base thing
the service endpoint should use
updateValues - opportunity to provide a delta to any values implied
by the handle/type parameters.
sessionID createSession(entityHandle, updateValues)
entityHandle - entity this session is related to (should this be a
list?)
updateValues - opportunity to set values for use within the session
Sorry about the length of this (& the raising of multiple issues in one
email), but I'm just trying to propose an alternative given that the URL
pattern matching when exposing independent service points for a Producer
deployed hierachy isn't going to work on todays infrastructure.
Eilon Reshef
<eilon.reshef@webc To: "'Michael Freedman'" <Michael.Freedman@oracle.com>, "'Gil
ollage.com> Tayar'" <Gil.Tayar@webcollage.com>
cc: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org
05/23/2002 06:35 Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec
PM 0.43]createEntity/createTemplate/createPortlet
Mike,
Per the tension you mentioned, and your previous e-mail with the
"Container" interfaces (C1-C4).
This is a question that Rich referred to as "Heterogeneous versus
Homogeneous" services. The question is whether the "container" behavior
should be an explicit part of the interface (as you suggested in C1-C4
= "heterogeneous") or can be implicit in the interface by providing
different "services" (in the WSDL sense), each representing a separate
portlet type (= "homogeneous").
Why do you feel that WSRP needs the heterogeneous service? Couldn't a
single container/server provide different services for different portlet
types, and use WSDL techniques (mainly, URL paths) to differentiate between
the different portlets?
Eilon