RE: Views on Web services architecture

Mike,
 
If I had to characterize it, it would be the EAI view.  It's not really the CORBA view.  Although we also build service-oriented architectures using CORBA, they are typically RPC oriented, and synchronous.  The EAI view builds on asynchronous messaging, which I think is consistent with Web services (at least as they are currently specified), to add message routers, transformation services, and adapters.  EAI systems work by transforming inputs into a canonical message format that the adapters transform into outputs for ERP, CRM, technology domains (J2EE, RDBMS, CORBA) etc.   To me this is much more like current Web services technology, which relies on transformation from some client or input program into XML and at the destination or receiver of the message, relies on transformation into the output program format.  
 
I have no problem characterizing this as the traditional or non-REST view, I was definitely trying to summarize that view.  I also think you were correct in characterizing the crux of the discussion as between generic interfaces and specific interfaces, and where the burden of ensuring interoperability is placed.  I think reality says that we are not going to be living in a perfect EAI (or OMA) world, and not in a perfect REST world, either.
 
Specific responses inline.
 
Eric

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@softwareag-usa.com]
Sent: Monday, July 22, 2002 9:04 PM
To: www-ws-arch@w3.org
Subject: RE: Views on Web services architecture


 

-----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
Sent: Monday, July 22, 2002 3:24 PM
To: www-ws-arch@w3.org
Subject: Views on Web services architecture 
 

I find this a very illuminating statement of the "traditional" or non-REST  position.  Can we come up with a label for it?  OMA maybe ... or "distributed object?"  As Eric says, "RPC" is a red herring.   I'm going to use the label "OMA" here just as a placeholder for the general orientation toward web services that Eric describes,  but am not really happy with the label....

Services have a name, and data inputs and outputs.  The data is exchanged with the service in the form of a message, which might include fields and structures to be mapped into and out of procedure or method arguments.  The service-oriented architecture is recursive, or perhaps inclusive -- meaning that features and functions within the Web services architecture are exposed as Web services the same as those created by application developers.  

Just trying to see how much agreement on non-critical issues we might have... Would you accept "services have an identity" rather than a "name"?  Do you (Eric) have any problem with the notion that a web service identifier SHOULD be a URI?  
 
>> No problem, I agree the URI is the common identifier and should be used for a Web service name/ID.
 
Let me try a translation into language that's a bit more neutral with respect to REST vs OMA.  Does anyone have a problem with "a service is invoked by a message that identifies in detail the action to be taken and information to be transferred to the service?"  The "action" can be one of the CRUD operations, or it can be something more domain-specific such as "accept-order".  Again, I'm not asking Mark to agree that a non-CRUDdy/RESTful operation is a "good thing", just to see if we can come up with acceptably neutral language for the WSA document to describe what it is we're doing.  
 
In the same vein, how about "a service invocation may produce a message that is sent back to the originator containing the result of the requested operation." 

 
 Two or more messages may be placed into relationship to emulate an RPC, 

We're struggling with language to define "message exchange patterns" appropriately across WSA, SOAP, and WSDL, but I think we generally agree on the concept, and RPC is clearly one of the MEPs that web services can exhibit.  Are we all more or less on the same page here?  Again, I'm not seeking agreement on which MEP to use or not use, just on the notion that there is a web services architecture concept of MEP, and different MEPs are associated with different architectural styles.

 
 Web services are consistent with established service-oriented architectural principles represented in products such as MQ Series, Orbix, Tuxedo, and TOP END.   

Could you (Eric) elaborate on this, or give a reference?  Are these "service-oriented architectural principles" general to WSA broadly defined, or just to the style I'm calling "OMA", or both?
 
** These references are to existing (and prior) industry practice. I'd have to look it up, but it's possible that IMS also used this terminolgy, since Tuxedo is derived from IMS. In any case, you will also find a vendor such as TIBCO calling their product a "service oriented" architecture product.  It's based on a messaging bus with defined endpoints described using a proprietary equivalent of WSDL.

Programs or applications that receive Web services messages have associated semantic information that determines how the message is processed, including how it is mapped to the program or application, and what information, if any, is to be carried in a reply message. 
 

Is WSDL "associated semantic information?"  If not, where does this semantic information come from in today's world?
 
** Yes, I mean WSDL or the equivalent (i.e. a mutually agreed schema)