![1.1. Virtual Enterprises
Most companies produce and sell products to their customers to achieve defined
business goals, such as specific financial targets. Their business processes prescribe
how products are designed, manufactured, marketed, distributed, and sold. From a
certain level of abstraction, a company's business processes are a direct reflection of
the products it offers. Therefore, the speed of changing the existing infrastructure or
creating new business processes corresponds to the speed of changing or creating
products.
To survive in highly dynamic markets and constantly changing environments,
companies must be flexible. Flexibility here means the ability to react quickly
(preferably faster than the competition) to new customer requirements, new
product offerings by existing and new competitors, technology advances, and so on.
The flexibility of an enterprise is a refection of its ability to adapt its business
processes quickly.
The constituents of the definition of a business process (see [Ley 2000]) translate
directly into actions that are necessary to alter business processes: changing the
flow of activities of a business process, changing the actors who are performing
these activities, changing the tools that support these activities, and so on. These
might result in moving the execution of (a subset of) the activities of the business
processes to partners. The result could be multiple business partners having to
cooperate to perform the business processes of a given company. The company in
fact becomes a virtual company (or virtual enterprise). This term indicates that
externally, the company looks like a real companyperforming all of its business
processes itselfbut in practice, that is not what is actually happening. Others are
partially running the company's business processes, making the company virtual in
this sense.
1.1.1. Business Process Optimization
The model of a business process prescribes the order in which a business must
execute the activities that constitute it and under which conditions it must perform
each of the activities. Collectively, this kind of prescription is called control flow. The
control flow massively influences business-relevant properties of a business
processsuch as its total cost and its overall durationand thus the competitiveness of
a company:
The execution of each step or activity within a business process is associated
with certain costs, such as people costs that are associated with the activity if
human intervention is required, or the cost of computer resources that are
required to execute activities within the IT environment. Based on this
information, a company can derive the overall cost for performing a business
process. For example, if policy associated with a credit allocation process
determines that someone must check credits with an amount greater than
$1,000, and more customers are asking for credits above this limit, a business](https://image.slidesharecdn.com/31740-250410162203-b22a3f1d/85/Web-Services-Platform-Architecture-SOAP-WSDL-WS-Policy-WS-Addressing-WS-BPEL-WS-Reliable-Messaging-and-More-1st-Edition-Sanjiva-Weerawarana-39-320.jpg)
![could change the policy to set manual intervention at a higher value to reduce
the overall costs for running the process.
Activities have temporal characteristics, such as the average duration for
executing an activity or the average time elapsed until an activity is picked up
and performed. Based on this information, you can derive the average interval
for executing a business process. For example, when you are booking a
business trip, you can reserve hotel and flight reservations in parallel, resulting
in a shorter execution time for the overall business process relative to its
sequential execution.
There are other business-relevant properties of business processes and the activities
they encompass. Changing the control flow of a business process might alter the
corresponding properties of the business process in an unexpected manner. For
example, introducing parallelism between activities might result in a longer duration
of the overall process in those cases in which the parallel activities compete for the
same resources (such as staff members who have rare skills).
Therefore, modeling a business process is a non-trivial endeavor, supported by
specialized design and analysis tools. After having modeled and optimized a
business process, it must be executed in exactly the way it was specified to ensure
the business properties that the process is optimized for. Special middleware is
available that enforces the correct and model-compliant executionso-called workflow
systems [Ley 2000]. Workflow systems allow monitoring of the business properties
of individual business processes or aggregations of business processes at runtime.
They also support the analysis of corresponding execution histories. Based on
monitoring and analysis of results, you can change the model of a business process,
if required, to further optimize it, especially when benchmarking shows that the
execution of a business process is not competitive in terms of its key business
parameters, such as cost or duration.
Sometimes, modifying the control flow of a business process is insufficient to hit the
target values for certain business properties. For example, the cost structure within
a company or wages for certain required staff might be too high to meet business
expense targets. In such situations, a company's business process cannot gain
competitiveness without significant re-engineering. The company (or a certain
branch or location within a company) should probably determine its core
competencies, focus on executing only the activities that correspond to these core
competencies, and outsource the noncore competencies. Of course, the constraint is
that outsourcing must result in hitting the target objectives of the subject business
properties. SOA and Web service technology facilitates this kind of outsourcing in a
secure, reliable manner.
1.1.2. Collaborations, Mergers, and Acquisitions
Figure 1-1 demonstrates an original process (denoted by "P") that a company runs.
The company determines that it is no longer competitive in performing activities A,
B, and E. It finds two partners that can run these activities and meet the business
goals. Partner 1 runs activities A and B, and Partner 2 runs activity E. The company](https://image.slidesharecdn.com/31740-250410162203-b22a3f1d/85/Web-Services-Platform-Architecture-SOAP-WSDL-WS-Policy-WS-Addressing-WS-BPEL-WS-Reliable-Messaging-and-More-1st-Edition-Sanjiva-Weerawarana-40-320.jpg)
![Mergers or acquisitions can have a deep impact on companies, and they, thus,
generally take a less radical approach. They determine appropriate partners and
negotiate long-term contracts for performing specific activities on behalf of the
outsourcing company. These contracts especially include service level-agreements,
which are specifications of service objectives such as availability of the outsourced
activities, penalties applied when objectives are not met, bonuses paid if the
objectives are overachieved, and so on [Dan 2004]. The result is a network of
collaborating partners.
Situations might be highly dynamic. Multiple partners might provide the same
services, and a company should choose on a case-by-case basis one of these to
perform specific activities. For example, the cost of performing activities on behalf of
a company might change depending on the actual load at each partner side. The
company can then determine the partner on a best-price basis.
Collaboration might not only result from process optimization endeavors, but from
supply chains that are typical within an industry. In this situation, a company and its
partners are not distinguished. All partners are peers, collaborating to realize an
overall business process that is spread over the partners. Some industries even
have standards to define the various kinds of partners, the activities each of them
runs, and how they relate. For example, RosettaNet [RN] defines such a standard
and is currently moving toward Web service technology [RNWS].
1.1.3. Resource Sharing
In addition to business process optimization, businesses outsource activities or
complete business processes for total cost of ownership considerations. Perhaps a
business process is competitive overall, but the overall cost for running parts of it on
IT equipment that the company owns is too high. In this situation, a company looks
for a partner to run the corresponding activities or the whole business process on
behalf of the company. This partner, also called application service provider (ASP),
not only runs parts of the business process on its IT equipment, but it also runs the
corresponding software, covering the whole spectrum from managing prerequisite
software to monitoring the software and performing periodic backups.
Web service technology, technology from the area of Grid computing that is based
on Web services, and autonomic computing facilitate the ASP model and extend it
toward a model called utility computing (see [Ley 2004], [Rappa 2004]). Within this
utility computing model, computer resources and other IT related resources are
offered in a similar manner to traditional utilities such as electricity or telephone.
The usage of the utility IT resources to run parts of a business process is metered
and charged on this basis. You will read more about this topic later.](https://image.slidesharecdn.com/31740-250410162203-b22a3f1d/85/Web-Services-Platform-Architecture-SOAP-WSDL-WS-Policy-WS-Addressing-WS-BPEL-WS-Reliable-Messaging-and-More-1st-Edition-Sanjiva-Weerawarana-42-320.jpg)
![1.2. The Need for Loose Coupling
Enabling communication with services, possibly dynamically discovered, requires
loose coupling between a requester and the service to be used. The notion of loose
coupling precludes any knowledge or assumptions about the specific platforms that
the requester or the service provider run on, specifics about the implementation
that either of the partners uses, or the formats and protocols used to interoperate
between them. Making such assumptions significantly limits the usefulness of a
service or the choice of services that might be available. The notion of loose
coupling is a fundamental underpinning of SOA. The following section sheds more
light on it.
1.2.1. Issues with Current Distributed System Technologies
Distributed system technology that has been developed in the past allows building
applications, the elements of which can run on different machines in a network.
However, dealing with the business scenarios outlined earlier has some other issues.
Fragility of Object Systems
Typically, current distributed system technology is centered on object technology. In
this case, a service is offered as a method of a class implemented by an object. A
requester who wants to use a service must tie the whole object into his application.
In other words, a person who needs a single function has to use the whole class
oreven worsethe whole class hierarchy within his program. When the class used or
the class above it in the class hierarchy changes, he must also change the
application that uses that class. The requester and the service are tightly coupled,
which means that the requester's application is fragile because of its association
with and dependence on this detail.
Lack of Interoperability
Today, different distributed system technologies such as Common Object Request
Broker Architecture (CORBA), Java 2 Platform, Enterprise Edition (J2EE), and
Component Object Model (COM) are based on quite different and incompatible
object models [Emm 2000]. As a result, interoperability between these platforms is
difficult. Communication between a requester on one platform and a service on
another is at best cumbersome, if it's possible at all. Not only are the object models
different, but higher-level frameworks (middleware) that support them (such as
transactions, security, management, and messaging) are also incompatible. This
significantly compounds the interoperability problem because you have to deal with
quality of service differences. These differences can include running a transaction
with participants on different platforms that operate incompatible transaction
services, which is not an easy task!](https://image.slidesharecdn.com/31740-250410162203-b22a3f1d/85/Web-Services-Platform-Architecture-SOAP-WSDL-WS-Policy-WS-Addressing-WS-BPEL-WS-Reliable-Messaging-and-More-1st-Edition-Sanjiva-Weerawarana-43-320.jpg)
![1.2.2. Advantages of Message-Oriented Middleware
A significant consequence of these interoperability problems is that islands of
middleware and corresponding applications that are based on this middleware have
been created. In parallel, the ability to easily integrate applications, especially from
different islands, has become a strong requirement (Enterprise Application
Integration EAI). In tandem, products that provide special integration middleware
have been created. A key aspect of such integration middleware is message
orientation.
Adapters and Channels
Message orientation refers to messages being exchanged between the applications
that are to be integrated. For this purpose, adapters wrap existing applications that
need to be integrated. One kind of adapter signals the occurrence of an event that
needs to be passed to other applications (source adapter), and another kind of
adapter receives such events and passes them to the application that they are
wrapping (target adapter). Events are represented by messages that are
transported via a so-called "channel" from the source adapter to a target adapter.
The channel ensures a certain quality of services, such as "exactly once delivery".
Also, the channel can have other side effects, such as transforming the message
into a format that the recipient understands. Figure 1-2 shows a source adapter A
that wraps application A. Adapter A passes a message of format M to the channel,
which transforms the message into format M' and delivers it reliably to target
adapter B. Adapter B in turn understands how to pass the data from M' to B. See
[Hohpe 2004] for additional perspectives in this space.
Figure 1-2. Message-based integration.
Based on this message-based architecture, applications A and B are loosely coupled.
For example, the owner of application A can change the format of message M,
generally without affecting his ability to integrate application B. The message M that
A produces can be appropriately transformed by the channel into the format M' that
B expects. A message-based approach like this fosters loose coupling.
Interaction Patterns](https://image.slidesharecdn.com/31740-250410162203-b22a3f1d/85/Web-Services-Platform-Architecture-SOAP-WSDL-WS-Policy-WS-Addressing-WS-BPEL-WS-Reliable-Messaging-and-More-1st-Edition-Sanjiva-Weerawarana-44-320.jpg)
![A package is a mere syntactic unit. To improve on and extend this concept further,
the notion of a class evolved. A class describes the behavior of objects from a
problem domain; therefore, it carries certain semantics in addition to being a
syntactic unit combining functions and data. Classes, together with the concept of
polymorphism and inheritance, have turned out to be a powerful concept for
building software. Polymorphism allows the resulting software to become more
flexible, whereas through inheritance, class lattices can be built that stimulate reuse
and ease communication among developers within a given community.
Although classes represent objects and carry some semantics, a class lattice mostly
captures syntaxnamely, the signature of the functions aggregated. The semantics
that a class lattice captures are typically understood only within a limited
community, such as a development team. Few class lattices are known, the
semantics of which are shared across larger communities.
In contrast to this, services are described not only via their interfaces, but also via
business terms. Thus, the semantics that a service description provides go beyond
that of a class and a class lattice. As such, services support comprehension by much
broader communities.
Components
Besides being coarser than objects and classes, components go further by dealing
with deployment. Addressing the issue of deployment allows a component provider
to focus specifically on application logic, while qualities of services are folded in by
the runtime environment that is hosting the component. For that purpose, quality of
service requirements are factored and parameterized by deployment descriptors
[J2EE]. By setting appropriate values in the deployment descriptors, you specify the
behavior of a component with respect to such things as transactions, security
checking, state management, and so on. In addition, you can resolve dependencies
on other components and resources (such as databases and queues) via
deployment descriptors. Finally, you can set up values governing application-specific
context (such as local tax rates) via deployment descriptors.
Dealing with these aspects of deployment eases customization. You can tailor a
piece of application logic to a company's specific use by setting values in
deployment descriptors accordingly. The container that is hosting the application
logic interprets the deployment descriptors and ensures the specified behavior. For a
customized context that the application logic requires, the deployment descriptor
provides the standardized contract. Deployment descriptors enable components to
become tradeable artifacts.
1.3.2. The Software Version of a Service
Services represent another step forward in the evolution of software packages.
Services can provide an abstraction of specific component models, allowing users of
these components to think only in terms of Web services and ignore specific details
of the component model and how it its implemented. For example, services can hide](https://image.slidesharecdn.com/31740-250410162203-b22a3f1d/85/Web-Services-Platform-Architecture-SOAP-WSDL-WS-Policy-WS-Addressing-WS-BPEL-WS-Reliable-Messaging-and-More-1st-Edition-Sanjiva-Weerawarana-48-320.jpg)
![the details about whether the component is a J2EE-based component or a .NET
based component. This provides significantly enhanced interoperability between
computing platforms that have programming models based on these differing
component models, such as WebSphere and .NET.
Characteristics of a Service
A service is available at a particular endpoint in the network, and it receives and
sends messages and exhibits behavior according to its specification. The service has
specific functionality and is deployed with appropriate quality of service at the
endpoint. (For example, the service is set up with certain transactional or security or
reliable messaging behavior.) The functional aspects of a service are specified using
WSDL, and the constraints and conditions that are associated with the use of the
service are specified via policies that you can attach to various parts of the WSDL
(see chapter 7). Interfaces and policies describe the terms and conditions that
govern the use of the service. These are published so that potential users of the
service can discover and be given all the information they need to bind (perhaps
dynamically) to that service.
The information that is published about a service provides details of what the
service is and does (its semantics). It further provides all the information that allows
the environment hosting a potential user to access the service and successfully
interact with it. This can include information about the transport protocols that can
be supported and used to send a messages to the service, the wire format of this
message expected by the service, whether and how the message has to be
encrypted or signed.
Although the environment that is hosting needs this information, the requester
doesn't need this kind of access information, and it certainly doesn't need to
understand details about the implementation of the service. You can implement this
service as an EJB, a database stored procedure, or a CICS or IMS transaction made
available via a wrapper. The environment that is hosting the service and receiving
the request message, often referred to as a container, must deal with that detail
necessary to interact with a particular implementation. The requester can think in
terms of using a Web service. In that sense, Web service technology is virtualization
technology for making use of services, but an implementer of a service can use the
technology he is acquainted with to build the service implementation.
SolutionsComposition of Services
One valuable aspect of the services model is that you can create new services from
existing ones without leaving the service paradigm. A technology called
choreography facilitates the composition and orchestration of the execution of
existing services to create more powerful ones (see Chapter 14, "Modeling Business
Processes: BPEL"). Choreographies support the idea of programming in the large
(see [Ley 2004], [Ley 1997], [Wied 1992]), which fosters the creation of new
functionality, in particular by non-IT personnel.](https://image.slidesharecdn.com/31740-250410162203-b22a3f1d/85/Web-Services-Platform-Architecture-SOAP-WSDL-WS-Policy-WS-Addressing-WS-BPEL-WS-Reliable-Messaging-and-More-1st-Edition-Sanjiva-Weerawarana-49-320.jpg)
![Mr Ewing could pronounce backwards, though he could notâthe
various sounds could also be distinguished. Words and sentences
which when pronounced backwards or forwards sound the same,
were tried. Thus was tried the well-known sentence, âMadam, Iâm
Adam,â with which Adam is traditionally alleged to have saluted Eve;
but âMadam, Iâm Adam,â although spelt the same both ways, did not
sound the same in the phonograph, the diphthongal sound of the
âIâmâ giving a sound like âmya.â It is obvious from Professor Fleeming
Jenkinâs experiments that some interesting points in acoustics may
yet be settled by means of this extraordinary instrument.
Printed and Published by W. & R. Chambers, 47 Paternoster Row,
London, and 339 High Street, Edinburgh.
All Rights Reserved.
[Transcriberâs note: the following changes have been made to this
text.
Page 206: repeated word âanâ correctedââan hour and reportâ.]](https://image.slidesharecdn.com/31740-250410162203-b22a3f1d/85/Web-Services-Platform-Architecture-SOAP-WSDL-WS-Policy-WS-Addressing-WS-BPEL-WS-Reliable-Messaging-and-More-1st-Edition-Sanjiva-Weerawarana-52-320.jpg)
Web Services Platform Architecture SOAP WSDL WS Policy WS Addressing WS BPEL WS Reliable Messaging and More 1st Edition Sanjiva Weerawarana
- 1. Web Services Platform Architecture SOAP WSDL WS Policy WS Addressing WS BPEL WS Reliable Messaging and More 1st Edition Sanjiva Weerawarana pdf download https://ebookgate.com/product/web-services-platform-architecture- soap-wsdl-ws-policy-ws-addressing-ws-bpel-ws-reliable-messaging- and-more-1st-edition-sanjiva-weerawarana/ Get Instant Ebook Downloads â Browse at https://ebookgate.com
- 2. Instant digital products (PDF, ePub, MOBI) available Download now and explore formats that suit you... SOA and WS BPEL 1st Ed. Edition Yuli Vasiliev https://ebookgate.com/product/soa-and-ws-bpel-1st-ed-edition-yuli- vasiliev/ ebookgate.com Building Interoperable Web Services using the WS I Basic Profile 1 0 Patterns Practices 1st Edition Microsoft Corporation https://ebookgate.com/product/building-interoperable-web-services- using-the-ws-i-basic-profile-1-0-patterns-practices-1st-edition- microsoft-corporation/ ebookgate.com SOA Governance in Action REST and WS Architectures Jos Dirksen https://ebookgate.com/product/soa-governance-in-action-rest-and-ws- architectures-jos-dirksen/ ebookgate.com Topological Library Part 1 Cobordisms and Their Applications WS 2007 1st Edition S. P. Novikov https://ebookgate.com/product/topological-library-part-1-cobordisms- and-their-applications-ws-2007-1st-edition-s-p-novikov/ ebookgate.com
- 3. Building Web services with Java making sense of XML SOAP WSDL and UDDI 2nd ed Edition Graham https://ebookgate.com/product/building-web-services-with-java-making- sense-of-xml-soap-wsdl-and-uddi-2nd-ed-edition-graham/ ebookgate.com Building Web Services with Java Making Sense of XML SOAP WSDL and UDDI 2nd Edition Steve Graham https://ebookgate.com/product/building-web-services-with-java-making- sense-of-xml-soap-wsdl-and-uddi-2nd-edition-steve-graham/ ebookgate.com Mobile Messaging Technologies and Services SMS EMS and MMS Second Edition Gwenael Le Bodic(Auth.) https://ebookgate.com/product/mobile-messaging-technologies-and- services-sms-ems-and-mms-second-edition-gwenael-le-bodicauth/ ebookgate.com Addressing Racial Disproportionality and Disparities in Human Services Multisystemic Approaches Rowena Fong (Editor) https://ebookgate.com/product/addressing-racial-disproportionality- and-disparities-in-human-services-multisystemic-approaches-rowena- fong-editor/ ebookgate.com Service Oriented Architecture with Java Using SOA and web services to build powerful Java applications First Edition Christudas https://ebookgate.com/product/service-oriented-architecture-with-java- using-soa-and-web-services-to-build-powerful-java-applications-first- edition-christudas/ ebookgate.com
- 5. Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More By Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey, Donald F. Ferguson ............................................... Publisher: Prentice Hall PTR Pub Date: March 22, 2005 Print ISBN: 0-13-148874-0 Pages: 456 Table of Contents | Index The Insider's Guide to Building Breakthrough Services with Today's New Web Services PlatformUsing today's new Web services platform, you can build services that are secure, reliable, efficient at handling transactions, and well suited to your evolving service-oriented architecture. What's more, you can do all that without compromising the simplicity or interoperability that made Web services so attractive. Now, for the first time, the experts who helped define and architect this platform show you exactly how to make the most of it.Unlike other books, Web Services Platform Architecture covers the entire platform. The authors illuminate every specification that's ready for practical use, covering messaging, metadata, security, discovery, quality of service, business-process modeling, and more. Drawing on realistic examples and case studies, they present a powerfully coherent view of how all these specifications fit togetherand how to combine them to solve real-world problems. Service orientation: Clarifying the business and technical value propositions Web services messaging framework: Using SOAP and WS-Addressing to deliver Web services messages WSDL: Documenting messages and supporting diverse message interactions WS-Policy: Building services that specify their requirements and capabilities, and how to interface with them UDDI: Aggregating metadata and making it easily available WS-MetadataExchange: Bootstrapping efficient, customized communication between Web services WS-Reliable Messaging: Ensuring message delivery across unreliable networks Transactions: Defining reliable interactions with WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity Security: Understanding the roles of WS-Security, WS-Trust, WS-SecureConversation, and WS-Federation BPEL: Modeling and executing business processes as service compositionsWeb Services Platform Architecture gives you an insider's view of the platform that will change the way you deliver applications. Whether you're an architect, developer, technical manager, or consultant, you'll find it indispensable.Sanjiva
- 6. Weerawarana, research staff member for the component systems group at IBM Research, helps define and coordinate IBM's Web services technical strategy and activities. A member of the Apache Software Foundation, he contributed to many specifications including the SOAP 1.1 and WSDL 1.1 specifications and built their first implementations. Francisco Curbera, IBM research staff member and component systems group manager, coauthored BPEL4WS, WS-Addressing, and other specifications. He represents IBM on the BPEL and Web Services Addressing working groups. Frank Leymann directs the Institute of Architecture of Application Systems at the University of Stuttgart. As an IBM distinguished engineer, he helped architect IBM's middleware stack and define IBM's On Demand Computing strategy. IBM Fellow Tony Storey has helped lead the development of many of IBM's middleware, Web services, and grid computing products. IBM Fellow Donald F. Ferguson is chief architect and technical lead for IBM Software Group, and chairs IBM's SWG Architecture Board.
- 7. Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More By Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey, Donald F. Ferguson ............................................... Publisher: Prentice Hall PTR Pub Date: March 22, 2005 Print ISBN: 0-13-148874-0 Pages: 456 Table of Contents | Index Copyright Praise for Web Services Platform Architecture Foreword by Steve Mills Foreword by Ronald Schmelzer Preface Who Should Read this Book? Acknowledgments About the Authors Part 1: Introduction Chapter 1. Service-Oriented Architectures Section 1.1. Virtual Enterprises Section 1.2. The Need for Loose Coupling Section 1.3. What Is a Service? Section 1.4. Service-Oriented Architecture Section 1.5. Summary Chapter 2. Background Section 2.1. XML Section 2.2. World Wide Web Section 2.3. Summary Chapter 3. Web Services: A Realization of SOA Section 3.1. Scope of the Architecture
- 8. Section 3.2. Transport Services Section 3.3. Messaging Services Section 3.4. Service Description Section 3.5. Discovery Services Section 3.6. Quality of Service Section 3.7. Service Components Section 3.8. Composeability Section 3.9. Interoperability Section 3.10. REST Section 3.11. Scope of Applicability of SOA and Web Service Section 3.12. Summary Part 2: Messaging Framework Chapter 4. SOAP Section 4.1. A Brief History of SOAP Section 4.2. Architectural Concepts Section 4.3. SOAP Attachments Section 4.4. Differences Between SOAP 1.1 and 1.2 Section 4.5. Summary Chapter 5. Web Services Addressing Section 5.1. Addressing Web Services Section 5.2. Architectural Concepts Section 5.3. Example Section 5.4. Future Directions Section 5.5. Summary Part 3: Describing Metadata Chapter 6. Web Services Description Language (WSDL) Section 6.1. Role of WSDL in WS-*/SOA Section 6.2. History Section 6.3. Architectural Concepts Section 6.4. WSDL 1.1 Section 6.5. WSDL v2.0 Section 6.6. Future Directions Section 6.7. Summary Chapter 7. Web Services Policy Section 7.1. Motivation for WS-Policy Section 7.2. Architectural Concepts Section 7.3. Future Directions Section 7.4. Summary
- 9. Part 4: Discovering Metadata Chapter 8. Universal Description, Discovery, and Integration (UDDI) Section 8.1. Role of UDDI in SOA and the WS Stack Section 8.2. Motivation for UDDI Section 8.3. Architectural Concepts Section 8.4. Future Directions Section 8.5. Summary Chapter 9. Web Services Metadata Exchange Section 9.1. Architectural Concepts Section 9.2. Future Directions Section 9.3. Summary Part 5: Reliable Interaction Chapter 10. Reliable Messaging Section 10.1. Motivation for Reliable Messaging Section 10.2. Reliable Messaging Scenarios Section 10.3. Architectural Concepts Section 10.4. Processing Model Section 10.5. Strengths and Weaknesses Section 10.6. Examples Section 10.7. Future Directions Section 10.8. Summary Chapter 11. Transactions Section 11.1. Role of Transactions in Web Services/SOA Section 11.2. Motivation for Transactions Section 11.3. Architectural Concepts Section 11.4. Example Section 11.5. Summary Part 6: Security Chapter 12. Security Section 12.1. A Motivating Example: Travel Agent Web Services Section 12.2. Roles of Security in Web Services Section 12.3. Motivation for Using WS-Security Section 12.4. End-to-End Security When Intermediaries Are Present Section 12.5. Federating Multiple Security Domains Section 12.6. A Brief History Section 12.7. Architectural Concepts Section 12.8. Processing Model Section 12.9. Putting the Pieces Together
- 10. Section 12.10. Interoperability Section 12.11. Future Directions Section 12.12. Summary Chapter 13. Advanced Security Section 13.1. WS-Trust Section 13.2. WS-SecureConversation Section 13.3. WS-Privacy Section 13.4. WS-Federation Section 13.5. WS-Authorization Section 13.6. Web Services Authorization Model Section 13.7. Security and Policy Section 13.8. Assertion Model Section 13.9. Other Security Topics Section 13.10. Non-Repudiation Section 13.11. Summary Part 7: Service Composition Chapter 14. Modeling Business Processes: BPEL Section 14.1. Motivation for BPEL Section 14.2. Architectural Concepts Section 14.3. BPEL Processing Model Section 14.4. Future Directions Section 14.5. Summary Part 8: Case Studies Chapter 15. Case Study: Car Parts Supply Chain Section 15.1. Scenario Description Section 15.2. Architecture Section 15.3. Web Service Descriptions Section 15.4. Messages and Protocols Section 15.5. Summary Chapter 16. Case Study: Ordering Service Packs Section 16.1. Scenario Description Section 16.2. Architecture Section 16.3. Web Service Descriptions Section 16.4. Messages and Protocols Section 16.5. Summary Part 9: Conclusion Chapter 17. Futures Section 17.1. Semantics
- 11. Section 17.2. Wiring Section 17.3. Ordering Constraints Section 17.4. Contracting Section 17.5. Summary Chapter 18. Conclusion Section 18.1. A Summary of the Web Services Platform Section 18.2. Standardization Section 18.3. Competing Specifications Section 18.4. Perspectives Section 18.5. Building on the Core Platform Section 18.6. Summary Appendix A References Index
- 13. Copyright Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U. S. Corporate and Government Sales (800) 382-3419 corpsales@pearsontechgroup.com For sales outside the U. S., please contact: International Sales international@pearsoned.com Visit us on the Web: www.phptr.com Library of Congress Catalog Number: 2004116713 Copyright Š 2005 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc. Rights and Contracts Department One Lake Street Upper Saddle River, NJ 07458 Text printed in the United States on recycled paper at R.R. Donnelley and Sons Company in Crawfordsville, Indiana.
- 14. First printing, March 2005 Dedication To my parents, Kamal and Ruby Fernando, for their trust and support to send me to a university in the U.S., which enabled me to do all of this. And to my wife, Shahani, and children, Rukmal, Sashi, and Rukshi, for their tolerance of my crazy life. Sanjiva Weerawarana To my wife and my daughters. Francisco Curbera To Susanne and Lukas: Thanks for your patience and love. Frank Leymann To my wife, Jacky, and my two sons, Peter and David, for their patience and understanding of the things that motivate and drive my life. Tony Storey To Kaitlin and Kristen. Donald F. Ferguson
- 16. Praise for Web Services Platform Architecture "Other books claim to present the complete Web services platform architecture, but this is the first one I've seen that really does. The authors have been intimately involved in the creation of the architecture. Who better to write this book?" Anne Thomas Manes, vice president and research director, Burton Group "This is a very important book, providing a lot of technical detail and background that very few (if any) other books will be able to provide. The list of authors includes some of the top experts in the various specifications covered, and they have done an excellent job explaining the background motivation for and pertinent details of each specification. The benefit of their perspectives and collective expertise alone make the book worth reading." Eric Newcomer, CTO, IONA Technologies "Most Web services books barely cover the basics, but this book informs practitioners of the 'real-world' Web services aspects that they need to know to build real applications. The authors are well-known technical leaders in the Web services community and they helped write the Web services specifications covered in this book. Anyone who wants to do serious Web services development should read this book." Steve Vinoski, chief engineer, Product Innovation, IONA Technologies "There aren't many books that are as ambitious as this one is. The most notable distinguishing factor of this book is that the authors have tried to pare down the specifications for the user and rather than focusing on competing specifications, they focus on complementary ones. Nearly every chapter provides a business justification and need for each feature discussed in the Web services stack. I would recommend this book to developers, integrators, and architects." Daniel Edgar, systems architect, Portland General Electric
- 18. Foreword by Steve Mills Web services are about enabling complete business-level interoperability across vendor middleware platforms. Starting with the first baby stepsin the form of SOAPmore than five years ago, I have seen the industry moving steadily toward this integration platform with the introduction of one key component after another. While we are not completely there yet, I am confident that a solid technical foundation has been laid and that now the community building process is under way. This book is about that technical foundation. Starting with an explanation of some of the motivating factors driving customers toward full, in-depth integration of middleware platforms, the authors take you through the entire Web services platform and give you an understanding of why this platform effectively solves the integration problem. Two case studies, one in a business-to-business setting and the other in an enterprise application integration setting, illustrate how the Web services platform can be effectively applied to meet all the integration requirements. Finally, the authors provide an outlook of what is still coming down the pipe, in terms of both the short-term and long-term evolution of the integration space. While there are dozens of books out there about Web services, this book is unique for two critical reasons: it is the first book to provide comprehensive coverage of the entire Web services platform; and, rather than providing an unguided explanation of a plethora of "WS-*" specifications, the authors make subjective judgment calls on which specifications are core to the platform and which are not. Their bold assertions of what is core to the platform makes it clear that the Web services platform has a clear underlying architecture and that it is not just a collection of specifications, as is commonly held. The second reason above hints at a key reason for why this book is extremely unique: the authors are in fact the very same people who have been involved with defining all of the specifications that comprise the Web services platform. This is as "from the horse's mouth" as it can ever get! Given the importance of true interoperability across vendor platforms, no one can afford to not fully understand Web services. I suspect this book will be a key milestone in your travels down the Web services roads. Steve Mills Senior VP and Group Executive IBM Software Group December 2004
- 20. Foreword by Ronald Schmelzer One of the constant struggles for enterprises of all types, sizes, and industries is the ability for their Information Technology (IT) systems to meet their evolving business needs. Because most enterprises' IT systems are a hodgepodge of systems of different types, ages, architectures, and technologies, companies must continue to invest in their increasingly complex IT infrastructure while seeing gradually diminishing benefits. At times, it seems that the more that companies spend on IT, the less business benefit they receive, because more time is spent on making existing systems talk to each other rather than on making them accomplish new, productive tasks for the enterprise. Part of the reason for the ongoing IT problem is that companies don't make technology and architecture decisions all at once. Rather, most companies have to make IT decisions as they go using the best information and reasoning they have at the time. At times, these decisions are made due to expediency, and at other times, the decisions are made for strategic reasons that are lost when the company goes through significant change, such as a merger or acquisition, or during a period of significant economic downturn. As a result, many of these IT decisions result in significant expense for the company. Furthermore, as a company accumulates IT assets, new technologies emerge that seem to make older ones implemented in the enterprise obsolete. However, companies are loathe to throw out their previous IT investments (legacy systems) and replace them with new systems, and as a result, these companies are faced with trying to make their old systems work in new environments. So, rather than simplifying their IT ecosystems over time, the problem only grows more complicated, more expensive, and more inflexible as new systems are introduced. This problem of heterogeneity is at the core of why integration challenges continue to plague so many organizations. To solve these problems, companies need two sorts of solutions: technology solutions that aim to simplify integration problems through a combination of standards-based interoperability and enable reuse of legacy environments, and architectural solutions that aim to change the way in which companies build, deploy, manage, secure, and scale their IT systems. While the latter solution requires changes in IT management, structure, and governance, the former solution requires a standards-based, comprehensive technology platform for working in a heterogeneous IT environment. Web services-based Service-Oriented Architectures (SOA) hope to provide both of the above sorts of solutions to the enduring problem of IT inflexibility. Smart enterprises are increasingly realizing that the real value in Web services is in using loosely coupled, standards-based technologies to build SOAs. Many enterprises have achieved success implementing Web services to solve point-to- point integration problems and are now looking to leverage the power and flexibility of Web services strategically across the enterprise, which means building loosely coupled, standards-based SOAs.
- 21. The power and flexibility that SOAs can offer the enterprise are substantial. If an organization abstracts its IT infrastructure so that it presents its functionality in the form of coarse-grained services that offer clear business value, then the consumers of those services (whether they are with the same company or one of that company's business partners) can access those services independent of the underlying technology that supports them. Furthermore, if service consumers can dynamically discover and bind to available services in an agile mannerbuilding applications out of composed servicesthen the IT infrastructure behind those services can offer extraordinary flexibility to the businesses that invoke them. The difference between the practice of SOA and other approaches to enterprise architecture is in the business agility that SOA offers. Companies have become used to the fact that IT decision making and implementations impede their organization and that technology and its limitations often drive business decisions. Service orientation, however, has the potential to change this equation and enable business decisions to finally drive their technology decisions. Business agility is the ability of a company to respond quickly and efficiently to change and to leverage change for competitive advantage. For the architect, building an architecture that provides business agility means creating an IT infrastructure that meets as-yet unknown business requirementsa situation that throws traditional IT planning and design out the window. Today's distributed computing transition, while every bit as significant as the ones that came before, has an entirely different economic model. Instead of massive IT investment, today's IT executive is concerned with thrift. Thrift depends on one of the holy grails of software development: code reuse. In an SOA, developers should construct the services to be as simple as possible, where they continually refactor them so that they are as broadly applicable as is practical. The resulting services are then reusable at runtimeboth fine- and coarse-grained nuggets of software functionality that can be used in a variety of situations, as contrasted to typical code reuse, which is a design time principle. Once the SOA is in place, new business requirements will continue to generate the need for new and updated services. The IT staff can then make the required changes on an ongoing basis. In addition, taking an ad hoc upgrade approach to services, which are composed into business applications, reduces the need to "rip and replace" large portions of the IT infrastructure. Companies thus only consider a rip and replace strategy as a last resort, and then only within a service orientation context. There is an additional, related concept to broad applicability that goes even further: the concept of consumability. It's not enough for a service to have the potential to be used in a variety of situations; it must actually be usable. Not only must the service's functionality be technically applicable to various situations, but people must know about the service, understand its use, and be able to find it when they need it. As such, technologies such as repositories and metadata management tools are rapidly becoming as important as the runtime and design-time infrastructure for the services themselves. While the concepts of SOAs sound compelling to most enterprises, building service- oriented infrastructures is not easy. That is why this book, Web Services Platform
- 22. Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging and More, is such an important and critical reading. In this book, Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey, and Donald Ferguson make the effective argument that Web services and SOA are required technologies that help businesses meet their continually evolving requirements. The book offers not only implementation-level coverage of the technologies and specs as required by technical developers, it also provides the right technical context for business readers. An emerging audience of "enterprise architects," which are more business focused than developers, yet tasked with more specific technical requirements than purely line-of-business users, will find significant value in the book. This book gives these users the ammunition to discuss the topics with their more technical developers, and the nuts-and-bolts to implement higher-level concepts decided by their more business-level superiors. In the first chapter, the authors make the correct observation that SOA is a new paradigm shift that requires not only a change of technology, but also a cultural mind shift in how to create, manage, secure, and deploy service assets in the network. The concepts are on targetcorrectly mapping the business driver of agility, or flexibility, to the technical capabilities of an SOA to enable rapid change with low economic penalty. The book then continues to discuss business flexibility in the abstract while tying the concepts to specific notions of the business process. As the book progresses, the reader will learn incrementally more about the basic, core Web services specificationsSOAP, WSDL, and UDDI, as well as the XML-based underpinnings of those formats. What makes this book stand out are its detailed discussion on emerging specifications, including WS-Policy, WS-Addressing, WS- ReliableMessaging, WS-AtomicTransaction, WS-BusinessActivity, as well as the BPEL specification, whichwhile still emerging specifications as of the time of writing this forewordwill surely be the formative specifications for SOA in the future. In addition, the authors spend a considerable amount of time discussing the practical implementations of SOA, especially in a messaging-centric context. Their discussions can immediately be applied to a wide range of message-oriented middleware approaches as well as emerging Enterprise Service Bus implementations. In fact, what makes this book credible is the experience of the authors. The authors, hailing from the pioneering software group at IBM, have not only rich experience with Web services and SOA, but have also been involved in the creation of the specs themselves. As such, the authors not only bring their experience in implementing Web services and SOA at IBM, but also their experience in crafting the very specifications they outline in the bookthis book is an "insider's" guide to Web services and SOA, if you will. In conclusion, service orientation represents the next major trend in enterprise computing, and as a result, requires a new perspective, new techniques, and new tools for implementing technology solutions that meet the needs of business. At this point in time, the IT industry stands at a cuspa tipping point where sporadic applications of Web services become a movement toward agile, thrifty computing based on SOAs. When people stand at such a threshold, they often have a difficult
- 23. time planning for the future because many of the business patterns that have applied in the past may no longer apply. It is our hope that through learning the basic precepts of SOA and Web services and the detail required to implement them in your most important applications, you can become informed and educated enough to participate and lead the revolution that SOA means to the enterprise. Ronald Schmelzer Senior Analyst ZapThink, LLC December 2004
- 25. Preface "Web services are a mess!" "There are more than 150 Web services (WS-*) specs!" "Simple? This stuff is more complicated than CORBA!" "There is no architecture; just a bunch of competing specs!" "These specs are denser than plutonium!" Those are some of the statements we've heard from peopleincluding our own colleaguesabout Web services. That's why we wrote this book: to show that the WS- * platform is not a random walk through a space of WS-* specifications but rather an organized, structured architecture with well-defined design and architectural objectives. We apply these objectives when working on WS-* specifications and when deciding whether or not we need a new specification in a certain area. The objective of this book is to present the cohesive, structured architecture of the Web services platform that we have been helping to define. The architecture is designed to enable loosely coupled interaction between services with business- quality reliability, security, and transactional capabilities. We start by presenting some of the business worlddriving forces that are motivating the creation of the service-oriented computing platform (Chapter 1, "Service-Oriented Architectures"). Then we focus on Web services as a realization of this service-oriented computing platform and indicate which specifications contribute to the platform (Chapter 3, "Web Services"). After that, we consider each major part of the platform and offer the insight that went into defining the specifications that govern that component. We cover the messaging framework, describing metadata, reliable interaction, security, and service composition in different parts of the book. Before concluding, we consider two case studies to illustrate how the Web services platform can address both intranet and extranet integration scenarios. In the concluding part, we summarize the platform and give our perspectives on why the integrated architecture we present makes sense and will "win" the standards battle. Finally, we present our thoughts on the future of the Web services platform. At the end of this book, you should no longer feel that Web services has no architecture or that the architecture is hidden somewhere between 150+ WS-* specifications. You might not agree with our choice of components that comprise the architecture, but we chose the set based on the fact that those were designed from the ground up to work together to solve a single problem: that of being a ubiquitous platform for integrating heterogeneous systems to enable rich business communication.
- 26. Who Should Read this Book? We wrote this book for technical professionals and students. Although Chapter 2, "Background," briefly introduces the requisite background material about major XML technologies, we assume that you have a fair grasp of those technologies coming into this book. Developers who want to understand the overall Web services platform will appreciate this book. However, this is not a "developer book" in the sense of providing detailed, code-level understanding. That was not our objective. Architects, consultants, and technically oriented management should find this book useful. Students who have already attended introductory courses in distributed systems or database systems will be able to understand the Web services platform.
- 28. Acknowledgments This book is the result of the contributions of numerous people. We would especially like to acknowledge and pay tribute to our many colleagues in IBM, too numerous to mention individually, who work alongside us in this fascinating area on a daily basis and whose innovation and stimulus have been a significant factor in making Web services a reality. Within that group of people, we would particularly like to thank Bob Sutor, Karla Norsworthy, Diane Jordan, Dan House, and Greg Clarke, who worked tirelessly in helping to bring this work to the world at large in the form of specifications and standards. We would like to thank Eric Newcomer of IONA Technologies, Daniel Edgar of Portland General Electric, Ronald Schmelzer of ZapThink LLC, and Max Loukianov of Netprise Corp, for their insightful reviews and comments of earlier drafts of this book. Also thanks to Mark Little of Arjuna Technologies, with whom we had extensive helpful dialogue on wide-ranging Web servicesrelated topics. Their input and comments brought about significant improvements and additions to the published version. We're also grateful to the many people in the IT industryin particular our customers who've listened to what we had to say about this subject over the years and provided feedback that has helped to fashion our views about SOA and Web services. This book is also the result of collaboration with colleagues at Microsoft. We would like to acknowledge their contributions to the specifications that helped realize the vision outlined in this book. We would also like to thank everyone on the publishing team for their excellent guidance on the focus of the book, for their help in realizing this project, and particularly for their patience in an endeavor that was more difficult than we had anticipated.
- 30. About the Authors This book was a team effort by the folks at IBM who have been working on designing and building the Web services platform. The lead authors of this bookSanjiva, Francisco (Paco), Frank, Tony, and Donwrote parts of the book and coordinated contributions from the others. We'll start with descriptions of the five lead authors and then talk about the others who contributed. Sanjiva Weerawarana received a Ph.D. in computer science from Purdue University in 1994. After a few years at Purdue as visiting faculty, he joined IBM Research in 1997, where he is a research staff member in the Component Systems Group and a member of the IBM Academy of Technology. Sanjiva's research interests are in component-oriented programming in general and specifically about component-oriented distributed computing architectures. He got involved with the Web services stack early by contributing to SOAP 1.1 and then by building the first implementation of it, which was later released to the Apache Software Foundation to start the Apache SOAP open source project. After that, Sanjiva cocreated WSDL (with Paco) and coauthored many Web services specifications, including WS- Addressing, WS-MetadataExchange, BPEL4WS, and WS-Resource Framework. In addition to developing specifications, Sanjiva has implemented many of them, in addition to technologies that are related to Web services, including Apache WSIF and the Web Services Gateway. He has been an active contributor to IBM's technical strategy for Web services and has helped coordinate IBM's Web services activities for the past five years. After Web services, Sanjiva's second love is open source, where he's a member of the Apache Software Foundation and the cofounder of the Lanka Software Foundation, an open source foundation in Sri Lanka. In his leisure time, he teaches at the University of Moratuwa, Sri Lanka, where he lives and telecommutes to his job in New York. You can e-mail Sanjiva at sanjiva@watson.ibm.com or sanjiva@opensource.lk. Francisco Curbera is a research staff member and manager of the Component Systems Group at the IBM T.J. Watson Research Center in Hawthorne, New York, where he has worked since 1993. He holds a Ph.D. in computer science from Columbia University. His current research interests are in the use of component- oriented software in distributed computing system. In the past, he has worked in the design of algorithms and tools for processing XML documents, and in the use of markup languages for automatic UI generation. He has worked in different Web services specifications since the initial Web services concept surfaced in late 1999, first as one of the original authors of the Apache SOAP implementation of SOAP 1.1, and then as coauthor of WSDL 1.1, BPEL4WS, WS-Policy, and WS- PolicyAttachments, WS-Addressing, WS-MetadataExchange, and other Web services specifications. He currently represents IBM in the Web Services Addressing working group, standardizing WS-Addressing at the W3C, and in the Web Services Business Process technical committee standardizing BPEL4WS at OASIS. You can reach Paco at curbera@us.ibm.com. Frank Leymann is a professor of computer science and the director of the Institute of Architecture of Application Systems at the University of Stuttgart, Germany. His research interests include service-oriented computing, workflow and business
- 31. process management, transaction processing, and architecture patterns. Before taking over as a professor, Frank worked for two decades at IBM Software Group in the development of database and middleware products. During that time, he built tools that support conceptual and physical database design for DB2, as well as performance prediction and monitoring, co-architected a repository system, built both a universal relation system and a complex object database system on top of DB2, and was coarchitect of the MQSeries family. In parallel to that, Frank has worked continuously since the late 1980s on workflow technology and has become the father of IBM's workflow product set. As an IBM Distinguished Engineer and elected member of the IBM Academy of Technology, he has contributed to the architecture and strategy of IBM's middleware stack and IBM's on-demand computing strategy. From 2000 on, Frank worked as coarchitect of the Web service stack. He is coauthor of many Web service specifications, including WSFL, WS- Addressing, WS-Metadata Exchange, WS-Business Activity, and the WS-Resource Framework set of specifications. Together with Satish Thatte, he was the driving force behind BPEL4WS. Frank has published many papers in journals and proceedings, co-authored two other text books, and holds numerous patents. You can reach Frank at Frank.Leymann@informatik.uni-stuttgart.de or LEY1@de.ibm.com. Tony Storey is an IBM Fellow, Fellow of the Royal Academy of Engineering, and Fellow of the Institute of Electrical Engineering. He graduated from the Royal Institute of Chemistry and received his doctorate from the University of Durham. Tony joined IBM at the UK Scientific Centre and spent some years there in pioneering work on relational database technology. Subsequently, he has worked for more than two decades in the IBM development laboratory at Hursley, engaged in the development of distributed computing and middleware. He has played a leading role in the creation and development of many of IBM's world-leading middleware products, such as Customer Information Control System (CICS) and MQSeries. He was a key contributor to the development of Java specifications and technology for use in enterprise computing environments for which he earned a corporate award. Tony has most recently helped develop Web services and Grid computing within IBM and more broadly across the industry. He is a coauthor of many Web services specifications, in particular the transaction and messaging specifications. He is actively involved in providing guidance to the UK e-Science strategy that leverages a significant portion of the Web services infrastructure covered in this book. Prior to joining IBM, he worked in the development of Real Time computing systems for military applications. You can e-mail Tony at tony_storey@uk.ibm.com. Donald F. Ferguson is one of approximately 55 IBM Fellows, the company's highest technical position, in its engineering community of 190,000 technical professionals. He is the chief architect and technical lead for IBM's Software Group family of products, and he chairs the SWG Architecture Board. Don's most recent efforts have focused on Web services, business process management, Grid services, and application development. He earned a Ph.D. in computer science from Columbia University in 1989. His thesis studied the application of economic models to the management of system resources in distributed systems. Don joined IBM Research in 1987 and initially led research and advanced development efforts in several areas of system performance and management. Starting in 1993, Don started focusing his efforts in the area of distributed, Object-Oriented systems. This work focused on CORBA-based SM solutions and frameworks and evolved into an effort to define
- 32. frameworks and system structure for CORBA-based object transaction monitors. The early design and prototype of these systems produced the IBM Component Broker and WebSphere family of products. Don has earned two corporate awards (EJB Specification, WebSphere), four outstanding technical awards, and several division awards at IBM. He was the coprogram committee chairman for the First International Conference on Information and Computation Economies. He received a best paper award for his work on database buffer pools, has written more than 24 technical publications, and has nine granted or pending patents. In addition, he has given approximately 15 invited keynote speeches at technical conferences. Don was elected to the IBM Academy of Technology in 1997 and was named a Distinguished Engineer on April Fool's Day, 1998. No one is sure if the joke was on IBM or Don. Don was named an IBM Fellow on May 30, 2001. You can reach him at dff@us.ibm.com. A team of 10 other writers coauthored specific chapters whose underlying technology they helped create. We provide their bios in alphabetical order here. John Colgrave is a senior software engineer based in IBM's Hursley Laboratory in the United Kingdom. He has a B.S. degree in electrical and electronic engineering and an M.S. degree in computer science. Both degrees are from Manchester University. John has 20 years of experience in the architecture, design, and development of distributed systems and middleware. He is an active member of the OASIS UDDI Specification Technical Committee. He has authored several technical notes and contributed to the main UDDI specification. He is the architect of the IBM implementation of UDDI Version 3. You can contact John at colgrave@uk.ibm.com. Christopher Ferris is a senior technical staff member in IBM's Standards Strategy group. He has been involved in the architecture, design, and engineering of distributed systems for most of his 25-year career in IT and has been actively engaged in open standards development for XML and Web services since 1999. Chris currently chairs the WS-I Basic Profile Working Group, which is responsible for the development of the WS-I Basic Profile, and is an elected member of the OASIS Technical Advisory Board. He is a coauthor and editor of the WS-Reliable Messaging specification. Prior to joining IBM, Chris served as chair of the W3C Web Services Architecture Working Group and as a member of the W3C XML Protocols Working Group. You can e-mail him at chrisfer@us.ibm.com. Thomas Freund, coauthor of Chapter 11, "Transactions," is a senior technical staff member in the Emerging Technology group at IBM. He has worked extensively in the areas of transaction systems and Web services and has participated in the development of standards for OMG, Java, and Web Services. These specifications include the OMG/Object Transaction Service, the J2EE/Java Transaction Service, and Web Service's WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity. You can contact Tom at tjfreund@us.ibm.com. Maryann Hondo, co-author of Chapter 7, "Web Services Policy," is a senior technical staff member at IBM, having joined IBM/Lotus in 1996. Her previous background includes work for HP on DCE- and PKI-based Single SignOn, for Digital on a B1/CMW operating system, and for AT&T Bell Labs on B2 UNIX. Currently, she is the security architect for emerging technology at IBM, concentrating on XML security. Maryann is one of the coauthors of the WS-Security, Policy, Trust, and
- 33. Secure Conversation specifications announced by IBM and other business partners. Before joining the emerging technology group, she managed the IBM Tivoli Jonah team (IETF PKIX reference implementation) and was security architect for Lotus e- Suite, participating in the development of Java Security (JAAS). Send e-mails to Maryann at mhondo@us.ibm.com. John Ibbotson is a member of the Emerging Technology Services group based at the Hursley Development Laboratory near Winchester in the UK. He is the IBM prime representative on the World Wide Web Consortium (W3C) XML Protocol Working Group that is standardizing SOAP, a key component of the Web services architecture. He is also a coauthor of the WS-ReliableMessaging specification. Earlier in his career, John developed scientific image-processing systems and digital libraries. John is a Chartered Engineer and Fellow of the Institution of Electrical Engineers (IEEE). You can contact him at john_ibbotson@uk.ibm.com. Rania Khalaf is a software engineer in the Component Systems group at the IBM T.J. Watson Research Center. She received her bachelor's and master's degrees in computer science and electrical engineering from MIT in 2000 and 2001. Rania is a codeveloper and coarchitect of the IBM BPEL4WS prototype implementation (BPWS4J). She is an active member of the OASIS WS-BPEL Technical Committee standardizing BPEL. She has published numerous papers in the field and has served on the program committees of conferences and workshops. Rania is currently pursuing her Ph.D. studies under Professor Dr. Frank Leymann with the University of Stuttgart. Rania can be contacted at rkhalaf@us.ibm.com. Dieter KĂśnig is a software architect for workflow systems at the IBM Germany Development Laboratory. He joined the laboratory in 1988 and has worked at the Resource Measurement Facility for z/OS, MQSeries Workflow, and WebSphere Process Choreographer. Dieter is a member of the OASIS WS-BPEL Technical Committee, which is working toward an industry standard for Web Services Business Process Execution Language (WS-BPEL). He holds a master's degree (Diploma in Informatics) in computer science from the University of Bonn, Germany. You can contact him at dieterkoenig@de.ibm.com. Hiroshi Maruyama is a Distinguished Engineer at the IBM Tokyo Research Laboratory, Japan. In 1997, his team developed XML Parser for Java, one of the first fully compliant XML processors. Since then, he has worked on XML and Web Services. In particular, he has focused on the security aspects of these technologies, such as XML Signature, XML Encryption, and "WS-Security standards." He wrote XML and Java: Developing Web Applications, published by Addison-Wesley. He is one of the coauthors of WS-Security standards. He has a master's degree from Tokyo Institute of Technology and a Ph. D. in computer science from Kyoto University. Contact Hiroshi at maruyama@jp.ibm.com. Anthony Nadalin is a Distinguished Engineer and the chief security architect who is responsible for security infrastructure design and development across IBM SWG and Tivoli. Anthony serves as the primary security liaison to Sun Microsystems' JavaSoft division for Java security design and development collaboration. In his 23-year career with IBM, he has held the following positions: lead security architect for VM/SP, security architect for AS/400, and security architect for OS/2. Anthony has also authored and coauthored more than 30 technical journal and conference
- 34. articles and two books. Anthony has been on the technical committee of three major scientific journals and one conference, and has reviewed extensively work that peers in the field have published. E-mail Anthony at drsecure@us.ibm.com. Chris Sharp is a senior technical staff member working on Web services specifications and standards in IBM's Software Group, based in the IBM Hursley Laboratory in the United Kingdom. Chris is also a member of the IBM Academy of Technology. He joined IBM in 1990 as a graduate of computer science and has worked in the field of integration and Internet standards since 1994. He worked extensively on the development of IBM's integration middleware and exploitation of Internet standards. Chris is the editor of the WS-PolicyAttachment specification, coauthor of the WS-Policy specification, and contributor to WS-Addressing, WS- MetadataExchange, and the WS-ResourceFramework specifications. Chris is a Fellow of the British Computer Society. You can reach him at sharpc@uk.ibm.com.
- 36. Part 1: Introduction The first part of this book introduces you to Service-Oriented Architectures (SOAs) and Web services. The three chapters of this part cover service orientation, background, and Web services. Chapter 1, "SOA," starts by motivating the current trend toward service orientation and then explains what it is and how it differs from other technologies. The chapter wraps up by articulating the structure of a framework for service orientation. Chapter 2, "Background," presents a brief review of some key background concepts that are used throughout the book. Chapter 3, "Web Services," goes back to the service-oriented framework and introduces Web services as a realization of that platform. It briefly covers each of the specifications, which are discussed in detail in the rest of the book.
- 38. Chapter 1. Service-Oriented Architectures This chapter introduces the concept of Services and the associated architectural paradigm, Service-Oriented Architecture (SOA). SOA has emerged as a direct consequence of specific business and technology drivers that have materialized over the past decade. From the business side, major trends such as the outsourcing of noncore operations and the importance of business process reengineering have been key influences driving the surfacing of SOA as an important architectural approach to business information technology (IT) today. From the technology side, the past 15 years have resulted in a realization of the importance of middleware standards and architectures, learning in particular from the successes and failures of distributed object systems and message-oriented middleware. As an architectural concept, SOA permits multiple approaches for the realization and deployment of an IT system that has been designed and built around its principles. This book focuses on a specific technology that, arguably, has the most significant commercial visibility and traction, and that is Web services. Web services technology is a standards-based, XML-centric realization of an SOA. This chapter examines the motivation behind Web services and some of the main architectural concepts of SOA. Chapter 3, "Web Services," presents an overview of a Web services platform that provides the foundation to accomplish an SOA stack. Chapter 2, "Background," offers some required background so that you can understand the rest of this book.
- 39. 1.1. Virtual Enterprises Most companies produce and sell products to their customers to achieve defined business goals, such as specific financial targets. Their business processes prescribe how products are designed, manufactured, marketed, distributed, and sold. From a certain level of abstraction, a company's business processes are a direct reflection of the products it offers. Therefore, the speed of changing the existing infrastructure or creating new business processes corresponds to the speed of changing or creating products. To survive in highly dynamic markets and constantly changing environments, companies must be flexible. Flexibility here means the ability to react quickly (preferably faster than the competition) to new customer requirements, new product offerings by existing and new competitors, technology advances, and so on. The flexibility of an enterprise is a refection of its ability to adapt its business processes quickly. The constituents of the definition of a business process (see [Ley 2000]) translate directly into actions that are necessary to alter business processes: changing the flow of activities of a business process, changing the actors who are performing these activities, changing the tools that support these activities, and so on. These might result in moving the execution of (a subset of) the activities of the business processes to partners. The result could be multiple business partners having to cooperate to perform the business processes of a given company. The company in fact becomes a virtual company (or virtual enterprise). This term indicates that externally, the company looks like a real companyperforming all of its business processes itselfbut in practice, that is not what is actually happening. Others are partially running the company's business processes, making the company virtual in this sense. 1.1.1. Business Process Optimization The model of a business process prescribes the order in which a business must execute the activities that constitute it and under which conditions it must perform each of the activities. Collectively, this kind of prescription is called control flow. The control flow massively influences business-relevant properties of a business processsuch as its total cost and its overall durationand thus the competitiveness of a company: The execution of each step or activity within a business process is associated with certain costs, such as people costs that are associated with the activity if human intervention is required, or the cost of computer resources that are required to execute activities within the IT environment. Based on this information, a company can derive the overall cost for performing a business process. For example, if policy associated with a credit allocation process determines that someone must check credits with an amount greater than $1,000, and more customers are asking for credits above this limit, a business
- 40. could change the policy to set manual intervention at a higher value to reduce the overall costs for running the process. Activities have temporal characteristics, such as the average duration for executing an activity or the average time elapsed until an activity is picked up and performed. Based on this information, you can derive the average interval for executing a business process. For example, when you are booking a business trip, you can reserve hotel and flight reservations in parallel, resulting in a shorter execution time for the overall business process relative to its sequential execution. There are other business-relevant properties of business processes and the activities they encompass. Changing the control flow of a business process might alter the corresponding properties of the business process in an unexpected manner. For example, introducing parallelism between activities might result in a longer duration of the overall process in those cases in which the parallel activities compete for the same resources (such as staff members who have rare skills). Therefore, modeling a business process is a non-trivial endeavor, supported by specialized design and analysis tools. After having modeled and optimized a business process, it must be executed in exactly the way it was specified to ensure the business properties that the process is optimized for. Special middleware is available that enforces the correct and model-compliant executionso-called workflow systems [Ley 2000]. Workflow systems allow monitoring of the business properties of individual business processes or aggregations of business processes at runtime. They also support the analysis of corresponding execution histories. Based on monitoring and analysis of results, you can change the model of a business process, if required, to further optimize it, especially when benchmarking shows that the execution of a business process is not competitive in terms of its key business parameters, such as cost or duration. Sometimes, modifying the control flow of a business process is insufficient to hit the target values for certain business properties. For example, the cost structure within a company or wages for certain required staff might be too high to meet business expense targets. In such situations, a company's business process cannot gain competitiveness without significant re-engineering. The company (or a certain branch or location within a company) should probably determine its core competencies, focus on executing only the activities that correspond to these core competencies, and outsource the noncore competencies. Of course, the constraint is that outsourcing must result in hitting the target objectives of the subject business properties. SOA and Web service technology facilitates this kind of outsourcing in a secure, reliable manner. 1.1.2. Collaborations, Mergers, and Acquisitions Figure 1-1 demonstrates an original process (denoted by "P") that a company runs. The company determines that it is no longer competitive in performing activities A, B, and E. It finds two partners that can run these activities and meet the business goals. Partner 1 runs activities A and B, and Partner 2 runs activity E. The company
- 41. re-engineered the original process into a new process (P'). In the new process, activity AB kicks off the execution at the first partner (Partner 1), and E' starts the execution at the second partner (Partner 2). The company now has a new process P', which results in increased competitiveness. Figure 1-1. Outsourcing activities to partners. In general, a company can work in several ways with partners that run the outsourced activities. One way is for a business to acquire a partner that can effectively run some of the activities that it could not run in a competitive manner before. A company might take this approach if the activities that it has trouble performing competitively are core to its business. A company might also choose this acquisition if it is cheaper to acquire the partner than pay the partner to perform the activities. A company might also choose to merge with a partner, essentially combining its own business with that of the partner in a peer manner. This could exploit synergies between the two companies, further reducing costs and enhancing the competitiveness of the aggregate. Usually, mergers and acquisitions result in business processes that are run in a distributed manner, across partners or virtual enterprise as described here.
- 42. Mergers or acquisitions can have a deep impact on companies, and they, thus, generally take a less radical approach. They determine appropriate partners and negotiate long-term contracts for performing specific activities on behalf of the outsourcing company. These contracts especially include service level-agreements, which are specifications of service objectives such as availability of the outsourced activities, penalties applied when objectives are not met, bonuses paid if the objectives are overachieved, and so on [Dan 2004]. The result is a network of collaborating partners. Situations might be highly dynamic. Multiple partners might provide the same services, and a company should choose on a case-by-case basis one of these to perform specific activities. For example, the cost of performing activities on behalf of a company might change depending on the actual load at each partner side. The company can then determine the partner on a best-price basis. Collaboration might not only result from process optimization endeavors, but from supply chains that are typical within an industry. In this situation, a company and its partners are not distinguished. All partners are peers, collaborating to realize an overall business process that is spread over the partners. Some industries even have standards to define the various kinds of partners, the activities each of them runs, and how they relate. For example, RosettaNet [RN] defines such a standard and is currently moving toward Web service technology [RNWS]. 1.1.3. Resource Sharing In addition to business process optimization, businesses outsource activities or complete business processes for total cost of ownership considerations. Perhaps a business process is competitive overall, but the overall cost for running parts of it on IT equipment that the company owns is too high. In this situation, a company looks for a partner to run the corresponding activities or the whole business process on behalf of the company. This partner, also called application service provider (ASP), not only runs parts of the business process on its IT equipment, but it also runs the corresponding software, covering the whole spectrum from managing prerequisite software to monitoring the software and performing periodic backups. Web service technology, technology from the area of Grid computing that is based on Web services, and autonomic computing facilitate the ASP model and extend it toward a model called utility computing (see [Ley 2004], [Rappa 2004]). Within this utility computing model, computer resources and other IT related resources are offered in a similar manner to traditional utilities such as electricity or telephone. The usage of the utility IT resources to run parts of a business process is metered and charged on this basis. You will read more about this topic later.
- 43. 1.2. The Need for Loose Coupling Enabling communication with services, possibly dynamically discovered, requires loose coupling between a requester and the service to be used. The notion of loose coupling precludes any knowledge or assumptions about the specific platforms that the requester or the service provider run on, specifics about the implementation that either of the partners uses, or the formats and protocols used to interoperate between them. Making such assumptions significantly limits the usefulness of a service or the choice of services that might be available. The notion of loose coupling is a fundamental underpinning of SOA. The following section sheds more light on it. 1.2.1. Issues with Current Distributed System Technologies Distributed system technology that has been developed in the past allows building applications, the elements of which can run on different machines in a network. However, dealing with the business scenarios outlined earlier has some other issues. Fragility of Object Systems Typically, current distributed system technology is centered on object technology. In this case, a service is offered as a method of a class implemented by an object. A requester who wants to use a service must tie the whole object into his application. In other words, a person who needs a single function has to use the whole class oreven worsethe whole class hierarchy within his program. When the class used or the class above it in the class hierarchy changes, he must also change the application that uses that class. The requester and the service are tightly coupled, which means that the requester's application is fragile because of its association with and dependence on this detail. Lack of Interoperability Today, different distributed system technologies such as Common Object Request Broker Architecture (CORBA), Java 2 Platform, Enterprise Edition (J2EE), and Component Object Model (COM) are based on quite different and incompatible object models [Emm 2000]. As a result, interoperability between these platforms is difficult. Communication between a requester on one platform and a service on another is at best cumbersome, if it's possible at all. Not only are the object models different, but higher-level frameworks (middleware) that support them (such as transactions, security, management, and messaging) are also incompatible. This significantly compounds the interoperability problem because you have to deal with quality of service differences. These differences can include running a transaction with participants on different platforms that operate incompatible transaction services, which is not an easy task!
- 44. 1.2.2. Advantages of Message-Oriented Middleware A significant consequence of these interoperability problems is that islands of middleware and corresponding applications that are based on this middleware have been created. In parallel, the ability to easily integrate applications, especially from different islands, has become a strong requirement (Enterprise Application Integration EAI). In tandem, products that provide special integration middleware have been created. A key aspect of such integration middleware is message orientation. Adapters and Channels Message orientation refers to messages being exchanged between the applications that are to be integrated. For this purpose, adapters wrap existing applications that need to be integrated. One kind of adapter signals the occurrence of an event that needs to be passed to other applications (source adapter), and another kind of adapter receives such events and passes them to the application that they are wrapping (target adapter). Events are represented by messages that are transported via a so-called "channel" from the source adapter to a target adapter. The channel ensures a certain quality of services, such as "exactly once delivery". Also, the channel can have other side effects, such as transforming the message into a format that the recipient understands. Figure 1-2 shows a source adapter A that wraps application A. Adapter A passes a message of format M to the channel, which transforms the message into format M' and delivers it reliably to target adapter B. Adapter B in turn understands how to pass the data from M' to B. See [Hohpe 2004] for additional perspectives in this space. Figure 1-2. Message-based integration. Based on this message-based architecture, applications A and B are loosely coupled. For example, the owner of application A can change the format of message M, generally without affecting his ability to integrate application B. The message M that A produces can be appropriately transformed by the channel into the format M' that B expects. A message-based approach like this fosters loose coupling. Interaction Patterns
- 45. Often, interaction and communication styles, other than the synchronous request/response approach that is predominant in distributed object systems, are necessary for loosely coupled interactions. For example, the asynchronous send and receive pattern that was mentioned in the previous section can increase a requester's perspective of the overall availability of the requested service. Operating in a "send-and-forget" mode, the requester doesn't have to synchronously wait for a response from the service. The requester doesn't have to deal with potential connection problems between the requester's side and the service's side because the channel can operate in a store-and-forward manner, finally delivering the message to the target destination. Other patterns are also desirable. For example, a message might be delivered to multiple recipients, only a subset of which responds to the originator of the message. This pattern is useful in auction-type scenarios in which a request for bids is sent and bids are returned. This also contributes to loose coupling because the requester is unaware of who the recipients are. The underlying integration middleware deals with these aspects. To overcome rigidity in distributed object systems, you must support the ability to define message exchange patterns (MEP), which provide advanced interaction patterns. MEP is discussed in Chapter 6 in more details. Web service technology is built on the concept of messaging. As a result, requesters and services can run on different platforms with channels connecting them. Wrappers hide the implementation specifics of the wrapped application function. In other words, requesters and services that are built according to different programming models can interact with each other. Protocols that are underlying a channel are hidden from the communication partners, and different formats can be transformed within a channel. The messaging architecture underlying Web servicesSOAPalso foresees exchange of information required by higher-level functionality, such as transaction context or security context. Therefore, a messaging-based approach supports many of the requisite features at the beginning of this section. 1.2.3. Future Proofing The concept of a wrapper allows switching implementations of application functions without impact to the other communication partner. This in turn facilitates loose coupling between a requester and a service (their corresponding wrappers). That is fine, but a universally agreed or standard approach to specifying the wrappers is required to describe, in a machine-readable way, the interface that a service provides to its potential users. The Web Services Description Language (WSDL) provides precisely this capability. Technology Abstraction WSDL provides a standard way of describing the interfaces of the wrappers that hide the specific implementation details of a service. Such an interface describes, in abstract terms, the functions that services provide. A requester can use any service
- 46. that implements a particular interface to satisfy his requirement. This contributes to loose coupling between a requester and the service and provides some element of future-proofing. It gives the requester the freedom to select a different service implementation of the same interface at any time. In particular, the requester can benefit from any future advancements in implementation technology for services by being based on WSDL interfaces. Provider Abstraction Services are described not only by their WSDL interfaces, but also in terms of the quality of service they provide. For example, a service might assert that it can participate in a transaction, thereby ensuring overall integrity of a series of service invocations. It might also assert that it can cope with encrypted messages, ensuring that in the course of an interaction between a requester and the service, no confidential data will be revealed to unauthorized parties. The ability to annotate quality of service descriptions is important, and incorporated into Web service technology by means of the Web service policy specifications discussed later in this book (Chapter 7, "Web Services Policy"). Also, you can associate services with business-relevant data. The directory features of the Universal Description, Discovery, and Integration (UDDI) technology (discussed later) offer and support such a capability and allow information about the company that is providing the service, including contact information, additional documentation, and geographic details. This allows discovery of suitable services based on detailed business criteria. For example, as a requester, a restaurant might want an online service that supplies ordering, settlement, and delivery of vegetables, meat, and so on within a distance of less than 50 miles. As a consequence, the boundary for describing and discovering services is moved from specialized IT personnel toward business professionals. Again, this contributes to loose coupling by supporting discovery of providers that offer identical services and allowing switching between them dynamically with little or no change to the application.
- 47. 1.3. What Is a Service? In everyday life, you can point to many metaphors with which you can associate the concept of a service. These might include utilities such as water, gas, telephone, or electric, in addition to credit card services, transportation, travel agents, instant messaging, Internet service providers, search engines on the Web, and so on. These services represent some sort of publicized package of functionality. They are composeable. For example, a travel agent makes use of transportation (airline and rental car) and credit card services. Services are discoverable based on their descriptions, terms and conditions for use, and so on, based on metadata that fully describes the service. Actual use of a service is often based on an agreed-upon contract with the provider, including what in detail is provided and what the associated quality of services are, such as availability, cost, and other specified conditions that govern its use. Generally speaking, the user of the service requires little or no knowledge as to the specifics of how the service is implemented or how it is provided. The following sections relate these characteristics and apply them to software services. 1.3.1. Evolution of Major Software Granules The idea of packaging software into artifacts that have a wider context, use, and applicability than a single application has been given a lot of attention since the early days of computing. This objective also relates to more flexible units of deployable software. Additional benefits are derived through separation of concerns, which leads to a significantly better understanding of the overall anatomy of complex software systems. This in turn enables improved software development methodologies necessary for tackling today's complex problems, in addition to improvements in software maintainability. Over the past decades, the ideas that have been applied to this problem have evolved quite significantly. Functions and Packages One of the first attempts to decompose software was centered on functional decomposition that resulted in functions or subroutines as individual software units. Such a unit offers coherent functionality that you can easily understand and build. This decomposition into functions enables modularization of software systems. However, this approach frequently brings about partial simplification that can only address simple problems. Added value comes with aggregations of related functions that help solve more complex tasks that are associated with a particular problem domain. Such approaches have, for example, been pioneered by Ada in the form of packages. Objects and Classes
- 48. A package is a mere syntactic unit. To improve on and extend this concept further, the notion of a class evolved. A class describes the behavior of objects from a problem domain; therefore, it carries certain semantics in addition to being a syntactic unit combining functions and data. Classes, together with the concept of polymorphism and inheritance, have turned out to be a powerful concept for building software. Polymorphism allows the resulting software to become more flexible, whereas through inheritance, class lattices can be built that stimulate reuse and ease communication among developers within a given community. Although classes represent objects and carry some semantics, a class lattice mostly captures syntaxnamely, the signature of the functions aggregated. The semantics that a class lattice captures are typically understood only within a limited community, such as a development team. Few class lattices are known, the semantics of which are shared across larger communities. In contrast to this, services are described not only via their interfaces, but also via business terms. Thus, the semantics that a service description provides go beyond that of a class and a class lattice. As such, services support comprehension by much broader communities. Components Besides being coarser than objects and classes, components go further by dealing with deployment. Addressing the issue of deployment allows a component provider to focus specifically on application logic, while qualities of services are folded in by the runtime environment that is hosting the component. For that purpose, quality of service requirements are factored and parameterized by deployment descriptors [J2EE]. By setting appropriate values in the deployment descriptors, you specify the behavior of a component with respect to such things as transactions, security checking, state management, and so on. In addition, you can resolve dependencies on other components and resources (such as databases and queues) via deployment descriptors. Finally, you can set up values governing application-specific context (such as local tax rates) via deployment descriptors. Dealing with these aspects of deployment eases customization. You can tailor a piece of application logic to a company's specific use by setting values in deployment descriptors accordingly. The container that is hosting the application logic interprets the deployment descriptors and ensures the specified behavior. For a customized context that the application logic requires, the deployment descriptor provides the standardized contract. Deployment descriptors enable components to become tradeable artifacts. 1.3.2. The Software Version of a Service Services represent another step forward in the evolution of software packages. Services can provide an abstraction of specific component models, allowing users of these components to think only in terms of Web services and ignore specific details of the component model and how it its implemented. For example, services can hide
- 49. the details about whether the component is a J2EE-based component or a .NET based component. This provides significantly enhanced interoperability between computing platforms that have programming models based on these differing component models, such as WebSphere and .NET. Characteristics of a Service A service is available at a particular endpoint in the network, and it receives and sends messages and exhibits behavior according to its specification. The service has specific functionality and is deployed with appropriate quality of service at the endpoint. (For example, the service is set up with certain transactional or security or reliable messaging behavior.) The functional aspects of a service are specified using WSDL, and the constraints and conditions that are associated with the use of the service are specified via policies that you can attach to various parts of the WSDL (see chapter 7). Interfaces and policies describe the terms and conditions that govern the use of the service. These are published so that potential users of the service can discover and be given all the information they need to bind (perhaps dynamically) to that service. The information that is published about a service provides details of what the service is and does (its semantics). It further provides all the information that allows the environment hosting a potential user to access the service and successfully interact with it. This can include information about the transport protocols that can be supported and used to send a messages to the service, the wire format of this message expected by the service, whether and how the message has to be encrypted or signed. Although the environment that is hosting needs this information, the requester doesn't need this kind of access information, and it certainly doesn't need to understand details about the implementation of the service. You can implement this service as an EJB, a database stored procedure, or a CICS or IMS transaction made available via a wrapper. The environment that is hosting the service and receiving the request message, often referred to as a container, must deal with that detail necessary to interact with a particular implementation. The requester can think in terms of using a Web service. In that sense, Web service technology is virtualization technology for making use of services, but an implementer of a service can use the technology he is acquainted with to build the service implementation. SolutionsComposition of Services One valuable aspect of the services model is that you can create new services from existing ones without leaving the service paradigm. A technology called choreography facilitates the composition and orchestration of the execution of existing services to create more powerful ones (see Chapter 14, "Modeling Business Processes: BPEL"). Choreographies support the idea of programming in the large (see [Ley 2004], [Ley 1997], [Wied 1992]), which fosters the creation of new functionality, in particular by non-IT personnel.
- 50. Another Random Scribd Document with Unrelated Content
- 51. PHONOGRAPH ODDITIES. Professor Fleeming Jenkin has applied the phonograph to a very interesting series of observations on the wave-forms of articulate sound. By a process of enlargement of the vibrations caused by the indented tinfoil, he, with the assistance of Mr J. A. Ewing, has obtained a large series of markings, upon bands of paper, by which the wave-forms of different sounds have been shewn. Some of those results Professor Jenkin has laid before the Royal Society of Edinburgh. The vowel sounds in the phonograph are found not to be dependent on the speed with which the cylinder of the phonograph is turned, the distinct vowel being heard however much the pitch of the note may be altered. He found that the phonograph resolutely refused to reproduce the French u, converting it always into the sound of oo. On the black-board, Professor Jenkin illustrated some of the constant forms assumed by the sound-waves, one of the most interesting being those of the letter r. In the case of the broad sound of a, it was shewn that while with most ordinary voices the wave took the form which might be described as having two humps, a rich bass voice had been found to give a wave-form much more intricate, shewing four distinct humps in each recurrent period of vibration. It was found that the phonograph gave vowel sounds, as well when the cylinder was turned backwards as forwards; and encouraged by this, the consonants were experimented upon, giving the same result. Even with a consonant at the beginning and end of a syllable, as, for example, bab, it was rather unexpectedly found that the word would be correctly repeated either way; shewing the identity of the sound. Professor Jenkin gave some amusement by describing the effects of reading words backwards, stating that with careful observation every sound could be heard, as, for example, in âAssociation,â which, when the cylinder was reversed, could be distinctly heard as ânosh-a-i-sho-sa.â In âEdinburghââwhich he said
- 52. Mr Ewing could pronounce backwards, though he could notâthe various sounds could also be distinguished. Words and sentences which when pronounced backwards or forwards sound the same, were tried. Thus was tried the well-known sentence, âMadam, Iâm Adam,â with which Adam is traditionally alleged to have saluted Eve; but âMadam, Iâm Adam,â although spelt the same both ways, did not sound the same in the phonograph, the diphthongal sound of the âIâmâ giving a sound like âmya.â It is obvious from Professor Fleeming Jenkinâs experiments that some interesting points in acoustics may yet be settled by means of this extraordinary instrument. Printed and Published by W. & R. Chambers, 47 Paternoster Row, London, and 339 High Street, Edinburgh. All Rights Reserved. [Transcriberâs note: the following changes have been made to this text. Page 206: repeated word âanâ correctedââan hour and reportâ.]
- 53. *** END OF THE PROJECT GUTENBERG EBOOK CHAMBERS'S JOURNAL OF POPULAR LITERATURE, SCIENCE, AND ART, NO. 747, APRIL 20, 1878 *** Updated editions will replace the previous oneâthe old editions will be renamed. Creating the works from print editions not protected by U.S. copyright law means that no one owns a United States copyright in these works, so the Foundation (and you!) can copy and distribute it in the United States without permission and without paying copyright royalties. Special rules, set forth in the General Terms of Use part of this license, apply to copying and distributing Project Gutenberg⢠electronic works to protect the PROJECT GUTENBERG⢠concept and trademark. Project Gutenberg is a registered trademark, and may not be used if you charge for an eBook, except by following the terms of the trademark license, including paying royalties for use of the Project Gutenberg trademark. If you do not charge anything for copies of this eBook, complying with the trademark license is very easy. You may use this eBook for nearly any purpose such as creation of derivative works, reports, performances and research. Project Gutenberg eBooks may be modified and printed and given awayâyou may do practically ANYTHING in the United States with eBooks not protected by U.S. copyright law. Redistribution is subject to the trademark license, especially commercial redistribution. START: FULL LICENSE
- 54. THE FULL PROJECT GUTENBERG LICENSE
- 55. PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK To protect the Project Gutenberg⢠mission of promoting the free distribution of electronic works, by using or distributing this work (or any other work associated in any way with the phrase âProject Gutenbergâ), you agree to comply with all the terms of the Full Project Gutenberg⢠License available with this file or online at www.gutenberg.org/license. Section 1. General Terms of Use and Redistributing Project Gutenberg⢠electronic works 1.A. By reading or using any part of this Project Gutenberg⢠electronic work, you indicate that you have read, understand, agree to and accept all the terms of this license and intellectual property (trademark/copyright) agreement. If you do not agree to abide by all the terms of this agreement, you must cease using and return or destroy all copies of Project Gutenberg⢠electronic works in your possession. If you paid a fee for obtaining a copy of or access to a Project Gutenberg⢠electronic work and you do not agree to be bound by the terms of this agreement, you may obtain a refund from the person or entity to whom you paid the fee as set forth in paragraph 1.E.8. 1.B. âProject Gutenbergâ is a registered trademark. It may only be used on or associated in any way with an electronic work by people who agree to be bound by the terms of this agreement. There are a few things that you can do with most Project Gutenberg⢠electronic works even without complying with the full terms of this agreement. See paragraph 1.C below. There are a lot of things you can do with Project Gutenberg⢠electronic works if you follow the terms of this agreement and help preserve free future access to Project Gutenberg⢠electronic works. See paragraph 1.E below.
- 56. 1.C. The Project Gutenberg Literary Archive Foundation (âthe Foundationâ or PGLAF), owns a compilation copyright in the collection of Project Gutenberg⢠electronic works. Nearly all the individual works in the collection are in the public domain in the United States. If an individual work is unprotected by copyright law in the United States and you are located in the United States, we do not claim a right to prevent you from copying, distributing, performing, displaying or creating derivative works based on the work as long as all references to Project Gutenberg are removed. Of course, we hope that you will support the Project Gutenberg⢠mission of promoting free access to electronic works by freely sharing Project Gutenberg⢠works in compliance with the terms of this agreement for keeping the Project Gutenberg⢠name associated with the work. You can easily comply with the terms of this agreement by keeping this work in the same format with its attached full Project Gutenberg⢠License when you share it without charge with others. 1.D. The copyright laws of the place where you are located also govern what you can do with this work. Copyright laws in most countries are in a constant state of change. If you are outside the United States, check the laws of your country in addition to the terms of this agreement before downloading, copying, displaying, performing, distributing or creating derivative works based on this work or any other Project Gutenberg⢠work. The Foundation makes no representations concerning the copyright status of any work in any country other than the United States. 1.E. Unless you have removed all references to Project Gutenberg: 1.E.1. The following sentence, with active links to, or other immediate access to, the full Project Gutenberg⢠License must appear prominently whenever any copy of a Project Gutenberg⢠work (any work on which the phrase âProject Gutenbergâ appears, or with which the phrase âProject Gutenbergâ is associated) is accessed, displayed, performed, viewed, copied or distributed:
- 57. This eBook is for the use of anyone anywhere in the United States and most other parts of the world at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org. If you are not located in the United States, you will have to check the laws of the country where you are located before using this eBook. 1.E.2. If an individual Project Gutenberg⢠electronic work is derived from texts not protected by U.S. copyright law (does not contain a notice indicating that it is posted with permission of the copyright holder), the work can be copied and distributed to anyone in the United States without paying any fees or charges. If you are redistributing or providing access to a work with the phrase âProject Gutenbergâ associated with or appearing on the work, you must comply either with the requirements of paragraphs 1.E.1 through 1.E.7 or obtain permission for the use of the work and the Project Gutenberg⢠trademark as set forth in paragraphs 1.E.8 or 1.E.9. 1.E.3. If an individual Project Gutenberg⢠electronic work is posted with the permission of the copyright holder, your use and distribution must comply with both paragraphs 1.E.1 through 1.E.7 and any additional terms imposed by the copyright holder. Additional terms will be linked to the Project Gutenberg⢠License for all works posted with the permission of the copyright holder found at the beginning of this work. 1.E.4. Do not unlink or detach or remove the full Project Gutenberg⢠License terms from this work, or any files containing a part of this work or any other work associated with Project Gutenbergâ˘. 1.E.5. Do not copy, display, perform, distribute or redistribute this electronic work, or any part of this electronic work, without prominently displaying the sentence set forth in paragraph 1.E.1
- 58. with active links or immediate access to the full terms of the Project Gutenberg⢠License. 1.E.6. You may convert to and distribute this work in any binary, compressed, marked up, nonproprietary or proprietary form, including any word processing or hypertext form. However, if you provide access to or distribute copies of a Project Gutenberg⢠work in a format other than âPlain Vanilla ASCIIâ or other format used in the official version posted on the official Project Gutenberg⢠website (www.gutenberg.org), you must, at no additional cost, fee or expense to the user, provide a copy, a means of exporting a copy, or a means of obtaining a copy upon request, of the work in its original âPlain Vanilla ASCIIâ or other form. Any alternate format must include the full Project Gutenberg⢠License as specified in paragraph 1.E.1. 1.E.7. Do not charge a fee for access to, viewing, displaying, performing, copying or distributing any Project Gutenberg⢠works unless you comply with paragraph 1.E.8 or 1.E.9. 1.E.8. You may charge a reasonable fee for copies of or providing access to or distributing Project Gutenberg⢠electronic works provided that: ⢠You pay a royalty fee of 20% of the gross profits you derive from the use of Project Gutenberg⢠works calculated using the method you already use to calculate your applicable taxes. The fee is owed to the owner of the Project Gutenberg⢠trademark, but he has agreed to donate royalties under this paragraph to the Project Gutenberg Literary Archive Foundation. Royalty payments must be paid within 60 days following each date on which you prepare (or are legally required to prepare) your periodic tax returns. Royalty payments should be clearly marked as such and sent to the Project Gutenberg Literary Archive Foundation at the address specified in Section 4, âInformation
- 59. about donations to the Project Gutenberg Literary Archive Foundation.â ⢠You provide a full refund of any money paid by a user who notifies you in writing (or by e-mail) within 30 days of receipt that s/he does not agree to the terms of the full Project Gutenberg⢠License. You must require such a user to return or destroy all copies of the works possessed in a physical medium and discontinue all use of and all access to other copies of Project Gutenberg⢠works. ⢠You provide, in accordance with paragraph 1.F.3, a full refund of any money paid for a work or a replacement copy, if a defect in the electronic work is discovered and reported to you within 90 days of receipt of the work. ⢠You comply with all other terms of this agreement for free distribution of Project Gutenberg⢠works. 1.E.9. If you wish to charge a fee or distribute a Project Gutenberg⢠electronic work or group of works on different terms than are set forth in this agreement, you must obtain permission in writing from the Project Gutenberg Literary Archive Foundation, the manager of the Project Gutenberg⢠trademark. Contact the Foundation as set forth in Section 3 below. 1.F. 1.F.1. Project Gutenberg volunteers and employees expend considerable effort to identify, do copyright research on, transcribe and proofread works not protected by U.S. copyright law in creating the Project Gutenberg⢠collection. Despite these efforts, Project Gutenberg⢠electronic works, and the medium on which they may be stored, may contain âDefects,â such as, but not limited to, incomplete, inaccurate or corrupt data, transcription errors, a copyright or other intellectual property infringement, a defective or
- 60. damaged disk or other medium, a computer virus, or computer codes that damage or cannot be read by your equipment. 1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for the âRight of Replacement or Refundâ described in paragraph 1.F.3, the Project Gutenberg Literary Archive Foundation, the owner of the Project Gutenberg⢠trademark, and any other party distributing a Project Gutenberg⢠electronic work under this agreement, disclaim all liability to you for damages, costs and expenses, including legal fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE. 1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you discover a defect in this electronic work within 90 days of receiving it, you can receive a refund of the money (if any) you paid for it by sending a written explanation to the person you received the work from. If you received the work on a physical medium, you must return the medium with your written explanation. The person or entity that provided you with the defective work may elect to provide a replacement copy in lieu of a refund. If you received the work electronically, the person or entity providing it to you may choose to give you a second opportunity to receive the work electronically in lieu of a refund. If the second copy is also defective, you may demand a refund in writing without further opportunities to fix the problem. 1.F.4. Except for the limited right of replacement or refund set forth in paragraph 1.F.3, this work is provided to you âAS-ISâ, WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,
- 61. INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PURPOSE. 1.F.5. Some states do not allow disclaimers of certain implied warranties or the exclusion or limitation of certain types of damages. If any disclaimer or limitation set forth in this agreement violates the law of the state applicable to this agreement, the agreement shall be interpreted to make the maximum disclaimer or limitation permitted by the applicable state law. The invalidity or unenforceability of any provision of this agreement shall not void the remaining provisions. 1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation, the trademark owner, any agent or employee of the Foundation, anyone providing copies of Project Gutenberg⢠electronic works in accordance with this agreement, and any volunteers associated with the production, promotion and distribution of Project Gutenberg⢠electronic works, harmless from all liability, costs and expenses, including legal fees, that arise directly or indirectly from any of the following which you do or cause to occur: (a) distribution of this or any Project Gutenberg⢠work, (b) alteration, modification, or additions or deletions to any Project Gutenberg⢠work, and (c) any Defect you cause. Section 2. Information about the Mission of Project Gutenberg⢠Project Gutenberg⢠is synonymous with the free distribution of electronic works in formats readable by the widest variety of computers including obsolete, old, middle-aged and new computers. It exists because of the efforts of hundreds of volunteers and donations from people in all walks of life. Volunteers and financial support to provide volunteers with the assistance they need are critical to reaching Project Gutenbergâ˘âs goals and ensuring that the Project Gutenberg⢠collection will
- 62. remain freely available for generations to come. In 2001, the Project Gutenberg Literary Archive Foundation was created to provide a secure and permanent future for Project Gutenberg⢠and future generations. To learn more about the Project Gutenberg Literary Archive Foundation and how your efforts and donations can help, see Sections 3 and 4 and the Foundation information page at www.gutenberg.org. Section 3. Information about the Project Gutenberg Literary Archive Foundation The Project Gutenberg Literary Archive Foundation is a non-profit 501(c)(3) educational corporation organized under the laws of the state of Mississippi and granted tax exempt status by the Internal Revenue Service. The Foundationâs EIN or federal tax identification number is 64-6221541. Contributions to the Project Gutenberg Literary Archive Foundation are tax deductible to the full extent permitted by U.S. federal laws and your stateâs laws. The Foundationâs business office is located at 809 North 1500 West, Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up to date contact information can be found at the Foundationâs website and official page at www.gutenberg.org/contact Section 4. Information about Donations to the Project Gutenberg Literary Archive Foundation Project Gutenberg⢠depends upon and cannot survive without widespread public support and donations to carry out its mission of increasing the number of public domain and licensed works that can be freely distributed in machine-readable form accessible by the widest array of equipment including outdated equipment. Many
- 63. small donations ($1 to $5,000) are particularly important to maintaining tax exempt status with the IRS. The Foundation is committed to complying with the laws regulating charities and charitable donations in all 50 states of the United States. Compliance requirements are not uniform and it takes a considerable effort, much paperwork and many fees to meet and keep up with these requirements. We do not solicit donations in locations where we have not received written confirmation of compliance. To SEND DONATIONS or determine the status of compliance for any particular state visit www.gutenberg.org/donate. While we cannot and do not solicit contributions from states where we have not met the solicitation requirements, we know of no prohibition against accepting unsolicited donations from donors in such states who approach us with offers to donate. International donations are gratefully accepted, but we cannot make any statements concerning tax treatment of donations received from outside the United States. U.S. laws alone swamp our small staff. Please check the Project Gutenberg web pages for current donation methods and addresses. Donations are accepted in a number of other ways including checks, online payments and credit card donations. To donate, please visit: www.gutenberg.org/donate. Section 5. General Information About Project Gutenberg⢠electronic works Professor Michael S. Hart was the originator of the Project Gutenberg⢠concept of a library of electronic works that could be freely shared with anyone. For forty years, he produced and distributed Project Gutenberg⢠eBooks with only a loose network of volunteer support.
- 64. Project Gutenberg⢠eBooks are often created from several printed editions, all of which are confirmed as not protected by copyright in the U.S. unless a copyright notice is included. Thus, we do not necessarily keep eBooks in compliance with any particular paper edition. Most people start at our website which has the main PG search facility: www.gutenberg.org. This website includes information about Project Gutenbergâ˘, including how to make donations to the Project Gutenberg Literary Archive Foundation, how to help produce our new eBooks, and how to subscribe to our email newsletter to hear about new eBooks.
- 65. Welcome to Our Bookstore - The Ultimate Destination for Book Lovers Are you passionate about books and eager to explore new worlds of knowledge? At our website, we offer a vast collection of books that cater to every interest and age group. From classic literature to specialized publications, self-help books, and childrenâs stories, we have it all! Each book is a gateway to new adventures, helping you expand your knowledge and nourish your soul Experience Convenient and Enjoyable Book Shopping Our website is more than just an online bookstoreâitâs a bridge connecting readers to the timeless values of culture and wisdom. With a sleek and user-friendly interface and a smart search system, you can find your favorite books quickly and easily. Enjoy special promotions, fast home delivery, and a seamless shopping experience that saves you time and enhances your love for reading. Let us accompany you on the journey of exploring knowledge and personal growth! ebookgate.com