3.1 Basic Architecture
The Web services architecture places into relationship various
components and technologies that comprise a Web services "stack" or
completely functional implementation. Valid implementations include
subsets or parts of the stack, but must at least provide the
components within the basic architecture. Components and
technologies that extend the basic architecture are represented
within the extended architecture.
The basic architecture includes Web services technologies
capable of:
The basic Web services architecture defines an interaction
between software agents as an exchange of messages between service
requesters and service providers. Requesters are software agents
that request the execution of a service. Providers are software
agents that provide a service. Agents can be both service
requesters and providers. Providers are responsible for publishing
a description of the service(s) they provide. Requesters must be
able to find the description(s) of the services.
The basic Web service architecture models the interactions
between three roles: the service provider, service discovery
agency, and service requestor. The interactions involve the
publish, find, and bind operations. These roles and operations act
upon the web service artifacts: the web service software module and
its description. In a typical scenario a service provider hosts a
network accessible software module (an implementation of a web
service). The service provider defines a service description for
the web service and publishes it to a requestor or service
discovery agency. The service requestor uses a find operation to
retrieve the service description locally or from the discovery
agency (i.e. a registry or respository) and uses the service
description to bind with the service provider and invoke or
interact with the web service implementation. Service provider and
service requestor roles are logical constructs and a service may
exhibit characteristics of both.
Requesters and providers interact using one or more message
exchange patterns (MEPs) that define the sequence of one or more
messages exchanged between them. A service description is hosted by
a discovery service, to which a provider publishes the description,
and from which the requester discovers the description. The
description includes data type and structure information,
identifies the MEP, and contains the address of the service
provider.
The extended architecture describes Web services support for
MEPs that group basic messages into higher-level interactions,
details how support for features such as security, transactions,
orchestration, privace and others may be represented in messages
(SOAP modules), and describes how additional features can be added
to support business level interactions. The extended architecture
builds on the basic architecture using the extensibility mechanisms
inherent in the basic technologies.
Software agents in the basic architecture can take on one or all
of the following roles:
-
Service requester -- requests the execution of a Web service
-
Service provider -- processes a Web service request
-
Discovery agency -- agency through which a Web service
description is published and made discoverable
A software agent in the Web services architecture can act in one
or multiple roles, acting as requester or provider only, both
requester and provider, or as requester, provider, and discovery
agency. A service is invoked after the description is found, since
the service description is required to establish a binding.
The figure above illustrates the basic Web services
architecture, in which a service requestor and service provider
interact based on the service's description information published
by the provider and discovered by the requester through some form
of discovery agency. Service requesters and providers interact by
exchanging messages, which may be aggregated to form MEPs.
In the diagram above, the nodes of the triangle represent roles,
as further defined in section 3.1.2
Roles and the edges represent operations, which are further
defined in section 3.1.3
Operations
One or more intermediaries may exist in a message path between
requester and provider. Intermediaries, where present, cannot
interfere with the MEP. Intermediaries may perform certain
functions associated with the message such as routing, security,
management, or other operations. Examples of MEPs include one-way,
request/response, publish/subscribe, and broadcast.
Basic Web services architecture components are typically defined
using XML applications, use XML infoset definitions for message
data typing and structuring, and use HTTP for transport. Extended
Web services architecture components are typically defined using
extensions to the core XML applications and transports, including
alternatives to HTTP.
A message is defined as a construct that can include zero or
more headers in addition to data. The header part of a message can
include information pertinent to extended Web services
functionality, such as security, transaction context, orchestration
information, or message routing information. The data part of a
message contains the message content or data.
A web service is described using a standard, formal XML notion,
called its service description, that provides all of the details
necessary to interact with the service, including message formats
(that detail the operations), transport protocols, and location.
The nature of the interface hides the implementation details of the
service so that it can be used independently of the hardware or
software platform on which it is implemented and independently of
the programming language in which it is written.
Web services can be used alone or in conjunction with other web
services to carry out a complex aggregation or a business
transaction.
The figure above illustrates the relationships between
requesters, providers, services, descriptions, and discovery
services in the case where agents take on both requester and
provider roles. For example, XML messages compliant with the SOAP
specification are exchanged between the requester and provider. The
provider publishes a WSDL file that contains a description of the
message and endpoint information to allow the requester to generate
the SOAP message and send it to the correct destination.
To support the common MEP of request/response, for example, a
Web services implementation provides software agents that function
as both requesters and providers, as shown in Figure 2. The service
requester sends a message in the form of a request for information,
or to perform an operation, and receives a message from the service
provder that contains the result of the request or operation. The
service provider receives the request, processed the message and
sends a response. The technologies typically used for this type of
Web services interaction include SOAP, WSDL, and HTTP.
Note:
The Web services architecture does not include the concept of
automatically correlating requests and responses, as some RPC
oriented technologies do. The correletion of request and response
messages is typically application-defined.
The following sections provide more formal definitions of the
components, roles, and operations in Web services architecture.
3.1.1
Components
-
The Service: Whereas a web service is an interface described by
a service description, its implementation is the service. A service
is a software module deployed on network accessible platforms
provided by the service provider. It exists to be invoked by or to
interact with a service requestor. It may also function as a
requestor, using other web services in its implementation.
-
The Service Description: The service description contains the
details of the interface and implementation of the service. This
includes its data types, operations, binding information, and
network location. It could also include categorization and other
meta data to facilitate discovery and utilization by requestors.
The complete description may be realized as a set of XML
description documents. The service description may be published to
a requestor directly or to a discovery agency.
3.1.2 Roles
-
Service Provider: From a business perspective, this is the owner
of the service. From an architectural perspective, this is the
platform that hosts access to the service. It has also been
referred to as a service execution environment or a service
container. Its role in the client-server message exchange patterns
is that of a server.
-
Service Requestor: From a business perspective, this is the
business that requires certain function to be satisfied. From an
architectural perspective, this is the application that is looking
for and invoking or initiating an interaction with a service. The
requestor role can be played by a browser driven by a person or a
program without a user interface, e.g. another web service. Its
role in the client-server message exchange patters is that of a
client.
-
Discovery Agency: This is a searchable set of service
descriptions where service providers publish their service
descriptions. The service discovery agency can be centralized or
distributed. A discovery agency can support both the pattern where
it has descriptions sent to it and where the agency actively
inspects public providers for descriptions. Service requestors may
find services and obtain binding information (in the service
descriptions) during development for static binding, or during
execution for dynamic binding. For statically bound service
requestors, the service discovery agent is in fact an optional role
in the architecture, as a service provider can send the description
directly to service requestors. Likewise, service requestors can
obtain a service description from other sources besides a service
registry, such as a local filesystem, FTP site, URL, or WSIL
document.
3.1.3
Operations
In order for an application to take advantage of Web services,
three behaviors must take place: publication of service
descriptions, finding and retrieval of service descriptions, and
binding or invoking of services based on the service description.
These behaviors can occur singly or iteratively, with any
cardinality between the roles. In detail these operations are:
-
Publish: In order to be accessible, a service needs to publish
its description such that the requestor can subsequently find it.
Where it is published can vary depending upon the requirements of
the application (see Service Publication Stck discussion for more
details)
-
Find: In the find operation, the service requestor retrieves a
service description directly or queries the registry for the type
of service required (see Service Discovery for more details). The
find operation may be involved in two different lifecycle phases
for the service requestor: at design time in order to retrieve the
service's interface description for program development, and at
runtime in order to retrieve the service's binding and location
description for invocation.
-
Interact: Eventually, a service needs to be invoked. In the
interact operation the service requestor invokes or initiates an
interaction with the service at runtime using the binding details
in the service description to locate, contact, and invoke the
service. Examples of the interaction include: single message one
way, broadcast from requester to many services, a multi message
conversation, or a business process. Any of these types of
interactions can be synchronous or asynchronous.
3.3 Web Services Stacks
To ensure interoperability when performing the publish, find and
bind operations expressed in the Service Oriented Architecture
(SOA) diagram; conceptual and technical standards must be defined
for each role and type of interaction. This section will explore
each of roles and interactions in order identify each relevant
stack of technologies.
There are over arching concerns involving security, management
and quality of services that must be addressed at each layer in the
conceptual and technical stacks. The various solutions at each
layer may or may not be independent of one other. More of these
overarching concerns will emerge as the web services paradigm is
adopted and evolved. What is most important is building a framework
through which all such concerns may be applied to each of the
layers in the stack so that as new concerns emerge they may be
dealt with flexibly and consistently.
At the end of this section we assemble the independent stacks
into a single stack where each additional layer builds upon the
capabilities provided by those below it. The vertical towers
represent the variety of over arching concerns that must be
addressed at every level of each of the stacks.
An important point is that, towards the bottom layers of the
stack, the technologies and concepts are relatively more mature and
achieve a higher level of standardization than many of the upper
layers. The maturation and adoption of Web services will drive the
continued development and standardization of the higher levels of
the stack and the overarching concerns.
3.3.1 Wire
"Stack"
The wire stack encapsulates the concepts and technologies
dealing with the actual physical exchange of information between
any of the roles in the SOA diagram. This includes the variety
network transport, message packaging and message extensions that
may be utilized to facilitate data exchange.
3.3.1.1 Transport
The foundation of the web services stack is the network. Web
services must be network accessible to be invoked by a service
requestor. Web services that are publicly available on the Internet
use commonly deployed network protocols. Because of its ubiquity,
HTTP is the de facto standard network protocol for
Internet-available web services. Other Internet protocols may be
supported including SMTP and FTP. Intranet domains may use
proprietary or platform and vendor specific protocols such as
MQSeries, CORBA, etc.. The specific choice of network protocol used
in any given scenario depends entirely upon application
requirements, including concerns such as security, availability,
performance, and reliability. This allows web services to
capitalize on existing higher function networking infrastructures
and message oriented middleware, such as MQSeries.
Within an enterprise with multiple types of network
infrastructures, HTTP can be used as a common, interoperable bridge
to connect disparate systems. One of the benefits of web services
is that it provides a unified programming model for the development
and usage of private Intranet as well as public Internet services.
As a result, the choice of network technology can be made entirely
transparent to the developer and consumer of the service.
3.3.1.2 Packaging
Moving up the Wire stack, the next layer, Packaging, represents
the technologies that may be used to package information being
exchanged. XML has been broadly adopted as the basis for Web
service message packaging protocols.
SOAP is a simple and lightweight XML-based mechanism for
creating structured data packages that can exchanged between
network applications. SOAP consists of four fundamental components:
an envelope that defines a framework for describing message
structure, a set of encoding rules for expressing instances of
application-defined data types, a convention for representing
remote procedure calls (RPC) and responses, and a set of rules for
using SOAP with HTTP. SOAP can be used in combination with a
variety of network protocols; such as HTTP, SMTP, FTP, RMI/IIOP, or
a proprietary messaging protocol.
SOAP is currently the de facto standard for XML messaging for a
number of reasons. First, SOAP is relatively simple, defining a
thin layer that builds on top of existing network technologies such
as HTTP that are already broadly implemented. Second, SOAP is
flexible and extensible in that rather than trying to solve all of
the various issues developers may face when constructing Web
services, it provides an extensible, composable framework that
allows solutions to be incrementally applied as needed. Thirdly,
SOAP is based on XML. Finally, SOAP enjoys broad industry and
developer community support.
3.3.1.3
Extensions
Building on the transport and packaging layers, the final layer
in the Wire stack provides a framework that allows additional
information to be attached to Web service messages representing a
variety of additional concerns; such as context, routing, policy,
etc. As a key part of its envelope message structure, SOAP defines
a mechanism to incorporate orthogonal extensions (also known as
features) to the message in the form of headers and encoding rules.
It is expected that as Web services are adopted and evolved, a
broad collection of such extensions will emerge and be
standardized.
3.3.2 XML Messaging
with SOAP
Here is an example of how SOAP, HTTP, and the internet can be
used to implement the Wire stack. The following figure shows how
XML messaging (SOAP) and network protocols can be used as the basis
of the web services architecture.
| Editorial
note |
|
| CBF: missing
graphic... |
The basic requirements for a network node to play the role of
requestor or provider in XML Messaging based distributed computing
are the ability to build and/or parse a SOAP message and the
ability to communicate over a network (receive and/or send
messages).
Typically, a SOAP Server running in a web application server
performs these functions. Alternatively, a programming
language-specific runtime library can be used that encapsulates
these functions within an API. Application integration with SOAP
can be achieved by using four basic steps:
-
In the Figure 1 above at (1), a service requestor’s
application creates a SOAP message. This SOAP message is the
request that invokes the web service operation provided by the
service provider. The XML document in the body of the message can
be a SOAP RPC request or a document-centric message as indicated in
the service description. The service requestor presents this
message together with the network address of the service provider
to the SOAP infrastructure (e.g. a SOAP client runtime). The SOAP
client runtime interacts with an underlying network protocol (e.g.
HTTP) to send the SOAP message out over the network.
-
The network infrastructure delivers the message to the service
provider’s SOAP runtime (e.g. a SOAP server) (2). The SOAP
server routes the request message to the service provider's web
service. The SOAP runtime is responsible for converting the XML
Message into programming language specific objects if required by
the application. This conversion is governed by the encoding
schemes found within the message.
-
The web service is responsible for processing the request
message and formulating a response. The response is also a SOAP
message. The response SOAP message is presented to the SOAP runtime
with the service requestor as the destination (3). In the case of
synchronous request/response over HTTP, the underlying
request/response nature of the networking protocol is used to
implement the request/response nature of the messaging. The SOAP
runtime sends the SOAP message response to the service requestor
over the network.
-
The response message is received by the networking
infrastructure on the service requestor’s node. The message
is routed through the SOAP infrastructure; potentially converting
the XML message into objects in a target programming language (4).
The response message is then presented to the application.
This example uses the request/response transmission primitive
that is quite common in most distributed computing environments.
The request/response exchange may be synchronous or asynchronous.
Other transmission primitives such as one-way messaging (no
response), notification (push style response), publish/subscribe
are possible using SOAP.
3.3.2.1
Interactions
-
One way: Message sent from requestor to provider. Provider may
or may not return a response. If the provider returns a response,
the requester may have already stopped ‘listening’ for
it or closed the communications channel. Response will be
‘thrown away’ and not processed by the requester
-
Conversational: Requester and Provider exchange multiple
messages. Can be defined by choreography language.
-
Many-to-Many: Requester sends message to many providers. Or,
service provider responds to many requestors. Can be defined by
choreography language.
3.3.3 Description
"Stack"
The service description layer is actually a stack of description
documents defined using XML Schema.
It is through the service description that the service provider
communicates all the specifications for invoking the Web service to
the service requestor. The service description is a key contributor
to making the Web services architecture loosely coupled and to
reducing the amount of required shared understanding, custom
programming and integration between the service provider and the
service requestor. For example, neither the requestor nor the
provider must be aware of the other's underlying platform,
programming language, or distributed object model (if any). The
service description combined with the underlying XML Message
infrastructure defined in the Wire stack sufficiently encapsulates
this detail away from the service requestor's application and the
service provider’s Web service.
We describe the constituent parts of the service description
used in the Web services architecture in two groups, those used to
fully describe one Web service and those used to describe
interactions or relationships between sets of Web services.
3.3.3.1 Descriptions
Applying to a Particular Web Service
The first two layers of the description stack describe the
mechanics of invoking a Web service. The interface, or messages the
service expects and returns, and the implementation, how to encode
the messages and where to send them to. These two layers are
satisfied by Web Services Description Language (WSDL) [WSDL]. The
interface and implementation are the minimum service description
necessary to support interoperable Web services.
The Web services architecture uses WSDL (Web Services Definition
Language)[WSDL 01] for base-level service description. WSDL has
been submitted to the W3C and is being actively developed by the
W3C Web Services
Description WG. WSDL is an XML document format for describing
Web services as a set of endpoints operating on messages containing
either document-oriented or procedure-oriented (RPC) messages. The
operations and messages are described abstractly, and then bound to
a concrete network protocol and message format to define an
endpoint. Related concrete endpoints may be combined into services.
WSDL is sufficiently extensible to allow description of endpoints
and their messages regardless of what message formats or network
protocols are used to communicate. WSDL1.1 describes bindings for
SOAP1.1, HTTP POST, and MIME. WSDL1.2 will add binding support for
SOAP1.2.
The policy description layer is where the additional description
necessary to specify the business context, qualities of service,
security requirements and offerings, and management requirements.
The WSDL document can be complimented by other service description
documents to describe these higher-level aspects of the Web
service. For example, business context can be described using
Universal Data Description Interface (UDDI) [UDDI] data structures
in addition to the WSDL document.
The presentation layer describes how to render the input and
output messages on a screen for a user to interact with. This is
particularly useful for rendering Web services to users on many
different types of devices.
3.3.3.1.1
Interface
A service interface definition is an abstract or reusable
service definition that may be instantiated and referenced by
multiple service implementation definitions. Think of a service
interface definition like an IDL (Interface Definition Language),
Java interface, or Web service type. This allows common industry
standard service types to be defined and implemented by multiple
service implementers. This is analogous to defining an abstract
interface in a programming language and having multiple concrete
implementations. Service interfaces may be defined by industry
standards organizations, such as RosettaNet or HL7 for the health
industry.
In WSDL, the service interface contains elements that comprise
the reusable portion of the service description: binding,
portType, message and type elements as
depicted in Figure 2 - Basic Service Description above. In the
portType element, the operations of the Web service are
defined. The operations define what XML messages can appear in the
input, output and fault data flows. The message element
specifies which XML data types constitute various parts of a
message. The message element is used to define the
abstract content of messages that comprise an operation. The use of
complex data types within the message is described in the
types element. The binding element describes the
protocol, data format, security and other attributes for a
particular service interface (portType).
3.3.3.1.2
Implementation
The service implementation definition describes how a particular
service interface is implemented by a given service provider. It
also describes its location so that a requester can interact with
it. In WSDL, a Web service is modeled as a service
element. A service element contains a collection of
port elements. A port associates an endpoint
(e.g. a network address location (URL)) with a binding
element from a service interface definition.
To illustrate the allocation of responsibility, the Open
Applications Group[OAG] may define a service interface definition
for the OAGIS purchase order standard. This service interface
definition would define WSDL type(s), message(s),
portType(s) and binding(s). This specification
would be published at some well-known site (e.g.
http://www.openapplications.org/serviceInterfaces/).
A service provider may choose to develop a web service that
implements the OAGIS purchase order service interface. The service
provider would develop a service implementation definition document
that describes the WSDL service, port, and
address location elements that describe the network
address of the provider’s Web service and other
implementation specific details.
The service interface definition together with the service
implementation definition makes up a complete WSDL definition of
the service. This pair contains sufficient information to describe
to the service requestor how to invoke and interact with the Web
service. The service requestor may require other information about
the service provider’s end-point. This information is
provided by the complete Web service description of the
service.
3.3.3.1.3 Policy
Policy for Web services consists of facts, or assertions, and
rules that apply to a particular Web service. The policy may be
associated with an interface (portType), a
binding of that interface to a protocol, or a
service instance. Policy would be used to describe or
point to documents describing the owning business, associated
products, keywords, taxonomies for the service, security policies,
quality of service attributes, etc. Policy may be used by the
over-arching concerns: security, quality of service, and
management; as well as higher layers of the description stack.
3.3.3.1.4
Presentation
A Web service description may be accompanied by another
description document which defines how to display a service to a
user and what the interactions between the service and the user
should be. This description could be used to render the service on
a variety of devices including phones, PDAs, and systems.
3.3.3.2 Description
for Relationships between Web Services
There are two types of relationships between services:
programmatic and agreements. Programmatic relationships are
captured by the composition and orchestration description layers.
Agreements are more contractual indicating an agreement, possibly
legally binding. Agreements are captured by the service level
agreement and business agreement description layers.
Since a Web service’s implementation is a software module
or ‘component’, it is natural to produce Web services
by composing web services. A composition of Web services could play
one of several roles. Intra-enterprise Web services might
collaborate to present a single Web service interface to the
public. Optionally, the Web services from different enterprises may
collaborate to perform machine-to-machine or business-to-business
transactions. Alternatively, a workflow manager may call each Web
service as they participate in a business process. The composition
and orchestration layers describe how service-to-service
communications, collaborations, and flows are performed.
Description languages like BPEL4WS can be used to describe these
interactions.
3.3.3.2.1
Composition
@@@
3.3.3.2.2
Orchestration
An orchestration description reflects a simple choreography of
Web service invocations between two business partners to complete a
multi-step business interaction. For example an agreement
definition defines roles such as buyer and seller within a
purchasing protocol. The agreement definition outlines the
requirements that each role must fulfill. For example, the seller
must have web services that receive request for quote (RFQ)
messages, purchase order (PO) messages and payment messages. The
buyer role must have Web services that receive quotes (RFQ response
messages), invoice messages and account summary messages. This
simple choreography of web services into business roles is critical
for establishing multi-step service-oriented interactions between
business parties. A given service requestor or service provider
might be able to play the buyer or seller role in a number of
different business process flow standards. By explicitly modeling
business agreements and each node’s ability to play roles in
the business agreement, the requestor can choose which business
agreement to engage in with various provider business partners.
3.3.3.2.3 Service
Level Agreements
@@@
3.3.3.2.4 Business
Level Agreements
@@@
3.3.4 Discovery
Agencies "Stack"
While the bottom three layers of the stack identify technologies
for compliance and interoperability, the service publication and
service discovery can be implemented with a range of solutions.
Any action that makes a WSDL document available to a requestor,
at any stage of the service requestor’s lifecycle, qualifies
as service publication.
Since a web service cannot be discovered if it has not been
published, service discovery depends upon service publication. The
variety of discovery mechanisms parallels the set of publication
mechanisms. Any mechanism that allows the service requestor to gain
access to the service description and make it available to the
application at runtime qualifies as service discovery. The
simplest, most static example of discovery is static discovery
wherein the service requestor retrieves a WSDL document from a
local file. This is usually the WSDL document obtained through a
direct publish or the results of a previous find operation.
Alternatively, the service may be discovered at design time or run
time using a local WSDL registry, or a public or private registry
such as UDDI. The variety of service discovery mechanisms is
discussed in more detail in the section titled Service
Discovery.
3.3.4.1 Service
Publication
3.3.4.1.1 Producing
Service Descriptions
The service description may be generated, hand coded, or pieced
together based on existing service interface definitions etc.
Developers may hand code the entire service description, including
the UDDI entry. Tools exist to generate parts of the WSDL and
potentially parts of the UDDI entry from metadata artifacts from
the programming model and the deployment of the web service
executable. Parts of the service description may already exist (for
example the web service may be based on an industry standard
service interface definition) such that very little needs to be
further generated.
| Editorial
note |
|
| CBF: needs to be made
less UDDI-centric |
3.3.4.1.2 Publishing
Service Descriptions
A service description can be published using a variety of
mechanisms. These various mechanisms provide different capabilities
depending on how dynamic the application using the service is
intended to be. The service description may be published to
multiple service registries using several different mechanisms. The
simplest case is a direct publish. A direct publish means the
service provider sends the service description directly to the
service requestor. This can be accomplished using an e-mail
attachment, an FTP site, or even a CDROM distribution. Direct
publish can occur after two business partners have agreed on terms
of doing e-business over the Web, or after fees have been paid by
the service requestor for access to the service. In this case the
service requestor may maintain a local copy of the service
description. Slightly more dynamic publication uses WSIL. WSIL
defines a simple HTTP GET mechanism to retrieve Web services
descriptions from a given URL. An enhanced service description
repository would provide a local cache of service descriptions, but
with additional search capabilities.
Another means of publishing service descriptions available to
Web services is through a UDDI registry. There are several types of
UDDI registries that may be used depending on the scope of the
domain of Web services published to it. When publishing a Web
service description to a UDDI registry, complete business context
and well thought out taxonomies are essential if the service is to
be found by its potential service consumers.
-
Internal Enterprise Application UDDI registry: Web services for
use within a company for internal enterprise applications
integration should be published to a UDDI registry of this kind.
The scope of this UDDI registry may be single application,
departmental, or corporate. These UDDI registries sit behind the
firewall and allow the service publishers more control over their
service registry and its accessibility, availability, and
publication requirements.
-
Portal UDDI registry: Web services published by a company for
external partners to find and use may use a portal UDDI registry. A
portal UDDI registry runs in the service provider’s
environment outside the firewall or in a DMZ between firewalls.
This kind of private UDDI registry contains only those service
descriptions that a company wishes to provide to service requestors
from external partners. This allows companies to retain control of
their service descriptions, access to the UDDI registry and quality
of service for the UDDI registries. Moreover, by using the Role
based visibility inherent in portals, and emerging in newer drafts
of the UDDI specs themselves, the enterprise may limit visibility
of service descriptions to the partners authorized to see their
existence.
-
Partner Catalog UDDI registry: Web services to be used by a
particular company can be published to a Partner Catalog (rolodex
like) UDDI registry. A Partner Catalog UDDI registry sits behind
the firewall. This kind of private UDDI registry contains only
approved, tested, and valid web service descriptions from
legitimate business partners. The business context and metadata for
these web services can be targeted to the specific requestor.
-
e-Marketplace UDDI registry: For web services that the service
provider intends to compete for requestors' business with other web
services, the service description should be published to an
e-Marketplace UDDI registry or the UDDI Business Registry.
E-Marketplace UDDI registries are hosted by an industry standards
organization or consortium and contain service descriptions from
businesses in a particular industry. These services may be required
to support specific standards, searchable meta data, interfaces, or
data types E-Marketplace UDDI registries will generally provide
some filtering of illegitimate entries as well as some guaranteed
qualities of service.
-
UDDI Business Registry: Web services may also wish to publish to
the UDDI Business Registry in some other public registry in order
that they may be discovered by new potential business partners or
service users.
This figure shows the continuum from the most static, easiest
technologies for publish and discovery to the most dynamic, more
complex technologies. Users or implementers of web services may not
follow this progression in strict sequence.
| Editorial
note |
|
| CBF: is there a missing
graphic here? |
3.3.4.2 Service
Discovery
3.3.4.2.1 Acquiring
Service Descriptions
As with publishing Web service descriptions, acquiring Web
service descriptions will vary depending on how the service
description is published and how dynamic the Web service
application is meant to be. Service requestors will find Web
services during two different phases of an application lifecycle
– design time and run time. At design time, service
requestors will search for web service descriptions by the type of
interface they support. At run time service requestors will search
for a web service based on how they communicate or qualities of
service advertised.
With the direct publish approach, the service requestor will
cache the service description at design time for use at runtime.
The service description may be statically represented in the
program logic, stored in a file, or in a simple, local service
description repository.
Service requestors can retrieve a service description at design
time or runtime from a Web page (URL), a service description
repository, a simple service registry or a UDDI registry. The
look-up mechanism will need to support a query mechanism that
provides find by type of interface (based on a WSDL template), the
binding information (i.e. protocols), properties (such as QOS
parameters), the types of intermediaries required, the taxonomy of
the service, business information, etc.
The various types of UDDI registries have implications on the
number of runtime binding web services can choose from, policy for
choosing one among many, or the amount of pre screening that must
be done by the requestor before invoking the service. Service
selection can be based on binding support, historical performance,
quality of service classification, proximity, or load balancing.
E-Marketplace UDDI registries will have more runtime services to
choose from. Some pre screening must be done to verify that the web
service provider is a worthy partner and is not nefarious or inept.
Choosing a service may be done based on price promises, cost,
presence on approved partners list, as well as binding support,
historical performance, quality of service classifications, and
proximity. If service requestors query the UDDI Business Registry
for web service providers, they will have to exercise the most
caution and diligence when prescreening potential service
providers. An efficient and accurate filter will have to be in
place to return only suitable descriptions and potential business
partners.
3.3.4.2.2 Consuming
Service Descriptions
Once a service description is acquired, the service requestor
will need to process it in order to invoke the service. The service
requestor uses the service description to generate SOAP requests or
programming language specific proxies to the web service. This
generation can be done at design time or at runtime to format an
invocation to the web service. Various tools can be used at design
time or runtime to generate programming language bindings from WSDL
documents. These bindings present an API to the application program
and encapsulate the details of the XML messaging from the
application.
3.3.4.2.3
Inspection
Inspection technologies such as WSIL provide a de-centralized
service discovery method. It may be used to discover Web services
at the service provider's point-of-offering. The WSIL specification
defines a document format that contains a list of WSDL URLs and
other related WSIL URLs within a domain. WSIL can also reference
UDDI entries/repositories and RDF documents as well. It can
actually contain references to anything. The WSIL specification
defines a convention for naming and placing the files so that they
are easier to locate (similar to index.html and robots.txt files).
Inspection technologies, unlike registries, is not suited for
many/most of the dynamic discovery/bind scenarios, simply because
there is no searching capability.
They may or may not be local to the system. WSIL documents can
be used to enable a variety of discovery agent patterns:
-
Local service discovery for ‘local’ web service
applications (micro SOAs that don’t leave the box… all
else is the same except it limits where it looks for services).
-
Application integration.
-
Discovery agents populated by crawlers looking for WSIL
documents.
-
Management topologies of available services (but its not a
discovery source).
| Editorial
note |
|
| CBF: this section needs
more, we can get some help the WSIL folks |
3.3.5 Overarching
Concerns
| Editorial
note |
|
| CBF: To be
developed... |
@@@
3.3.6 The Complete Web
Services "Stack"
The figure above illustrates the complete stack of functions
contained in the extended Web services architecture. The extended
functionality includes additional technologies in the following
areas: discovery agencies, description, and wire. The extended
architecture also includes overarching concerns such as security,
management, and qualites of service that apply to all components in
the Web services architecture.
| Editorial
note |
|
| CBF: what about privacy?
where should this be reflected in the stack? |
| Editorial
note |
|
| EN: As with the basic
architecture, a next step after completing the description of the
diagrams will be to fill in the diagrams with reference
technologies and specifications. |
