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

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

William,

1) why is it that [Just looking for a specific property or operation is not enough] for WSDM consumers?
2) [So what consumer will be most looking for, is the list of "atomic" portTypes that are available] isn't that equivalent to lookning for message exchanges and may be properties?
3) [WSDM states that the way you know that a resource is a manageable resource is that it implements the muws:Identity portType.] And in that "portType" there is only one mandatory property <muws-xs:ResourceID>. Would it not be simpler to merely look for that property instead of looking for the "atomic" portType and fetch all the portTypes along the way. Would it not solve the problem that you're describing below, William?


-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: Vambenepe, William N [mailto:vbp@hp.com] 
Sent: Thursday, September 23, 2004 8:16 PM
To: Tom Maguire
Cc: wsrf@lists.oasis-open.org
Subject: RE: [wsrf] Groups - DerivedFrom portType extension.doc uploaded


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