It seems to me that either approach will scare a few
more people away from WSRF. Just looking at the debate of the tradeoffs and
benefits between the two.
Would it not be reasonable to go for same
old "look at the message exchange signatures & property
document schema"?
What kind of simplicity/enhancements are we trying to gain?
The code to implement/obide by all those rules and make sure it does not break
anything will eat all of the imagined benefits. Think about implementing this on
a phone running Symbian...
-- Igor
Sedukhin .. ()
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
From: Steve Graham [mailto:]
Sent: Tuesday, September 28, 2004 7:29 AM
To: Vambenepe,
William N
Cc: Sedukhin, Igor S; Tom Maguire;
Subject: RE: [wsrf] Groups - DerivedFrom
portType extension.doc uploaded
William:
In this debate between the "just the derived set" vs
"entire transitive closure", it boils down (to me at least) to a trade
off.
With the transitive closure you
suggest, there is more work for the designer to do but more search
expressiveness.
With the derived
set, there is better affinity with WSDL 2.0 @extends (not perfect fit, but
similar role) and the requirement that additional registry search must be built.
The sort of "extended" search
we are talking about seems to make sense to be concentrated in some sort of
registry function, which could itself traverse the derived set to form the
transitive closure.
Are there other
important points for or against either approach?
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On
Demand Architecture
Member, IBM Academy of Technology
<Soli Deo
Gloria/>
++++++++
"Vambenepe, William N"
<>
09/27/2004 09:03 PM
To
Steve
Graham/Raleigh/IBM@IBMUS
cc
"Sedukhin, Igor S"
<>, Tom Maguire/Hawthorne/IBM@IBMUS,
<>
Subject
RE: [wsrf] Groups -
DerivedFrom portType extension.doc
uploaded
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.
>
>
