Re: service references (was: Re: WSA diffs from REST)

"Paul Prescod" <paul@prescod.net> writes:
> 
> Do you mean "port" or "part".

I meant "part."

> And if "part" then why not "element"? 
> Parts don't don't have minoccurs. They don't have maxoccurs. They can't 
> be mixed in with metadata about the reference.

Different discussion: Do we need <wsdl:message>? 

Please see the discussion in the last WS-Desc WG F2F and a set
of charts I presented about why it exists and what it does. We
have not made any definitive conclusion yet AFAIK but I don't
imagine we'll be replacing <message> with <complexType> or
<element>. Just my gut feeling.

In any case, let's move that discussion to WS-Desc - its
orthogonal to the service refs discussion.
 
> > BPEL4WS already introduces a version of service ref.
> 
> I'm trying to understand it. How would it handle the situation where I 
> have an interface like:
> 
> interface PurchaseOrder{
>     ...
> }
> 
> interface PurchaseOrderManager{
>      PurchaseOrderReference createNew(PurchaseOrder po);
>      boolean update(PurchaseOrder po)
>      boolean updateFromReference(PurchaseOrderReference po)
> }
> 
> What is the SOAP+WSDL+BPEL4WS representation?

In today's WSDL, the response message of createNew would have
a part which is of XSD type <xyz:ServiceReferenceType> where
that's the type we defined in the BPEL spec as what a service
ref looks like. 

If you want to make it more specific, subtype that thing to be
a service ref of type PurchaseOrderReference and then use that
XSD type as the type of the part.

On the wire it'll appear in the serialized form of a service
ref (again see the BPEL spec).

> This is an even more fundamental divergence from the Web model than 
> anything labelled REST or GET etc. And to boot, it is a divergence from 

Huh? I thought you were all hot-n-heavy saying WS is so broken
because this capability is not there! Now you're saying its so
not-RESTafaric because its there. 

Which way do you want it to be??

> all of the other models like OO, pub/sub, etc. You *do not know* all of 
> the services you need to talk to at design time, anymore than a Java 
> program has a list of the objects it is going to create at design time.

Nothing I said forces anyone to know the value of a service ref
at design time. You certainly need to know that it is an SR
at design time - same as in Java.

> The problem has been evident since SOAP 1.0 and the first versions of 
> SOAP toolkits shipped. That was three (!) years ago.

Its because the layer that really needs it is business process
orchestration or service composition. That stuff is just maturing
now IMO. Maybe we're not smart enough to predict everything
needed right at the beginning, but at least the SOAP/WSDL etc.
creators were creative enough to not preclude them.

> For more than a year I've been agitating and getting very little 
> traction (most often to responses of: "Why do we need that?"). My 
> observation is that it has taken some "tone" to get people thinking. 

OK, understood.

> Better I use tone now then wait around and have the TAG mandate a deep 
> rewrite of WSDL later.

:-) 

I personally don't take the TAG as controlling authority to that extent.
If they do that, we should spank the TAGsters amongst us for not 
keeping is abreast enough of fundamental flaws that we're just too
damn dumb to get; where's DaveO?

But that's just me.

> Furthermore, this is a major architectural shift which will impact all 
> of the other specifications and literally hundreds of SOAP tools. It 
> would be better to address it sooner rather than later.

Agreed. And as Anne said in a separate note, some SOAP toolkits,
notably WASP, has supported this for quite a while. I'm in no way
claiming that BPEL was the first!

So what we really need is a standard form of SRs and WSDL support
for them. Now's the time to do it.

> Let's continue with the analogy of Java. If Java version 1 only allowed 
> references to classes and static methods and Java version 2 added the 
> concept of object instances, would you say that's a "simple feature"? It 
> seems rather major to me.

Again, its not impossible with SOAP/WSDL as they stand today (WASP
and BPEL are proof of that). What's missing is an interoperable way
to do it .. and we're getting there finally (hopefully).

Note: I'm not speaking for the WSDL WG in any of this stuff. So if
I said the WSDL WG may do something that's pure wishful thinking
on my part.

Sanjiva.

Received on Monday, 23 September 2002 22:46:04 UTC