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

Good example. The question is, what form will PurchaseOrderReference take.

1) A URL. A purchase order is a service with associated operations that you
can perform on it, the URL of that service is known and you can pass it
around. Here is where you want strong typing of the port being passed.

Just saying it's a URI is not enough - what operations can you do about it?
You want to be able to say it's a port that implements a particular portType
(or service type) so you know which operations you can perform on this
service.

You could pass a service definition (e.g. element of type wsdl:service) but
that would allow run-time type checking not design-time type checking.

One caveat. If I decide to move my service from http://host1.com to
http://host2.com tomorrow and you keep track of URIs pointing to the
purchase order, you will have to change all these URIs. It takes changing
one line in a configuration file to make the application point to a
different service, I'm not sure changing URI references to objects, if these
are stored in a database, is that trivial.


2) A URI. Maybe there are no operations accessible on the purchase order, it
is not a service just a record, but it's still an object. You're not passing
a service reference, because these is no service, and in all the examples of
passing purchase orders back and forth that I've seen, there is indeed no
service. It's an entity that you can create, change, cancel and query
through operations that are defined not on the entity itself, but on related
services.

Since the URI is not associated with a service per se, there is no need to
change the URI when the service's address is changed. You still can't use
XML Schema to indicate what type of URI it is, though.


3) A typed identifier. If it's not a service reference, maybe we should not
be using a URI. How about a simple type to represent a purchase order
number, e.g. pom:poNumber. The element type or simple/complex type tells you
exactly what you are dealing with. You can also express how that information
is contained in a message using something like a selector (see WSCI).


I'm not contradicting the need to be able to pass service references. I
think this is essential for complex Web service interactions. And I'm in
full agreement with you that service references need to be typed. Not just
xsd:anyURI, but a way to indicate what kind of operations are supported on
that URI, what service type it is expected to represent.

But I'm also indicating that one should not discard the two type of
references that exist. The service itself, and the entity managed by the
service, in the latter case the identifier is disjoint from the address of
the service and is represented by some business friendly identifier.

Those of us who have used CORBA for years might bulk at the idea. But it's
not new. It's common practice when developing database applications, it's
prevalent in component servers such as EJB and MTS.


When creating the WSCI specification we realized the need to support both
references to services (locators), means to express how identifiers (and
other properties) are expressed in WSDL messages (selectors), and means to
indicate what entity an operation refers to (correlation).

Most commonly these are used when defining sequencing rules between two Web
services (choreography), and so a lot of text is written on how they could
be used to establish what is commonly referred to as a conversation. But
unlike other attempts at supporting conversations that are intended to
achieve one goal, we have realized that selectors and correlations may be
used independently of choreography interface. That is why we have defined
them as a separate layer.

I firmly believe that the Web services community is better served if these
(or equivalent) mechanisms for service referencing and entity referencing
become part of the base service description language. I would have liked to
see that happen in WSDL 1.2, though I assume that is out of scope. That way,
we could leverage these two mechanisms in choreography and orchestration
languages, such as BPML, BPEL4WS or other BP-<insert your own acronym here>.

regards,
arkin


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?

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
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.

>...
> I'm surprised your article takes the tone that the people doing
> WS stuff are so dumb as to not want or understand the need for
> certain functionality.

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

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.
Better I use tone now then wait around and have the TAG mandate a deep
rewrite of WSDL later.

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.

 > This is just a simple feature and a
 > solution to half of it was already published in the BPEL spec.
 > The rest will come too - soon.

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.

  Paul Prescod

Received on Monday, 23 September 2002 20:29:15 UTC