Hi Steve,
I assume you mean that these 3 operations and 7 properties
are not defined as part of the same "atomic" portType. Let's say they are
defined between two atomic portTypes, PT1 (which defines 2 of the
operations and 3 of the properties) and PT2 (which defines the 3rd operation and
the 4 other properties).
With my proposed approach (return the transitive
closure in "derivedFrom"), you'd look for a service that lists PT1 and PT2 in
the "derivedFrom" attribute of its portType. End of story.
Now with your approach. Let's say someone has defined
a portType PT3 that derives from PT1 and PT2. And let's say that you know about
PT3. You can look for PT3 in the "derivedFrom" attribute. But if you don't find
it, you still can't say that the service doesn't support the 3 operations and
the 7 properties. Because someone might have created a PT4 portType that derives
from PT1 and PT2 (and possibly some other portTypes). And since you don't know
PT4, seeing it in the "derivedFrom" attribute doesn't help you. So you now have
to retrieve the WSDL definition for PT4 and introspect it. And so on,
recursively, for all portTypes. Basically, you won't know for sure
that a given service doesn't support the 3 operations and 7 properties until
you've generated the transitive closure that I suggest to include in the
"derivedFrom" attribute to start with.
So I think your example illustrates the advantage of using
the transitive closure as I recommend.
Regards,
William
From: Steve Graham [mailto:]
Sent: Friday, September 24, 2004 12:05 PM
To: Vambenepe,
William N
Cc: Sedukhin, Igor S; Tom Maguire;
Subject: RE: [wsrf] Groups - DerivedFrom
portType extension.doc uploaded
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.
>
>
