RE: [wsrf] Groups - DerivedFrom portType extension.doc uploaded

["Vambenepe, William N" <vbp@hp.com>]

Hi Tom,

Here is an example from WSDM to better illustrate why I am proposing
this approach:

WSDM defines a muws:operationalState portType with operations like
"start" and "stop". Someone could define a portType for management of an
app server, called foo:AppServerMgmtPT which derives from
muws:operationState (and a bunch of other portTypes). Then the Java guys
get together and define a management portType for a J2EE app server
called jsr845:J2EEContainerMgmtPT, which derives from
foo:appServerMgmtPT and other portTypes. And then BEA decides to create
a super tailored management portType for WebLogic called
bea:WebLogicMgmtPT which derives from jsr845:J2EEContainerMgmtPT and
adds a bunch of WebLogic-specific management capabilities.

Now think of the consumers on the other hand that have been developed to
understand and use the muws:operationalState portType and want to know
what they can do with this resource they just discovered that implements
jsr845:J2EEContainerMgmtPT. Your proposal forces them to create a whole
tree of portTypes that derive from one another, which implies in the
process that they have to retrieve the WSDL declarations for
jsr845:J2EEContainerMgmtPT and foo:AppServerMgmtPT (and all the other
portTypes derived from along the way that have nothing to do with
muws:operationalState but the consumer won't know that until they have
dereferenced and introspected everything). All this just to know what
was known at the time the portType was created, that
muws:operationalState is one the portTypes it is compatible with.

Because in practice, the real semantic will most often be attached to
"atomic" portTypes like muws:operationalState that define a set of
operations and properties and a lot of the portTypes that are generate
along the way to aggregate these atomic portType together define little
semantic of their own, they are just containers. So what consumer will
be most looking for, is the list of "atomic" portTypes that are
available. This is what will tell them what they can do with this
resource.

This is especially in WSDM because WSDM states that the way you know
that a resource is a manageable resource is that it implements the
muws:Identity portType. If I have to dereference and parse several WSDL
documents to find out whether a WSDL corresponds to a manageable
resource or not, you are making the discovery task in WSDM a lot harder
to perform. Just looking for a specific property or operation is not
enough, which is why we have this issue #1 that Steve's proposal
attempts to address.

So to me it comes down to a matter of who gets to do the work. It is
either done once, at design time when performance is not an issue, at
the time the portType is created. Or it is done at least once per
consumer (possibly more if the consumer can't cache the information), at
runtime where the cost is a lot higher. This seems like a clear
practical choice to me.

And don't get me started on the effect this has on versioning. If one of
the many portTypes is versioned, the approach I propose scopes the
impact of this to this portType alone. In your approach, all the other
portTypes that are derived form it have to change as well and people
have to introspect again the whole tree to find out what changed, even
though the capability they care about might not have changed at all.

Regards,

William

-----Original Message-----
From: Tom Maguire [mailto:tmaguire@us.ibm.com] 
Sent: Wednesday, September 22, 2004 11:06 PM
To: Vambenepe, William N
Cc: Steve Graham; wsrf@lists.oasis-open.org
Subject: RE: [wsrf] Groups - DerivedFrom portType extension.doc uploaded





-1 to the "complied-to" transitive closure

The process you describe for a consumer determining the transitive
closure of portTypes/interfaces is exactly the process that would be
used in WSDL2.0.  Further, it is not at all clear that every consumer
would need to do this; I can envision "registries" that would expose the
transitive closure of a portType's  "derivedFrom" attribute.
Additionally, I can think of no programming model paradigm that uses
such a "non-normalized" view of  "derivation" or "extension" in the
language itself.  In essence you are arguing for a restricted model that
only allows for a 2 level hierarchy.  I can think of no architectural
premise for such a restriction.

For me the question is what would become of the "derivedFrom" attribute
in a WSDL2.0 component model?

Tom


"Vambenepe, William N" <vbp@hp.com> wrote on 09/22/2004 08:12:34 PM:

>
> Hi Steve,
>
> Why not put in the "derivedFrom" attribute the Qnames of all the 
> portTypes with which this portType is compliant (i.e. the content of 
> the {extendedPortType} property that you define as the transitive 
> closure of all portTypes with which this portType is compliant).
>
> For example, if my program is written to know what to do with 
> implementations of the portType foo:bar, with your current proposal I 
> Can't just look at the Qname of a portType and at the Qnames in its 
> "derivedFrom" attribute to know whether or not I can invoke the
service.
> I need to retrieve the portType definition for each of the portTypes 
> in the "derivedFrom" attribute and recursively introspect what is in 
> their "derivedFrom" until I put together a list of "atomic" portTypes 
> (those that don't derive from anything). And this is true for every
consumer.
> We can simplify this task a lot by providing a complete list of 
> "complied-to" portTypes in "derivedFrom".
>
> Regards,
>
> William
>
>
> -----Original Message-----
> From: sggraham@us.ibm.com [mailto:sggraham@us.ibm.com]
> Sent: Tuesday, September 07, 2004 7:16 AM
> To: wsrf@lists.oasis-open.org
> Subject: [wsrf] Groups - DerivedFrom portType extension.doc uploaded
>
> The document DerivedFrom portType extension.doc has been submitted by 
> Stephen Graham (sggraham@us.ibm.com) to the OASIS Web Services 
> Resource Framework TC document repository.
>
> Document Description:
> Per Action Item I took on Aug 23 telecon, this document is a proposed 
> resolution to issue WSRF1.
>
> Download Document:
> http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/9079/De
> ri
> vedFrom%20portType%20extension.doc
>
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/wsrf/document.php?documen
> t_
> id=9079
>
>
> PLEASE NOTE:  If the above links do not work for you, your email 
> application may be breaking the link into two pieces.  You may be able

> to copy and paste the entire link address into the address field of 
> your web browser.
>
>