a further concern is related to a more
general problem. What happens if I need to find a service that has
all of the following 3 operations (with the right combination of input,
output and fault) and these 7 properties? A QName of a portType is
a much nicer way to express this search then a series of anded expressions.
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
"Vambenepe, William
N" <>
09/24/2004 02:22 PM
To
"Sedukhin, Igor S"
<>, Tom Maguire/Hawthorne/IBM@IBMUS
cc
<>
Subject
RE: [wsrf] Groups - DerivedFrom
portType extension.doc uploaded
Hi Igor,
This would all be true if we had a guarantee of unique message names per
operation. But we don't, however one feels about whether this is a bug
or a feature. When I see an operation called "foo" that has input
and
output messages that happen to match those of the "foo" operation
in
portType William:MyPortType, I still don't know whether the service
supports portType William:MyPortType. There could very well be a
Igor:MyOtherPortType portType that has a "foo" operations with
these
exact same input and output messages and yet is a whole different
operation. This is the very reason why we have issue #1. We need to have
the Qname of the portType to know what operation this is.
William
-----Original Message-----
From: Sedukhin, Igor S [mailto:]
Sent: Friday, September 24, 2004 9:12 AM
To: Vambenepe, William N; Tom Maguire
Cc:
Subject: RE: [wsrf] Groups - DerivedFrom portType extension.doc uploaded
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 .. ()
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
-----Original Message-----
From: Vambenepe, William N [mailto:]
Sent: Thursday, September 23, 2004 8:16 PM
To: Tom Maguire
Cc:
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:]
Sent: Wednesday, September 22, 2004 11:06 PM
To: Vambenepe, William N
Cc: Steve Graham;
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" <> 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: [mailto:]
> Sent: Tuesday, September 07, 2004 7:16 AM
> To:
> Subject: [wsrf] Groups - DerivedFrom portType extension.doc uploaded
>
> The document DerivedFrom portType extension.doc has been submitted
by
> Stephen Graham () 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.
>
>
