Chapter 7. Technology options 129
? Standardization: When multiple applications use XML to communicate with
each other they need to agree on the tag names they are using. While
industry-specific standard tag definitions often do exist, you can still declare
your own non-standard tags.
? Large size: XML documents tend to be larger in size than other forms of data
representation.
7.3 Web services
The W3C’s Web Services Architecture Working Group has jointly come to
agreement on the following working definition of a Web service:
“A Web service is a software application identified by a URI, whose interfaces
and bindings are capable of being defined, described, and discovered as
XML artifacts. A Web service supports direct interactions with other software
agents using XML-based messages exchanged via Internet-based protocols.”
Basic Web services combine the power of two ubiquitous technologies: XML, the
universal data description language, and the HTTP transport protocol widely
supported by browser and Web servers.
Web services = XML + transport protocol (such as HTTP)
Some of the key features of Web services are as follows:
? Web services are self-contained.
On the client side, no additional software is required. A programming
language with XML and HTTP client support, for example, is enough to get
you started.
On the server side, merely a Web server and a servlet engine are required. It
is possible to Web service enable an existing application without writing a
single line of code.
? Web services are self-describing.
Neither the client nor the server knows or cares about anything besides the
format and content of request and response messages (loosely coupled
application integration).
The definition of the message format travels with the message. No external
metadata repositories or code generation tools are required.
? Web services are modular.
Web services are a technology for deploying and providing access to
business functions over the Web; J2EE, CORBA, and other standards are
technologies for implementing these Web services.
130 Broker Interactions for Intra- and Inter-enterprise
? Web services can be published, located, and invoked across the Web.
The standards required to do so are:
– Simple Object Access Protocol (SOAP), also known as service-oriented
architecture protocol, an XML-based RPC and messaging protocol
– Web Service Description Language (WSDL), a descriptive interface and
protocol binding language
– Universal Description, Discovery, and Integration (UDDI), a registry
mechanism that can be used to look up Web service descriptions
? Web services are language independent and interoperable.
The interaction between a service provider and a service requester is
designed to be completely platform and language independent. This
interaction requires a WSDL document to define the interface and describe
the service, along with a network protocol (usually HTTP).
Because the service provider and the service requester have no idea what
platforms or languages the other is using, interoperability is a given.
? Web services are inherently open and standards-based.
XML and HTTP are the technical foundation for Web services. A large part of
the Web service technology has been built using open source projects.
Therefore, vendor independence and interoperability are realistic goals.
? Web services are dynamic.
Dynamic e-business can become a reality using Web services because, with
UDDI and WSDL, the Web service description and discovery can be
automated.
? Web services are composable.
Simple Web services can be aggregated to more complex ones, either using
workflow techniques or by calling lower-layer Web services from a Web
service implementation.
WebSphere V5.0 provides support for Web services. WebSphere applications
can send and receive SOAP messages and also communicate with UDDI
registries to publish and find services.
For detailed information on Web services, check out the following sources:
? The IBM Redbook:
WebSphere Version 5 Web Services Handbook, SG24-6891
? The World Wide Web Consortium (W3C) Web site at:
http://www.w3.org/
Chapter 7. Technology options 131
7.3.1 Static and dynamic Web services
There are two ways of binding to Web services: static and dynamic.
? In the static process, the binding is done at design time. The service
requester obtains a service interface and implementation description through
a proprietary channel from the service provider (by e-mail, for example), and
stores it in a local configuration file. No private, public, or shared UDDI
registry is involved.
? The dynamic binding occurs at runtime. While the client application is
running, it dynamically locates the service using a UDDI registry and then
dynamically binds to it using WSDL and SOAP.
This requires that the contents of the UDDI registry be trusted. Currently, only
private UDDI networks can provide such control over the contents.
7.3.2 Web Services Invocation Framework
The Apache Web Services Invocation Framework (WSIF) provides a standard
Java API to invoke services, no matter how or where the service is provided, as
long it is described in WSDL.
WSIF enables the developer to move away from the native APIs of the
underlying service, and interact with representations of the services instead. This
allows the developer to work with the same programming model regardless of
how the service is implemented and accessed.
WSIF is WSDL-driven and provides a uniform interface to invoke services using
WSDL documents. So if a SOAP service you are using becomes available as an
EJB, for example, you can change to RMI/IIOP by just modifying the WSDL
service description, without needing to modify your applications that use the
service.
This API is used by tools such as WebSphere Studio Integration Edition and
runtimes such as WebSphere Application Server to construct and manipulate
services defined in WSDL documents. The architecture allows new bindings to
be added at runtime.
WSIF has the following advantages:
? Multiple bindings can be offered for services, and bindings can be decided at
runtime.
? Services can be used either by a set of stub classes (static) or by a dynamic
interface invocation (dynamic).
? You can switch protocols, location, and so forth, without having to recompile
your client code.
132 Broker Interactions for Intra- and Inter-enterprise
For more details on the Web Services Invocation Framework see:
http://ws.apache.org/wsif/
7.3.3 Web services and the service-oriented architecture
Service-oriented architectures (SOAs) support a programming model that allows
service components residing on a network to be published, discovered, and
invoked by each other in a platform, network protocol, and
language-independent manner.
The origin of SOA can be traced back to Remote Procedure Calls (RPCs),
distributed object protocols such as CORBA and Java RMI, and
component-based architecture such as J2EE/EJBs (Sun) and
(D)COM/COM+/.Net (Microsoft).
Using XML over HTTP, Web services extend the SOA programming model into
the global Internet, allowing the publication, deployment, and discovery of
service applications over the Internet.
For more information on SOA and Web services, refer to:
http://www.ibm.com/software/solutions/webservices/resources.html
This Web site provides a collection of IBM resources on this topic. For example,
there is an introduction to the SOA in a white paper titled Web Services
Conceptual Architecture (WSCA 1.0).
7.3.4 Web services security
In April 2002, IBM and Microsoft proposed a technical strategy and roadmap for
“addressing security within a Web service environment.” The Web services
security specifications define a comprehensive Web service security model that
supports, integrates, and unifies several popular security models, mechanisms,
and technologies (including both symmetric and public key technologies) in a
way that enables a variety of systems to securely interoperate in a platform- and
language-neutral manner.
The Web services security specification provides a broad set of specifications
that cover security technologies, including authentication, authorization, privacy,
trust, integrity, confidentiality, secure communications channels, federation,
delegation, and auditing across a wide spectrum of application and business
topologies. These specifications provide a framework that is extensible and
flexible, and that maximizes existing investments in security infrastructure. By
leveraging the natural extensibility that is at the core of the Web services model,
Chapter 7. Technology options 133
the specifications build upon foundational technologies such as SOAP, WSDL,
XML Digital Signatures, XML Encryption, and SSL/TLS.
As shown in Figure 7-1, this set includes a message security model
(WS-Security) that provides the basis for the other security specifications.
Layered on this, we have a policy layer that includes a Web service endpoint
policy (WS-Policy), a trust model (WS-Trust), and a privacy model (WS-Privacy).
Together these initial specifications provide the foundation upon which we can
work to establish secure interoperable Web services across trust domains.
Figure 7-1 The evolving WS-Security roadmap
For more information, see the IBM developerWorks® article Security in a Web
Services World: A Proposed Architecture and Roadmap:
http://www.ibm.com/developerworks/webservices/library/ws-secmap/
WS-Security
Web Services Security (WS-Security) Version 1.0 was jointly developed by IBM,
Microsoft, and VeriSign, and was released in April 2002. It was submitted to
OASIS by 18 companies, and now involves over 50 companies.
WS-Security describes enhancements to SOAP messaging to provide quality of
protection through message integrity and message confidentiality. Also, this
specification defines how to attach and include security tokens within SOAP
messages. Finally, a mechanism is provided for specifying binary encoded
security tokens (for example, X.509 certificates). These mechanisms can be
used independently or in combination to accommodate a wide variety of security
models and encryption technologies.
For more information, see the IBM developerWorks article Web Services
Security (WS-Security):
http://www.ibm.com/developerworks/webservices/library/ws-secure/
Today
Time
WS-SecureConversation WS-Federation
WS-Policy WS-Trust WS-Privacy
WS-Security
SOAP Foundation
WS-Authorization
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.