Views on Web services architecture

Hi,
 
Rather than continue to respond to various email postings, I thought I'd try to summarize my views and ask others to respond (if anyone wants to, of course!).
 
I'd like any program to be able to call a Web service, and any Web service to be able to call any other program.  A service is not create, read, update or delete, although it could be.  Examples of services are:
 
-- Post a purchase Order
-- Debit a bank account
-- Start a transaction
-- Check an authorization
-- Schedule manufacturing run
-- Clear a stock trade
-- Get the next process flow step
-- Transform a document
 
The architecture should not constrain a service to be generic or require that it be specific.  The architecture should be defined at a level of abstraction sufficient for integrating any executable program (therefore we might suggest that the architecture does not include the execution of Web services, but simply sufficient representation of them to be executable on any software), and to allow data to be carried over any transport. 
 
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. 
 
Web services are not RPCs, at least not in the classic sense.  Anyone who thinks so either hasn't read the specs or doesn't think of RPCs in terms of DCE, IIOP, DCOM, or RMI.  Web services are joined using asynchronous, one-way messages.  Two or more messages may be placed into relationship to emulate an RPC, much the way RPCs were emulated over LU6.2 for the CICS DPL or over ATMI for the Tuxedo request/response API.  
 
Services are fundamentally interfaces to which a message is sent, and, optionally, from which a message is returned. 
 
Web services are consistent with established service-oriented architectural principles represented in products such as MQ Series, Orbix, Tuxedo, and TOP END.  Web services messaging uses XML, which provides an independent data format that can be used as a standard canonical model for adapting to any software domain or application.  Web services are therefore much more like EAI adapters than RPCs -- they receive messages in a canonical or standard format and map them into underlying executable programs and applications.
 
Web services applications can be composed of custom-built Web services and off-the-shelf Web services that provide standard functions such as transaction coordination, authentication/authorization, data transformation, process flow, and so on. 
 
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.
 
HTTP is but one of multiple potential "transports" for Web services, which are essentially XML messages constructed according to certain conventions and formats defined in the SOAP and WSDL specifications.  The same message can be carried over message oriented middleware systems, object request broker systems, or proprietary transports, as long as the service name, data, and associated semantic information (defining how to process the message) is accessible.
 
The Web services architecture should therefore include a definition of such items as "service," "message," "operation," and show how multiple services can collaborate or be combined to create "composite" applications.
 
A big issue is how to define associated functions and features that often are tightly coupled with transports and protocols, such as transactions, security, and session context. 
 
Eric
 
 
 
 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />


 <http://www.iona.com/> IONA Logo

Eric  <mailto:eric.newcomer@iona.com> Newcomer
CTO 


END 2 ANYWHERE

200 West Street 
Waltham, MA 02451
USA

Tel (781) 902-8366 
Fax (781) 902-8009 
 <mailto:Eric.Newcomer@iona.com> Eric.Newcomer@iona.com