Web Services Architecture
This section, briefly reviews web services as application integration technology, defines the term web service and describes the web services model.
What
the web did for program-to-user interactions, web services is poised to do for
program-to-program interactions. Web services will help companies to reduce the
cost of doing e-business, it will make it possible for them to deploy solutions
more rapidly, and it will open up new opportunities for them. The key to
reaching this new horizon is a common program-to-program communication model,
built on existing and emerging standards such as HTTP, XML, SOAP, WSDL, and
UDDI.
Web services allow applications to be integrated more rapidly, easily, and cheaply than before. Web services enable integration at a higher level in the protocol stack, based on messages that are centered on service semantics (rather than network protocol semantics) enabling loose integration of business functions. These are characteristics that are ideal for connecting business functions across the web – both between enterprises and within enterprises. They provide a unifying programming model so that application integration inside and outside the enterprise can be done with a common approach, leveraging common infrastructure. Integration and application of web services can be done in an incremental manner, using existing languages and platforms, adopting existing legacy applications. Moreover, web services are intended to compliment J2EE, CORBA and other standards for integration of more tightly-coupled distributed and non-distributed applications. Web services is a technology for deploying and providing access to business functions over the web, and J2EE, CORBA, and other traditional programming standards are technologies for implementing web services.
Early
use of web services will be pair wise and ad hoc. However, web services
addresses the complete problem of program-to-program communication including
describing, publishing and finding interfaces. As the use of web services grows
and the industry matures, more dynamic models of application integration will
develop. Eventually, systems integration through web services will happen dynamically
at runtime. Just-in-time integration will herald a new era of
business-to-business integration over the Internet.
Definition of Web Services
A web service is an interface that describes a collection of operations that are network accessible through standardized XML messaging.
The official W3c definition: A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols.
Web services fulfill a specific task or a set of tasks. 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.
This allows and encourages web services based applications to be loosely coupled, component oriented, cross-technology implementations. Web services can be used alone or in conjunction with other web services to carry out a complex aggregation or a business transaction.
The Web Services Oriented Architecture Model
The web service architecture based upon the interactions between three roles: 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. The detailed definitions of the elements follow:
Figure 1 - Web Services Roles, Operations and Artifacts
Figure 1Figure
1 illustrates these operations, the components
providing them and their interactions.
Artifacts of a Web Service
· 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.
Roles in a Web Service Architecture
·
The 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.
·
The 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.
·
The Service
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 find services and obtain
binding information (in the service descriptions) for services 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 file, FTP site, URL, or WSIL documentADS/DISCO.
Operations in a Web Service Architecture
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. The interaction can be 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.
Here is an example of the same SOA triangle with a
peer to peer relationship. In this case, each partner in the interaction plays
both the services provider and service requester roles.
<Note to
reviewers: Igors Interaction diagrams here>
In this case the SOA triangle has been modified
slightly to call attention to the fact that the service requester is not
tightly coupled to the service provider. The service provider may respond
to a completely different requestor. This illustration also shows that the
communication path between requestor and provider may not be direct and
exclusive. There may be one or more intermediaries that are invoked on either (or both)
the request message path and response message path.
Layman’s Scenario (From HK’s JMX book, we need to give attribution if we keep the next two paragraphs.): In a Service Oriented Architecture you, a service provider, have a software component you wish to make available to your clients over a network. That software component is the service implementation. You now create a service description for it. There are two types of information in the complete service description, functional and non-functional information. The functional description is used directly by the client and describes the mechanics a client must know to invoke your service, i.e. the interface and binding data. You may also want to include additional functional description to detail to your clients what your security requirements are and perhaps how long they should wait before a timeout among other things. The non-functional description is the rest of the information that clients will need to find your service and decide to use your service. The non-functional metadata and should at least include what business owns and runs the service, what the categorization taxonomy of the service is. You might also include additional interesting information such as the cost of using your service.
The description of your service is used to publish it in a registry, directory, or repository of service descriptions. After publication, the registry also has a copy of your service description. At some later time, a service requestor needs to use a service just like yours. The service requestor, or client, finds your service in the registry and retrieves the WSDL from the registry. Now the client developer can write code to invoke the service based on the WSDL. The fact that clients for Web services can be written and deployed long after the service gives us lifecycle decoupling. Given currently available development tools, the client development environment will generate a stub (or proxy) for the service. These stubs would usually completely hide the WSDL and SOAP transport from the client developer. This stub would do the actual bind to the service provider and then invoke the service. This methodology is already supported by many development toolkits and Web service execution environments.
The following web services architecture explains how to instantiate the elements and implement the operations in an interoperable manner.
Web Services Lifecycles
Web Service Development Lifecycle
The web services development lifecycle includes the design, deployment, and runtime requirements for each of the roles: service registry, service provider, and service discovery agency. Each component role has specific requirements for each element of the development lifecycle. The development and deployment of a service discovery agency is outside the scope of this discussion.
The development lifecycle can be examined as having four phases:
1.
Build
The build phase of the lifecycle includes development and testing of the web service implementation, the definition of the service interface description, and the definition of the service implementation description. Web service implementations can be provided by creating new web services, transforming existing applications into web services, and composing new web services from other web services and applications.
2.
Deploy
The deploy phase includes the publication of the service interface and service implementation definition to a requestor or registry and installation and deployment of the executables for the web service into an execution environment. Typically this will be a web application server.
During the run phase the web service is available for invocation. At this point, the web service is fully deployed, operational, and network accessible from the service provider. Now the requestor can perform the find and bind operations.
4.
Manage
The manage phase of the web service lifecycle covers ongoing management and administration of the web service application. Security, availability, performance, quality of service, and business processes must all be addressed.
Web Service Execution Lifecycle
Question to Reviewers: do we need this? Or is it a sub
element of Run:
1. Configure
2. Start
3. Enable
4. Configure
5. Operate
6. Monitor
1. Disable
7.
8. Stop
Stop
