Steve,
Are you using the terms “implements”
and “is compatible with” interchangeably? The WSDL 2.0 semantics
as they stand are unclear with a WSDL 2.0 interface (a) that extends another
interface (b) is compatible with the extended interface. Imagine that b
contains a read operation, and a adds an open operation that must be called
before the read. In this scenario, a is not compatible with b yet it extends
b. Alternatively, a could add a “getStatus” operation so that a
client that only knows about b will work with implementations of a, thus a is “backwards”
compatible with b. In scenario 1, the b client MUST change to work with a. In
scenario 2, the b client MAY change to work with a.
FYI I will be proposing a WSDL 2.0 Last
Call issue and solution to address this discrepancy.
Cheers,
Dave
From: Steve Graham
[mailto:]
Sent: Tuesday, September 28, 2004
10:05 AM
To: Sedukhin, Igor S
Cc: Tom Maguire; Vambenepe,
William N;
Subject: RE: [wsrf] Groups -
DerivedFrom portType extension.doc uploaded
so instead of having a query that looks like:
"find
me a service that implements operation O1, O2, O3 and O4 with resource property
document tns:foo"
"we
have find me a service that is compatible with portType tns:p1"
The
latter is a simpler query and already takes advantage of the mechanism in WSDL
to group related operations.
Why
do we want to make discovery of the Web service with the needed interface more
difficult?
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
"Sedukhin, Igor S"
<>
09/28/2004 12:14 PM
To
Steve Graham/Raleigh/IBM@IBMUS,
"Vambenepe, William N" <>
cc
Tom Maguire/Hawthorne/IBM@IBMUS,
<>
Subject
RE: [wsrf] Groups - DerivedFrom portType
extension.doc uploaded
In, general, I do agree that some way to
mechanically identify group of semantics is quite useaful. In programming
languages that may be an interface name. However, in this particular case,
there is nothing that will coerse the machines or designers in breaking that
link quite simply. So, why not just base on hard facts: signatures of message
exchanges and property document schemas?
-- Igor Sedukhin
.. ()
-- (631) 342-4325 .. 1 CA
Plaza, Islandia, NY 11788
From: Steve
Graham [mailto:]
Sent: Friday, September 24, 2004 3: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.
>
>
