Network Working Group Rezaur Rahman
Internet-Draft Rama R. Menon
Expires: May 2002 Intel Corporation
Lee Rafalow
IBM Corporation
Enabling OPES to Use Web Service
for Callout Service
draft-rrahman-web-service-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The Open Pluggable Edge Services architecture (OPES) defines an open
standards based framework for providing services on intermediaries to
operate on client requests and server responses. One of the key
elements of this framework is the notion of callout services.
Currently proposed remote callout service implementations interact
with an OPES intermediary through specially designed callout
protocols like iCAP[11].
Web services are beginning to emerge as new way of providing services
on the Internet. Web Services provide standard methods of exposing
and using the services available to anyone interested in using them
through open standards like UDDI and WSDL. This document describes
how the OPES framework can make use of these standards in
implementing callout services.
Rezaur [Page 1]
Internet Draft Web Services as Callout Service November 2001
Table of Contents
Status of this Memo.................................................1
Abstract............................................................1
1. Introduction.....................................................3
1.1 Requirement Language............................................3
1.2 Relationship to other standards work............................3
2. Terminology......................................................4
3. Content Encapsulation............................................4
4. WebService URI Scheme............................................6
5. Security Considerations..........................................8
6. Intellectual Property............................................8
7. Acknowledgments..................................................8
8. References.......................................................8
9. Disclaimer.......................................................9
10. Author's Address................................................9
11. Full Copyright Statement.......................................10
Appendix A: Web Services Execution.................................11
Appendix B: Performance Issues.....................................16
Appendix C: Automated Service Invocation Rules.....................17
Rezaur Expires May 2002 [Page 2]
Internet Draft Web Services as Callout Service November 2001
1. Introduction
One of the core benefits provided by the Open Pluggable Edge Services
architecture is to allow a standard way for the content provider
and/or third parties to provide value added services to be performed
on the requests and responses going through the OPES intermediary.
Proposed solutions to deploy these services include developing call-
out services on a protocol like [11] or creating locally executed
proxylets to provide these services. Web Services are becoming the
prominent service infrastructure for the web, based on more publicly
accepted standards like SOAP, UDDI, WSDL etc.
Due to their openness the web services tools are becoming the
infrastructure of choice for publishing various services ranging from
language translation to temperature conversion to local airport
weather forecast; also, the number of these services are increasing
at an explosive rate. The use of these various web services is
limited only by the imagination of the clients and content/service
providers.
Since OPES is aiming at making the Edge Services Platform open and
easy to use, it makes sense to provide sufficient architectural
support in its framework to leverage the existing web services tools
to develop the services platform for OPES.
This draft outlines a method of using web services as a callout
service deployed in an OPES environment.
The appendix near the end of this draft provides implementation notes
on enabling OPES with web services.
1.1 Requirement Language
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to
be interpreted as described in RFC2119.
1.2 Relationship to other standards work
With the standardization of XML in World Wide Web Consortium (W3C)
there has been a flurry of development in the IT industry to provide
services for distributed applications using XML as the foundation.
These activities resulted in services based on web technologies that
are available to distributed applications and are known as web
services. A web service includes various components like service
description, discovery, registration, data transport etc. Recently
W3C has taken up the protocol activities like SOAP and trying to
develop the technologies that standardize the protocol used by the
web services. It is expected that more similar efforts will follow
from W3C and other standards organizations to standardize the web
services components.
Rezaur Expires May 2002 [Page 3]
Internet Draft Web Services as Callout Service November 2001
Since not all components needed to build web services are
standardized yet, it is expected that this draft will be modified in
future to use more and more of the standardized components of the web
services infrastructure.
2. Terminology
WSDL Proposed Web Services Description Language is an XML format
for describing network services [1].
UDDI Universal Description Discovery and Integration specification
provides a way to describe, discover and integrate services on the
Internet. [2]
SOAP - Simple Object Access Protocol is an XML based protocol for
exchange of information in decentralized, distributed environment.
[3]
tModel In the context of UDDI registry a tModel describes a service
interface definition [4]. It defines the abstract interface rather
than a specific implementation of the service.
tModelKey - Each tModel is given a unique identifier (uuid) known a
tModelKey.
3. Content Encapsulation
The services performed in the OPES framework will have to deal with
various types of entities in a data format other than XML like HTTP
header, body, images, etc. These SOAP packages MUST follow the
following SOAP packaging in order to provide efficient processing of
the contents.
In order to provide efficient access to non-XML content, the web
services SHOULD use SOAP with attachment [10] messages for non-XML
content type. In addition the encoding MAY provide offset and length
of each attachment in the SOAP message package÷.
Figure 3.1 below describes the XML schema we propose to enhance the
SOAP message access. With the help of the elements defined in this
schema, a SOAP message package÷ can be accessed randomly to improve
service operation. The Manifest÷ element in this schema MAY contain
any of the request, response header and body component information.
These tags make it easier for the web services to access the data
elements.
Rezaur Expires May 2002 [Page 4]
Internet Draft Web Services as Callout Service November 2001
OPES Manifest Schema
<schema
targetNamespace="http://www.opes-ietf.org/callout-webservices/"
xmlns:tgt="http://www.opes-ietf.org/callout-webservices/"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name=÷Manifest÷ >
<complexType>
<sequence>
<element name=÷reqhdr÷ type=÷tgt:infotype÷ minOccurs=0 />
<element name=÷reqbody÷ type=÷tgt:infotype÷ minOccurs=0/>
<element name=÷resphdr÷ type=÷tgt:infotype÷ minOccurs=0/>
<element name=÷respbody÷ type=÷tgt:infotype÷ minOccurs=0/>
</sequence>
</complexType>
</element>
<complexType name=infotype>
<complexContent>
<attribute name=÷href÷ type=÷string÷ use=÷required÷/>
<attribute name=÷offset÷ type=÷unsignedLong÷
use=÷required÷/>
<attribute name=÷length÷ type=÷unsignedLong÷
use=÷required÷/>
</complexContent>
</complexType>
</schema>
Fig 3.1.
Example 3.1 below shows an HTTP message containing SOAP message
package including attachment. The SOAP body also contains the
Manifest÷ element described above to provide direct access to the
SOAP attachment components. In this example the namespace prefix
onsË is tied to an OPES defined target namespace. reqhdr÷ and
reqbody÷ elements in this namespace provide the means to specify the
offset and length of request header and request body components from
the end tag of the SOAP envelope.
POST /bookOrder HTTP/1.1
Host:www.bookstore.com
Content-type:Multipart/Related;Boundary=MIME-Boundary;type=text/xml;
Start=÷<bookOrder-start-id>÷
Content-length: xyz
SOAPAction: http://schemas.bookstore.com/newbook
Rezaur Expires May 2002 [Page 5]
Internet Draft Web Services as Callout Service November 2001
--MIME-Boundary
Content-type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <bookOrder-start-id>
<?xml version=Ë1.0Ë>
<SOAP-ENV:Envelope
xmlns:SOAP_ENV=Ëhttp://www.w3.org/2001/09/soap-envelopeË>
<SOAP-ENV:Body>
<ws:puchase xmlns:ws=Ëhttp://www.bookstore.com/byuschema÷>
<ons:Manifest xmlns:ons=Ëhttp://www.opes-ietf.org/callout-
webservices/Ë>
<ons:reqhdr href=÷cid:reqhdr0123÷ offset=0 length=64 />
<ons:reqbody href=÷cid:reqbdy234÷ offset=76 length=1024
/>
</ons:Manifest>
</ws:purchase>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
--MIME-Boundary
:
Content-ID: <reqhdr0123>
:
req-header entries
:
:
--MIME-Boundary
:
Content-ID: <reqbody234>
:
req-body
--MIME-Boundary
Example 3.1.
4. WebService URI Scheme
For the proxylet based web services (Appendix A) the rule description
SHOULD follow standard proxylet URI scheme defined in [7].
The support for the Web Services execution through discovery requires
a way to tie a rule to a specific web service. A new URI naming
convention is defined for this purpose. This follows the syntax of
Proxylet URI scheme defined in [7].
Syntax:
The ABNF grammar syntax for the web services URI is as follows:
Rezaur Expires May 2002 [Page 6]
Internet Draft Web Services as Callout Service November 2001
Uri = webservice:÷ //÷ [server] [/÷ resource-path]
server = // as specified in RFC2396.
resource-path = an XML document path within the server.
Here resource-path points to an XML document describing the web
service. The resource contains the following information items,
A Type÷ whose value is either WSDL÷ or UDDI÷.
If the type is WSDL, the record contains a URI for the WSDL
repository (the server where the WSDL document is located) otherwise
the file contains a tModelKey.
The file MUST contain the operation name (e.g., checkVirusInfection)
to invoke the service.
For interoperability, the OPES callout MUST use document-oriented
SOAP binding for its automated operation. This is necessary since the
automated system needs to know the entry point to the webservice that
describes the top level call to process the source document.
The following XML Schema describes the XML content model for a web
services resource file.
<schema
targetNamespace="http://www.opes-ietf.org/callout-
webservices/rulescheme/"
xmlns:tgt="http://www.opes-ietf.org/callout-webservices/
rulescheme/ "
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name=÷WebServicesRule÷ >
<complexType>
<sequence>
<element name=÷Type÷ type=÷string÷ minOccurs=1/>
<element name=÷Location÷ type=÷string÷ minOccurs=0/>
<element name=÷TModelKey÷ type=÷string÷ minOccurs=0
maxOccurs=÷unbounded÷/>
<element name=÷MethodSignature÷ type=÷string÷
minOccurs=1/>
</element>
</sequence>
</complexType>
</element>
</schema>
Rezaur Expires May 2002 [Page 7]
Internet Draft Web Services as Callout Service November 2001
5. Security Considerations
The Web Services for Callout Protocol SHOULD provide a sufficient
standard for securing the web services. As of this writing the work
in developing an industry standard for securing web services is under
way by various companies. We shall follow the industry development on
this aspect of web services and provide recommendation in a future
draft.
6. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
7. Acknowledgments
Thanks to Christian Maciocco for his valuable feedback on the draft.
8. References
[1] Eric Chrsitensen, Francisco Curbera, et al.,"Web Services
Description Language(WSDL) 1.1", W3C Note, 15th March 2001.
[2] UDDI Org, UDDI Technical White Paper÷, 6th September 2000.
[3] Editors: Martin Gudgin, Marc Hadley, et al., SOAP Version 1.2
Part 1: Messaging Framework÷, 2nd October 2001.
[4] UDDI Org, Using WSDL in a UDDI Registry 1.05÷, UDDI Working
Draft, Best Practices Document, 25th June 2001.
[5] UDDI Org, UDDI version 2.0 API Specification÷, UDDI Open Draft
Specification, 8th June 2001.
Rezaur Expires May 2002 [Page 8]
Internet Draft Web Services as Callout Service November 2001
[6] UDDI Org, UDDI Version 2.0 Data Structure Reference÷, UDDI Open
Draft Spec, 8th June 2001.
[7] Maciocco, C., Hofmann, M., "OMML: OPES Meta-data Markup
Language", draft-maciocco-opes-omml-00.txt
[8] Tomlinson, Orman, Condry, et al., " Extensible Proxy Services
Framework", draft-tomlinson-epsfw-00.txt
[9] Yang, L., Hoffman, M., OPES Architecture for Rule Processing and
Service Execution÷, draft-yang-opes-rule-processing-service-
execution-00.txt
[10] Barton, Thatte et al., SOAP Messages with Attachments÷, W3C
Note, 11th December, 2000.
[11] The ICAP Protocol Group, ICAP, the Internet Content Adaptation
Protocol÷, draft-elson-opes-icap-02.txt
9. Disclaimer
The views and specification herein are those of the authors and are
not necessarily those of their employer. The authors and their
employer specifically disclaim responsibility for any problems
arising from correct or incorrect implementation or use of this
specification.
10. Author's Address
Rezaur Rahman
Intel Corporation
MS JF3-202
2111 NE 25th Ave.
Hillsboro, OR 97124
Phone: +1-503-264-0417
E-Mail: rezaur.rahman@intel.com
Rama R. Menon
Intel Corporation
M/S JF3-206
2111 NE 25th Ave.
Hillsboro, OR 97124
Phone: +1-503-712-1438
E-Mail: rama.r.menon@intel.com
Lee Rafalow
IBM Corporation, BRQA/502
3039 Cornwallis Road
Research Triangle Park, NC 27709
E-mail: rafalow@watson.ibm.com
Rezaur Expires May 2002 [Page 9]
Internet Draft Web Services as Callout Service November 2001
11. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it maybe copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other then
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THEINTERNET ENGINEERING
TASK FORCE DISCLIAMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMAITON
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTEIS OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Rezaur Expires May 2002 [Page 10]
Internet Draft Web Services as Callout Service November 2001
Appendix A: Web Services Execution
+----------------------+
| OPES |
+-----------+ | Controller | +-----------+
| User |----->|----------------------|----->| Content |
| Agent |<-----| Service |<-----| Server |
+-----------+ | Execution engine | +-----------+
+----------------------+
A |
| |Callout Protocol
| V
+----------------------+
| Callout |
| Service |
+----------------------+
Fig A.1 - OPES System Architecture Components
Fig A.1 shows a typical OPES system architecture with a callout
service in use. The service execution engine communicates with the
callout service though a callout protocol. This section looks at ways
of integrating the web services with OPES service execution engine
such that the web services become callout services and the webs
service protocol becomes a callout protocol in the above diagram.
There are two ways of accomplishing this task: (1) a manual method
that involves custom development of a proxylet-like÷ shell for each
web service or (2) an automated integration mechanism that involves
discovery and invocation of a web service. The first alternative
requires a portion of the web service invocation process to be
manually developed, integrated and executed before the service can be
used by the OPES controller box. This scenario is suitable for
services that involves complex programmatic interfaces requiring
coding on the part of web service client. This mode of operation
closely resembles existing proxylet version of the service execution
performed in the existing OPES framework. The other alternative is
where the particular endpoint of a web service instantiation is
discovered before making a service call. In this scenario, the web
services discovery and invocation is mostly automated. This second
procedure provides greater flexibility in maintaining and migrating
web services from one server to another.
Rezaur Expires May 2002 [Page 11]
Internet Draft Web Services as Callout Service November 2001
Direct Call to a Web service from a Proxylet
The web services in this scenario works as a proxylet service for the
service execution environment [8]. As shown in Fig A.2 below, this
type of proxylet has two components- (1) interface to the service
execution engine through proxylet APIs and (2) the web service proxy
which executes on behalf of the remote web service on the local
platform. The web service component MAY make use of more than one web
service to complete its operation.
In this scenario the proxylet developer uses UDDI to select a web
service provider and retrieves the interfaces for a given service.
This interface is exposed as WSDL document. In some scenarios the
developer may get access to the WSDL document for a service from a
separate WSDL server or some other means. The developer chooses
proper binding and end points for the web service and generates
necessary code for web services proxy. The web services proxy code
and execution logic is exposed as a proxylet for the service
execution engine.
----------
| Client |
----------
| A
V |
|------------------------| ------------- Web Protocol------------
|OPES Service Execution |->|Proxy| Web |---------->|Web Service |
| OPES Controller |<-|-let |Service|<----------| |
------------------------- | | Proxy | |------------|
| A --------------
V |
|---------|
| Server |
|--------_|
Fig A.2. Web Services Client as a Proxylet in an OPES Framework
Fig A.2 above shows a generalized model of a web service invocation
by a Service Execution engine using proxylet API. In this scenario,
the web service description SHOULD be retrieved and a web service
proxy MUST be generated off-line with human intervention. The web
service proxy MUST implement appropriate interface (like proxylet
interface) to integrate with the OPES service execution module.
Rezaur Expires May 2002 [Page 12]
Internet Draft Web Services as Callout Service November 2001
The proxylet SHOULD be installed on the Service Execution environment
in the OPES Controller, as part of the system
installation/configuration. After this is done, it becomes possible
to invoke the web service through the proxylet (Fig A.3).
| rule module A
V |
+--------------+ |
| Rule Parser | |[Rule Parsing and
| & Validation | | compilation]
+--------------+ |
| |
V |
+--------------+ |
| Rule | |
| Base | V
+--------------+
|
|
|
V
+---------+ +----------+ +---------+ +--------+
-->| Message |--->| Rule |-->| Service |------->|Proxylet|
| Parser | | Processor| |Execution| |WebServc|
+---------+ +----------+ +---------+ +--------+
<---------------------------------------------------------------->
[Rule Processing and Service Execution]
Fig A.3. Service Execution within an OPES Device [9]
A rule match described through rule module [9] causes the Service
Execution to invoke the proxylet (Fig A.3). Upon invocation, the
proxylet gathers data and transforms the request and/or response
messages and associated data through web service interface.
The protocol details and message formats exchanged between the
proxylets and the web services are defined in documents [3] and [1].
Rezaur Expires May 2002 [Page 13]
Internet Draft Web Services as Callout Service November 2001
Automated Web Service Execution through Discovery
This method is intended for the automated invocation of web services
in an OPES framework. In this scenario, the rule engine provides a
hint as to the service to be executed and the service engine performs
the rest. There are two parts to this process.
Offline process: is where the hints provided by rule author is used
to discover and auto generate the web services proxy as dynamically
loadable modules. The interfaces for these dynamically loadable
modules will be implementation specific since these modules will be
auto generated by the system.
Runtime process: is where a rule match triggers a specific web
service invocation and the web service proxy is loaded and tied to
the resources (message headers and bodies) to be processed by the
remote web service.
By its nature, automated web service discovery and execution is
applicable where the web service involves simple method execution as
shown in Fig A.4.
----------
| Client |
----------
| A
V | SOAP
|------------------------|WEB Protocol |-----------|
|OPES Service Execution |------------> |Web Service|
| OPES Controller |<-------------| |
------------------------- |-----------|
| A
V |
|---------|
| Server |
|--------_|
Fig A.4. Web Service Execution from the Service Execution Engine
The SOAP message to the web service (Fig A.4) can be document
oriented where the whole document is sent to the Web service for
transformation (example: language translation service that works on
an HTML document). Or it can be RPC oriented where parts of the
document are converted by invoking remote procedures (example:
converting temperatures in a document from Celsius to Fahrenheit).
For automated web service proxy generation, the web services that
Rezaur Expires May 2002 [Page 14]
Internet Draft Web Services as Callout Service November 2001
support document-oriented SOAP messaging protocol SHOULD be used.
This requirement is imposed due to the nature of Edge Services in the
OPES framework and the suitability of the web services to automated
code generation and invocation. (See section 4 and Section 7.)
For RPC oriented Web Services, see the method described in 3.1.
Automated web service discovery and invocation enables the service
execution unit to make policy driven selection between different
service providers by looking up the UDDI registry entries. The
process is as follows:
A. The service execution engine is setup with a list of UDDI registry
URIs to be used for service discovery.
B. The rule module specifies the service though a list of
tModelKeys[4] and a method name.
C. The service is discovered and invoked. The process of selecting a
given service provider who supports a given service interface is as
follows. The item numbers in the list corresponds to the numbers
associated with the arrows in figure A.5.
Service UDDI WSDL Web Service
Execution Server Server Host
| 1 | | |
| -------> | | |
| 2 | | |
| <------- | | |
| | 3 | |
| ------------------------> |
| | 4 | |
<------------------------- |
| 5 |
|----------------------------------------->|
| 6 |
|<-----------------------------------------|
Fig A.5. Web Service Discovery and Execution Sequence
1. The OPES Service Execution engine makes a find_Service÷[5] UDDI
API call to locate all services that are defined by the given
tModelBag. The tModelBag contains the tModelKey for the WSDL
Interface we are interested in and other criteria.
2. This call returns a businessList on success. Assuming a nonempty
list, the execution engine drills down the list using UDDI API
calls to evaluate and select a business that satisfies the service
policy requirements at the edge (see browse pattern[5]). Once a
Rezaur Expires May 2002 [Page 15]
Internet Draft Web Services as Callout Service November 2001
business service is discovered that matches the policy
requirement, the appropriate bindingTemplate is retrieved from the
business service. The selection of binding template depends on the
various attributes of the bindingTemplate structure[6] like
accessPoint, tModelInstanceDetails etc. The tModelInstanceInfo is
traversed to retrieve the WSDL URL containing the WSDL service
interface document.
3. The service execution module requests (this should be through the
dynamically loaded proxylet) the WSDL document for a given service
from the WSDL server retrieved in step 2.
4. The server returns the WSDL document that describes the endpoints
of the requested web service.
5. Service Execution unit selects a particular implementation of a
service based on policies at the OPES controller. The binding
SHOULD be a SOAP binding.
5.1 The steps up to this point will be performed when the rule
engine compiles a rule describing the web service.
5.2 On a rule match, using the interface definition described in the
WSDL file and the operation name described in the rule file, the
web service enabled service execution engine makes service
request to the web services host at the end point. The service
execution engine will be responsible for sending the request÷
and response÷ modification requests together with the data to
the web service. The service request MUST follow the content
encapsulation guideline described in section 4.
6. The server performs appropriate service requested on the document
or data element and returns the result.
For the cases where the service requester knows the location of a
WSDL document, one can start from step 3 enumerated above.
Appendix B: Performance Issues
This section is non-normative. The performance issues will be
addressed by specific implementation. This section makes some
suggestions regarding how to overcome the overhead related to the web
service discovery.
In order to speed up the service execution performance, the UDDI
registry search or the WSDL registry search MAY be performed
statically when the rule base is loaded into the system and
processed. When a rule match happens at run time, the
ServiceExecution module would load appropriate precompiled code to
communicate with a web service.
Preview Operation: A preview operation MAY be provided by the web
services to check ahead part of the content to determine further
action from the web services on the content.
Rezaur Expires May 2002 [Page 16]
Internet Draft Web Services as Callout Service November 2001
Appendix C: Automated Service Invocation Rules
The web service end points described by WSDL can operate on messages
containing either document-oriented or procedure oriented information
[1]. A document-oriented message lends itself to simplified
programming model, capable of being generated computationally with
tractable complexity. The web service automation as described in
section 3.2 is applicable for simple method invocation where the web
service call semantics require a single top level method call that
operate on a document sent as a SOAP attachment or as part of the
SOAP body.
Rezaur Expires May 2002 [Page 17]