Web Service Architecture in Realization of the following SOA Architecture:
<--Web Service Triangle: Bind-Publish-Find
Business Activities Outsourcing-->
Service Oriented Architecture:
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
Business Process Optimization
· 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 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.
Collaborations, Mergers, and Acquisitions
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 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.
The basic principles that underpin SOA are illustrated as follows:
First, it is necessary to provide an abstract definition of the service, including the details that allow anyone who wants to use the service to bind to it in the appropriate way. Second, those people who are the providers of services need to publish details of their services so that those who want to use them can understand more precisely what they do and can obtain the information necessary to connect to use them.
Third, those who require services need to have some way to find what services are available that meet their needs. Also, to make this bind/publish/find approach work well, standards must be defined to govern what and how to publish, how to find information, and the specific details about how to bind to the service. Web services technology is at the heart of addressing these questions and is the subject of this book. It also forms a basis for the notion of a service bus (infrastructure) that supports SOA.
High level Architecture of SOA
The bottom layer presents its capabilities to cope with various transport protocols to communicate between a service and a requester. The messaging layer on top of the transport layer enables the bus to deal with messages, both XML and non-XML. The latter is important, for example, if a requester and the service needed reside in the same J2EE application server and the bus can simply transport the data in its Java rendering, avoiding unnecessary transformations. The next layer of the bus facilitates and deals with the description of services in terms of functions supported, quality of services of these functions, and supported binding mechanisms. The actual quality of services that the bus enforces based on appropriate parameterization via polices resides in the layer that follows. This layer copes with security aspects such as message integrity, confidentiality, and nonrepudiation, but also with reliable transport of messages and various kinds of transactions. The top layer represents the various kinds of virtual components that Web services represent. This layer has atomic services that are not composed as far as a requester's experience with the service is concerned.
Composed services that the service bus inherently supports are choreographies and societies of services that cooperate following an agreement protocol to decide on the success of the cooperation at the end of the cooperation. Finally, another layer provides features for discovery of services and their descriptions and to agree on a mode of interaction between a requester and a service.
WEB SERVICES:
"Service-Oriented Architectures," SOA represents an abstract architectural concept. It's an approach to building software systems that is based on loosely coupled components (services) that have been described in a uniform way and that can be discovered and composed. Web services represents one important approach to realizing an SOA.
The World Wide Web Consortium (W3C), which has managed the evolution of the SOAP and WSDL specifications, defines Web services as follows:
A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards.
Although Web services technology is not the only approach to realizing an SOA, it is one that the IT industry as a whole has enthusiastically embraced. With Web services, the industry is addressing yet again the fundamental challenge that distributed computing has provided for some considerable time: to provide a uniform way of describing components or services within a network, locating them, and accessing them. The difference between the Web services approach and traditional approaches (for example, distributed object technologies such as the Object Management Group Common Object Request Broker Architecture (OMG CORBA), or Microsoft Distributed Component Object Model (DCOM)) lies in the loose coupling aspects of the architecture. Instead of building applications that result in tightly integrated collections of objects or components, which are well known and understood at development time, the whole approach is much more dynamic and adaptable to change. Another key difference is that through Web services, the IT industry is tackling the problems using technology and specifications that are being developed in an open way, utilizing industry partnerships and broad consortia such as W3C and the Organization for the Advancement of Structured Information Standards (OASIS), and based on standards and technology that are the foundation of the Internet.
Web services had its beginnings in mid to late 2000 with the introduction of the first version of XML messagingSOAP, WSDL 1.1, and an initial version of UDDI as a service registry. This basic set of standards has begun to provide an accepted industry-wide basis for interoperability among software components (Web services) that is independent of network location, in addition to specific implementation details of both the services and their supporting deployment infrastructure. Several key software vendors have provided these implementations, which have already been widely used to address some important business problems.
Although the value of Web services technology has been demonstrated in practice, there is a desire to use the approach to address more difficult problems. Developers are looking for enhancements that raise the level and scope of interoperability beyond the basic message exchange, requiring support for interoperation of higher-level infrastructure services. Most commercial applications today are built assuming a specific programming model. They are deployed on platforms (operating systems and middleware) that provide infrastructure services in support of that programming model, hiding complexity, and simplifying the problems that the solution developer has to deal with. For example, middleware typically provides support for transactions, security, or reliable exchange of messages (such as guaranteed, once-only delivery). On the other hand, there is no universally agreed standard middleware, which makes it difficult to construct applications from components that are built using different programming models (such as Microsoft COM, OMG CORBA, or Java 2 Platform, Enterprise Edition (J2EE) Enterprise Java Beans). They bring with them different assumptions about infrastructure services that are required, such as transactions and security. As a consequence, interoperability across distributed heterogeneous platforms (such as .NET and J2EE) presents a difficult problem.
Transport Services
Web services is basically an interoperable messaging architecture, and message transport technologies form the foundation of this architecture. Web services is inherently transport neutral. Although you can transport Web services messages by using the ubiquitous Web protocols such as HyperText Transport Protocol (HTTP) or Secure HTTP (HTTPS) to give the widest possible coverage in terms of support for the protocols , you can also transport them over any communications protocol, using proprietary ones if appropriate. Although transport protocols are fundamental to Web services and clearly are a defining factor in the scope of interoperability, the details are generally hidden from the design of Web services
Messaging:
The messaging services component of the framework contains the most fundamental Web services specifications and technologies, including eXtensible Markup Language (XML), SOAP, and WS-Addressing. Collectively, these specifications form the basis of interoperable messaging between Web services.
2.1 SOAP
SOAP, one of the significant underpinnings of Web services, provides a simple and relatively lightweight mechanism for exchanging structured and typed information between services. SOAP is designed to reduce the cost and complexity of integrating applications that are built on different platforms. SOAP has undergone revisions since its introduction, and the W3C has standardized the most recent version, SOAP 1.2. SOAP is defined independently of the underlying messaging transport mechanism in use. It allows the use of many alternative transports for message exchange. SOAP messages are transmitted one way from sender to receiver. However, multiple one-way messages can be combined into more sophisticated message exchange patterns. For instance, a popular pattern is a synchronous request/response pair of messages. Messages can be routed based on the content of the headers and the data inside the message body. You can use tools developed for the XML data model to inspect and construct complete messages. Note that such benefits were not available in architectures such as DCOM, CORBA, and Java Remote Method Invocation (RMI), where protocol headers were infrastructural details that were opaque to the application. Any software agent that sends or receives messages is called a SOAP node. The node that performs the initial transmission of a message is called the original sender. The final node that consumes and processes the message is called the ultimate receiver. Any node that processes the message between the original sender and the ultimate receiver is called an intermediary. Intermediaries model the distributed processing of an individual message. The collection of intermediary nodes traversed by the message and the ultimate receiver are collectively referred to as the message path.
To allow parts of the message path to be identified, each node participates in one or more roles. The base SOAP specification defines two built-in roles: Next and UltimateReceiver. Next is a universal role in that every SOAP node, other than the sender, belongs to the Next role. UltimateReceiver is the role that the terminal node in a message path plays, which is typically the application, or in some cases, infrastructure that is performing work on behalf of the application. The body of a SOAP envelope is always targeted at the UltimateReceiver. In contrast, SOAP headers might be targeted at intermediaries or the UltimateReceiver
2.2 WS-Addressing
WS-Addressing provides an interoperable, transport-independent way of identifying message senders and receivers that are associated with message exchange. WS-Addressing decouples address information from the specific transport used by providing a mechanism to place the target, source, and other important address information directly within the Web service message. This specification defines XML elements to identify Web services endpoints and to secure end-to-end endpoint identification in messages. This specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.
WS-Addressing defines two interoperable constructs that convey information that transport protocols and messaging systems typically provide. These constructs normalize this underlying information into a uniform format that can be processed independently of transport or application. These two constructs are endpoint references and message information headers.
Description
Service description defines metadata that fully describes the characteristics of services that are deployed on a network. This metadata is important, and it is fundamental to achieving the loose coupling that is associated with an SOA. It provides an abstract definition of the information that is necessary to deploy and interact with a service.
3.1. WSDL
Web Services Description Language (WSDL) is perhaps the most mature of metadata describing Web services. It allows developers to describe the "functional" characteristics of a Web servicewhat actions or functions the service performs in terms of the messages it receives and sends. WSDL offers a standard, language-agnostic view of services it offers to clients. It also provides noninvasive future-proofing for existing applications and services and allows interoperability across the various programming paradigms, including CORBA, J2EE, and .NET.
WSDL is an XML format for describing (network) services as a set of endpoints that operate on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.
A WSDL document has two parts: abstract definitions and concrete descriptions. The abstract section defines SOAP messages in a language- and platform-independent manner. In contrast, the concrete descriptions define site-specific matters such as serialization.
3.2 Policy
As businesses depend more on technology, their ability to control access to resources and enforce their administrative policies become central requirements. In a dynamic distributed environment, this includes the need to manage and distribute these policies only to authorized entities. Recently, government regulations have increased businesses' responsibility to protect consumer information from being distributed to third parties without the individual's consent. This new privacy legislation adds to the existing set of business requirements and introduces access to customer data (and metadata) as part of the information that is critical to the day-to-day management of the business.
In a service-oriented environment, service policies have a fundamental impact on interoperability. It's important to communicate to potential requesters any policies that a service provider enforces when those policies impact the interaction either because they require requesters to follow a specific behavior or a protocol or because they imply service-side behavior that impacts requester requirements or expectations (such as following a particular privacy policy). Service policies become a critical part of service descriptions, augmenting the basic WSDL functional description with a statement of nonfunctional service behaviors. As such, Web service policies support the development of service applications and provide the means to perform both development time and runtime service discovery and selection based on nonfunctional capabilities. For example, a service can be selected from among a list of functionally equivalent services based on its support for a specific privacy policy or the security guarantees it provides.
The first set of Web Services Policy documents [WS-Policy, WS-PolicyAttachment, and WS-PolicyAssertions] was published in 2002.
Discovery Services
The transport, description, and messaging layer are fundamental to allowing Web services to communicate in an interoperable way using messages. However, to facilitate this, it is necessary to collect and store the important metadata that describes these services. The metadata must be in a form that is discoverable and searchable by users who are looking for appropriate services they require to solve some particular business problem. Also, such metadata aggregation and discovery services are a useful repository/registry in which many different organizations might want to publish the services that they host, describe the interfaces to their services, and enable domain-specific taxonomies of services.
4.1. UDDI
The Universal Description and Discovery Interface (UDDI) is a widely acknowledged specification of a Web service registry. It defines a metadata aggregation service and specifies protocols for querying and updating a common repository of Web services information. Solutions developers can query UDDI repositories at well-known locations at design time to ascertain those services that might be compatible with their requirements. After they locate a directory, they can send a series of query requests against the registry to acquire detailed information about Web services (such as who provides them and where they are hosted) and bindings to the implementation. They can then feed this information into an assortment of development time tools to generate the appropriate runtime software and messages required to invoke the required service. Solutions can also query UDDI repositories dynamically at runtime. In this scenario, the software that needs to use a service is told at execution time the type of service or interface it requires. Then it searches a UDDI repository for a service that meets its functional requirements, or a well-known partner provides it. The software then uses this information to dynamically access the service.
UDDI repositories can be provided in one of three ways:
· Public UDDI These are UDDI repositories that can serve as a resource for Internet-based Web services. An example of this is the UDDI Business Registry [UBR]hosted by a group of vendors led by IBM, Microsoft, and SAPthat is replicated across multiple hosting organizations.
· Intra Enterprise UDDI An enterprise has a private internal UDDI repository that provides much more control over which service descriptions are allowed to be placed there and used by application developers within that specific enterprise.
· Inter Enterprise UDDI This basically scopes the content of the UDDI to services that are shareable between specific business partners.
4.2. MetaData Exchange
WS-Policy proposes a framework that extends the service description features that WSDL provides. Having more refined service descriptions, qualified by specific WS-policies, supports much more accurate discovery of services that are compatible with the business application that is to be deployed. In a service registry (such as a UDDI registry), queries of WS-Policy-decorated services enable the retrieval of services that support appropriate policies in addition to the required business interface. For example, a query might request all services that support the creditAuthorization WSDL interface (port type), use Kerberos for authentication, and have an explicitly stated privacy policy. This allows a service requester to select a service provider based on the quality of the interaction that delivers its business contracts.
Although service registries are important components of some Web services environments, it is often necessary to address the request of service information directly to the service itself. The WS-MetaDataExchange specification defines protocols that support the dynamic exchange of WS-Policy and other metadata that is relevant to the service interaction (such as XML Schema and WSDL descriptions) between interacting Web services endpoints. WS-MetadataExchange allows a service requester to ask a service provider directly for all or part of its metadata, without the involvement of a third-party registry. Using the WS-MetadataExchange protocol service, endpoints can exchange policies at runtime and use them to bootstrap their interaction from information about the settings and protocols to be applied. This is especially useful when not all policy information is in a repository or when a requester receives a reference to a service through some mechanism other than a direct query on a registry. This direct dynamic exchange of policies also supports the customization of each interaction based, for example, on the identity of the other endpoint or any other aspect of the context under which the interaction takes place. This flexibility allows Web services to be designed to offer different qualities of service for different targeted audiences.
Quality of Service
Specifications in this domain are related to the quality of the experience associated with interaction with a Web service. The services in this layer specify the requirements that are associated with the overall reliability of Web services. The specific issues involving this layer include security, reliability of message delivery, and support for transactions (guaranteeing and agreeing on the outcome of a business application).
5.1. WS-Security
Security is of fundamental concern in enterprise computing. WS-Security is the basic building block for secure Web services. Today, most distributed Web services rely on transport-level support for security functions (for example, HTTPS and BASIC-Auth authentication). These approaches to security provide a basic minimum for secure communication, and the level of function they provide is significantly less than that provided by existing middleware and distributed environments. WS-Security uses existing security models (such as Kerberos and X509). The specifications concretely define how to use the existing models in an interoperable way. Multihop, multiparty Web service computations cannot be secure without WS-Security.
Security relies on predefined trust relationships. Kerberos works because participants trust the Kerberos Key Distribution Center. Public Key Infrastructure (PKI) works because participants trust the root certificate authorities. WS-Trust defines an extensible model for setting up and verifying trust relationships. The key concept in WS-Trust is a Security Token Service (STS). An STS is a distinguished Web service that issues, exchanges, and validates security tokens. WS-Trust allows Web services to set up and agree on which security servers they trust, and to rely on these servers.
Some Web service scenarios involve a short sporadic exchange of a few messages. WS-Security readily supports this model. Other scenarios involve long, multimessage conversations between the Web services. WS-Security also supports this model, but the solution is not optimal.
Protocols such as HTTP/S use public keys to perform a simple negotiation that defines conversation-specific keys. This key exchange allows more efficient security implementations and decreases the amount of information encrypted with a specific set of keys. WS-SecureConversation provides similar support for WS-Security. Participants often use WS-Security with public keys to start a conversation or session, and they use WS-SecureConversation to agree on session specific keys for signing and encrypting information.
WS-Federation allows a set of organizations to establish a single, virtual security domain. For example, a travel agent, an airline, and a hotel chain might set up such a federation. An end user who logs into any member of the federation has effectively logged into all of the members. WS-Federation defines several models for providing federated security through protocols between WS-Trust and WS-SecureConversation topologies. In addition, customers often have "properties" when they deal with an enterprise, and WS-Federation allows the setting up of a federated property space. This allows each participant to have secure controlled access to each member's property information about the end users.
5.2. Reliable Messaging
In the Internet world, communication channels are typically unreliable. Connections break, messages fail to be delivered or are delivered more than once, and perhaps in a different sequence to that in which they were sent. Communication can become even more of an issue when the exchange of messages spans multiple transport layer connections. Although techniques for ensuring reliable delivery of messages are reasonably well understood and available in some messaging middleware products today (such as IBM WebsphereMQ), messaging reliability is still a problem. If messaging reliability is addressed by Web service developers who are incorporating techniques to deal with this directly into the services they develop, there is no guarantee that developers of different Web services will make the consistent choices about the approach to adopt. The outcome might not guarantee end-to-end reliable interoperable messaging. Even in cases in which the application developers defer dealing with the reliable messaging to messaging middleware, different middleware products from different suppliers do not necessarily offer a consistent approach to dealing with the problem. Again, this might preclude reliable message exchange between applications that are using different message-oriented middleware.
WS-ReliableMessaging addresses these issues and defines protocols that enable Web services to ensure reliable, interoperable exchange of messages with specified delivery assurances. The specification defines three basic assurances:
· In-order delivery The messages are delivered in the same order in which they were sent.
· At least once delivery Each message that is sent is delivered at least one time.
· At most once delivery No duplicate messages are delivered.
5.3. Transactions
Dealing with many of today's business scenarios necessitates the development of applications that consist of multiple Web services exchanging many messages. An example might be a group of financial institutions setting up a financial offering that involves insurance policies, annuities, checking accounts, and brokerage accounts. Such applications can be complex, executing across heterogeneous, loosely coupled distributed systems that are prone to failure, and introducing significant reliability problems. For such applications, you must deal with the failure of any component Web service of the application within the context of the whole application. A coordinated orchestration of the outcome of the participating services that make up the business application is essential so that a coherent outcome of the whole business application can be agreed upon and guaranteed. Therefore, it is important that the Web services involved are able to do the following:
· Start new tasks, the execution and disposition of which are coordinated with other tasks.
· Agree on the outcome of the computation. For example, does everyone agree that the financial packages were set up?
WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity define protocols that are designed specifically to address these requirements.
WS-Coordination is a general mechanism for initiating and agreeing on the outcome of multiparty, multimessage Web service tasks. WS-Coordination has three key elements:
· A coordination context This is a message element that is associated with exchanges during the interaction of Web services. This coordination context contains the WS-Addressing endpoint reference of a coordination service, in addition to the information that identifies the specific task being coordinated.
· A coordinator service This provides a service to start a coordinated task, terminate a coordinated task, allow participants to register in a task, and produce a coordination context that is part of all messages exchanged within a group of participants.
· An interface Participating services can use the interface to inform them of an outcome that all of the participants have agreed upon.
WS-AtomicTransaction defines a specific set of protocols that plug into WS-Coordination to implement the traditional two-phase atomic ACID transaction protocols. However, traditional atomic transactions and the WS-AtomicTransaction protocol are not always suitable. For example, this protocol is generally not appropriate for use with many types of business transactions.
Transaction protocols for business transactions have to deal with long-lived activities. These differ from atomic transactions in that such activities can take much longer to complete. Therefore, to minimize latency of access by other potential users of the resources being used by Web services participating in the activity, you need to make the results of interim operations visible to others before the overall activity has completed. In light of this, you can introduce mechanisms for fault and compensation handling to reverse the effects of tasks that were completed previously within a business activity (such as compensation or reconciliation). WS-BusinessActivity defines a specific set of protocols that plug into the WS-Coordination model to provide such long-running, compensation-based transaction protocols. For example, although WS-BPEL defines a transaction model for business processes, it is WS-BusinessActivity that specifies the corresponding protocol rendering. This, again, is an example for the composeability of the Web services specifications.
Components
The existing Web services standards do not provide for the definition of the business semantics of Web services. Today's Web services are isolated and opaque. Overcoming this isolation means connecting Web services and specifying how to jointly use collections (compositions) of Web services to realize much more comprehensive and complex functionalitytypically referred to as a business process. A business process specifies the potential execution order of operations from a collection of Web services, the data that is shared between these composed Web services, which partners are involved, and how they are involved in the business process, joint exception handling for collections of Web services, and so on. This composition especially allows the specification of long-running transactions between composed Web services. Consistency and reliability are increased for Web services applications. Breaking this opaqueness of Web services means specifying usage constraints of operations of a collection of Web services and their joint behavior. This, too, is similar to specifying business processes.
6.1. Composition of Web Services
Business Process Execution Language for Web services (WS-BPEL, often shortened to BPEL) provides a language to specify business processes and process states and how they relate to Web services. This includes specifying how a business process uses Web services to achieve its goal, and it includes specifying Web services that a business process provides. Business processes specified in BPEL are fully executable and are portable between BPEL-conformant tools and environments. A BPEL business process interoperates with the Web services of its partners, whether these Web services are realized based on BPEL or not. Finally, BPEL supports the specification of business protocols between partners and views on complex internal business processes.
Reference Book:
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
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
Business Process Optimization
· 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 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.
Collaborations, Mergers, and Acquisitions
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 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.
The basic principles that underpin SOA are illustrated as follows:
First, it is necessary to provide an abstract definition of the service, including the details that allow anyone who wants to use the service to bind to it in the appropriate way. Second, those people who are the providers of services need to publish details of their services so that those who want to use them can understand more precisely what they do and can obtain the information necessary to connect to use them.
Third, those who require services need to have some way to find what services are available that meet their needs. Also, to make this bind/publish/find approach work well, standards must be defined to govern what and how to publish, how to find information, and the specific details about how to bind to the service. Web services technology is at the heart of addressing these questions and is the subject of this book. It also forms a basis for the notion of a service bus (infrastructure) that supports SOA.
High level Architecture of SOA
The bottom layer presents its capabilities to cope with various transport protocols to communicate between a service and a requester. The messaging layer on top of the transport layer enables the bus to deal with messages, both XML and non-XML. The latter is important, for example, if a requester and the service needed reside in the same J2EE application server and the bus can simply transport the data in its Java rendering, avoiding unnecessary transformations. The next layer of the bus facilitates and deals with the description of services in terms of functions supported, quality of services of these functions, and supported binding mechanisms. The actual quality of services that the bus enforces based on appropriate parameterization via polices resides in the layer that follows. This layer copes with security aspects such as message integrity, confidentiality, and nonrepudiation, but also with reliable transport of messages and various kinds of transactions. The top layer represents the various kinds of virtual components that Web services represent. This layer has atomic services that are not composed as far as a requester's experience with the service is concerned.
Composed services that the service bus inherently supports are choreographies and societies of services that cooperate following an agreement protocol to decide on the success of the cooperation at the end of the cooperation. Finally, another layer provides features for discovery of services and their descriptions and to agree on a mode of interaction between a requester and a service.
WEB SERVICES:
"Service-Oriented Architectures," SOA represents an abstract architectural concept. It's an approach to building software systems that is based on loosely coupled components (services) that have been described in a uniform way and that can be discovered and composed. Web services represents one important approach to realizing an SOA.
The World Wide Web Consortium (W3C), which has managed the evolution of the SOAP and WSDL specifications, defines Web services as follows:
A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards.
Although Web services technology is not the only approach to realizing an SOA, it is one that the IT industry as a whole has enthusiastically embraced. With Web services, the industry is addressing yet again the fundamental challenge that distributed computing has provided for some considerable time: to provide a uniform way of describing components or services within a network, locating them, and accessing them. The difference between the Web services approach and traditional approaches (for example, distributed object technologies such as the Object Management Group Common Object Request Broker Architecture (OMG CORBA), or Microsoft Distributed Component Object Model (DCOM)) lies in the loose coupling aspects of the architecture. Instead of building applications that result in tightly integrated collections of objects or components, which are well known and understood at development time, the whole approach is much more dynamic and adaptable to change. Another key difference is that through Web services, the IT industry is tackling the problems using technology and specifications that are being developed in an open way, utilizing industry partnerships and broad consortia such as W3C and the Organization for the Advancement of Structured Information Standards (OASIS), and based on standards and technology that are the foundation of the Internet.
Web services had its beginnings in mid to late 2000 with the introduction of the first version of XML messagingSOAP, WSDL 1.1, and an initial version of UDDI as a service registry. This basic set of standards has begun to provide an accepted industry-wide basis for interoperability among software components (Web services) that is independent of network location, in addition to specific implementation details of both the services and their supporting deployment infrastructure. Several key software vendors have provided these implementations, which have already been widely used to address some important business problems.
Although the value of Web services technology has been demonstrated in practice, there is a desire to use the approach to address more difficult problems. Developers are looking for enhancements that raise the level and scope of interoperability beyond the basic message exchange, requiring support for interoperation of higher-level infrastructure services. Most commercial applications today are built assuming a specific programming model. They are deployed on platforms (operating systems and middleware) that provide infrastructure services in support of that programming model, hiding complexity, and simplifying the problems that the solution developer has to deal with. For example, middleware typically provides support for transactions, security, or reliable exchange of messages (such as guaranteed, once-only delivery). On the other hand, there is no universally agreed standard middleware, which makes it difficult to construct applications from components that are built using different programming models (such as Microsoft COM, OMG CORBA, or Java 2 Platform, Enterprise Edition (J2EE) Enterprise Java Beans). They bring with them different assumptions about infrastructure services that are required, such as transactions and security. As a consequence, interoperability across distributed heterogeneous platforms (such as .NET and J2EE) presents a difficult problem.
Transport Services
Web services is basically an interoperable messaging architecture, and message transport technologies form the foundation of this architecture. Web services is inherently transport neutral. Although you can transport Web services messages by using the ubiquitous Web protocols such as HyperText Transport Protocol (HTTP) or Secure HTTP (HTTPS) to give the widest possible coverage in terms of support for the protocols , you can also transport them over any communications protocol, using proprietary ones if appropriate. Although transport protocols are fundamental to Web services and clearly are a defining factor in the scope of interoperability, the details are generally hidden from the design of Web services
Messaging:
The messaging services component of the framework contains the most fundamental Web services specifications and technologies, including eXtensible Markup Language (XML), SOAP, and WS-Addressing. Collectively, these specifications form the basis of interoperable messaging between Web services.
2.1 SOAP
SOAP, one of the significant underpinnings of Web services, provides a simple and relatively lightweight mechanism for exchanging structured and typed information between services. SOAP is designed to reduce the cost and complexity of integrating applications that are built on different platforms. SOAP has undergone revisions since its introduction, and the W3C has standardized the most recent version, SOAP 1.2. SOAP is defined independently of the underlying messaging transport mechanism in use. It allows the use of many alternative transports for message exchange. SOAP messages are transmitted one way from sender to receiver. However, multiple one-way messages can be combined into more sophisticated message exchange patterns. For instance, a popular pattern is a synchronous request/response pair of messages. Messages can be routed based on the content of the headers and the data inside the message body. You can use tools developed for the XML data model to inspect and construct complete messages. Note that such benefits were not available in architectures such as DCOM, CORBA, and Java Remote Method Invocation (RMI), where protocol headers were infrastructural details that were opaque to the application. Any software agent that sends or receives messages is called a SOAP node. The node that performs the initial transmission of a message is called the original sender. The final node that consumes and processes the message is called the ultimate receiver. Any node that processes the message between the original sender and the ultimate receiver is called an intermediary. Intermediaries model the distributed processing of an individual message. The collection of intermediary nodes traversed by the message and the ultimate receiver are collectively referred to as the message path.
To allow parts of the message path to be identified, each node participates in one or more roles. The base SOAP specification defines two built-in roles: Next and UltimateReceiver. Next is a universal role in that every SOAP node, other than the sender, belongs to the Next role. UltimateReceiver is the role that the terminal node in a message path plays, which is typically the application, or in some cases, infrastructure that is performing work on behalf of the application. The body of a SOAP envelope is always targeted at the UltimateReceiver. In contrast, SOAP headers might be targeted at intermediaries or the UltimateReceiver
2.2 WS-Addressing
WS-Addressing provides an interoperable, transport-independent way of identifying message senders and receivers that are associated with message exchange. WS-Addressing decouples address information from the specific transport used by providing a mechanism to place the target, source, and other important address information directly within the Web service message. This specification defines XML elements to identify Web services endpoints and to secure end-to-end endpoint identification in messages. This specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.
WS-Addressing defines two interoperable constructs that convey information that transport protocols and messaging systems typically provide. These constructs normalize this underlying information into a uniform format that can be processed independently of transport or application. These two constructs are endpoint references and message information headers.
Description
Service description defines metadata that fully describes the characteristics of services that are deployed on a network. This metadata is important, and it is fundamental to achieving the loose coupling that is associated with an SOA. It provides an abstract definition of the information that is necessary to deploy and interact with a service.
3.1. WSDL
Web Services Description Language (WSDL) is perhaps the most mature of metadata describing Web services. It allows developers to describe the "functional" characteristics of a Web servicewhat actions or functions the service performs in terms of the messages it receives and sends. WSDL offers a standard, language-agnostic view of services it offers to clients. It also provides noninvasive future-proofing for existing applications and services and allows interoperability across the various programming paradigms, including CORBA, J2EE, and .NET.
WSDL is an XML format for describing (network) services as a set of endpoints that operate on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.
A WSDL document has two parts: abstract definitions and concrete descriptions. The abstract section defines SOAP messages in a language- and platform-independent manner. In contrast, the concrete descriptions define site-specific matters such as serialization.
3.2 Policy
As businesses depend more on technology, their ability to control access to resources and enforce their administrative policies become central requirements. In a dynamic distributed environment, this includes the need to manage and distribute these policies only to authorized entities. Recently, government regulations have increased businesses' responsibility to protect consumer information from being distributed to third parties without the individual's consent. This new privacy legislation adds to the existing set of business requirements and introduces access to customer data (and metadata) as part of the information that is critical to the day-to-day management of the business.
In a service-oriented environment, service policies have a fundamental impact on interoperability. It's important to communicate to potential requesters any policies that a service provider enforces when those policies impact the interaction either because they require requesters to follow a specific behavior or a protocol or because they imply service-side behavior that impacts requester requirements or expectations (such as following a particular privacy policy). Service policies become a critical part of service descriptions, augmenting the basic WSDL functional description with a statement of nonfunctional service behaviors. As such, Web service policies support the development of service applications and provide the means to perform both development time and runtime service discovery and selection based on nonfunctional capabilities. For example, a service can be selected from among a list of functionally equivalent services based on its support for a specific privacy policy or the security guarantees it provides.
The first set of Web Services Policy documents [WS-Policy, WS-PolicyAttachment, and WS-PolicyAssertions] was published in 2002.
Discovery Services
The transport, description, and messaging layer are fundamental to allowing Web services to communicate in an interoperable way using messages. However, to facilitate this, it is necessary to collect and store the important metadata that describes these services. The metadata must be in a form that is discoverable and searchable by users who are looking for appropriate services they require to solve some particular business problem. Also, such metadata aggregation and discovery services are a useful repository/registry in which many different organizations might want to publish the services that they host, describe the interfaces to their services, and enable domain-specific taxonomies of services.
4.1. UDDI
The Universal Description and Discovery Interface (UDDI) is a widely acknowledged specification of a Web service registry. It defines a metadata aggregation service and specifies protocols for querying and updating a common repository of Web services information. Solutions developers can query UDDI repositories at well-known locations at design time to ascertain those services that might be compatible with their requirements. After they locate a directory, they can send a series of query requests against the registry to acquire detailed information about Web services (such as who provides them and where they are hosted) and bindings to the implementation. They can then feed this information into an assortment of development time tools to generate the appropriate runtime software and messages required to invoke the required service. Solutions can also query UDDI repositories dynamically at runtime. In this scenario, the software that needs to use a service is told at execution time the type of service or interface it requires. Then it searches a UDDI repository for a service that meets its functional requirements, or a well-known partner provides it. The software then uses this information to dynamically access the service.
UDDI repositories can be provided in one of three ways:
· Public UDDI These are UDDI repositories that can serve as a resource for Internet-based Web services. An example of this is the UDDI Business Registry [UBR]hosted by a group of vendors led by IBM, Microsoft, and SAPthat is replicated across multiple hosting organizations.
· Intra Enterprise UDDI An enterprise has a private internal UDDI repository that provides much more control over which service descriptions are allowed to be placed there and used by application developers within that specific enterprise.
· Inter Enterprise UDDI This basically scopes the content of the UDDI to services that are shareable between specific business partners.
4.2. MetaData Exchange
WS-Policy proposes a framework that extends the service description features that WSDL provides. Having more refined service descriptions, qualified by specific WS-policies, supports much more accurate discovery of services that are compatible with the business application that is to be deployed. In a service registry (such as a UDDI registry), queries of WS-Policy-decorated services enable the retrieval of services that support appropriate policies in addition to the required business interface. For example, a query might request all services that support the creditAuthorization WSDL interface (port type), use Kerberos for authentication, and have an explicitly stated privacy policy. This allows a service requester to select a service provider based on the quality of the interaction that delivers its business contracts.
Although service registries are important components of some Web services environments, it is often necessary to address the request of service information directly to the service itself. The WS-MetaDataExchange specification defines protocols that support the dynamic exchange of WS-Policy and other metadata that is relevant to the service interaction (such as XML Schema and WSDL descriptions) between interacting Web services endpoints. WS-MetadataExchange allows a service requester to ask a service provider directly for all or part of its metadata, without the involvement of a third-party registry. Using the WS-MetadataExchange protocol service, endpoints can exchange policies at runtime and use them to bootstrap their interaction from information about the settings and protocols to be applied. This is especially useful when not all policy information is in a repository or when a requester receives a reference to a service through some mechanism other than a direct query on a registry. This direct dynamic exchange of policies also supports the customization of each interaction based, for example, on the identity of the other endpoint or any other aspect of the context under which the interaction takes place. This flexibility allows Web services to be designed to offer different qualities of service for different targeted audiences.
Quality of Service
Specifications in this domain are related to the quality of the experience associated with interaction with a Web service. The services in this layer specify the requirements that are associated with the overall reliability of Web services. The specific issues involving this layer include security, reliability of message delivery, and support for transactions (guaranteeing and agreeing on the outcome of a business application).
5.1. WS-Security
Security is of fundamental concern in enterprise computing. WS-Security is the basic building block for secure Web services. Today, most distributed Web services rely on transport-level support for security functions (for example, HTTPS and BASIC-Auth authentication). These approaches to security provide a basic minimum for secure communication, and the level of function they provide is significantly less than that provided by existing middleware and distributed environments. WS-Security uses existing security models (such as Kerberos and X509). The specifications concretely define how to use the existing models in an interoperable way. Multihop, multiparty Web service computations cannot be secure without WS-Security.
Security relies on predefined trust relationships. Kerberos works because participants trust the Kerberos Key Distribution Center. Public Key Infrastructure (PKI) works because participants trust the root certificate authorities. WS-Trust defines an extensible model for setting up and verifying trust relationships. The key concept in WS-Trust is a Security Token Service (STS). An STS is a distinguished Web service that issues, exchanges, and validates security tokens. WS-Trust allows Web services to set up and agree on which security servers they trust, and to rely on these servers.
Some Web service scenarios involve a short sporadic exchange of a few messages. WS-Security readily supports this model. Other scenarios involve long, multimessage conversations between the Web services. WS-Security also supports this model, but the solution is not optimal.
Protocols such as HTTP/S use public keys to perform a simple negotiation that defines conversation-specific keys. This key exchange allows more efficient security implementations and decreases the amount of information encrypted with a specific set of keys. WS-SecureConversation provides similar support for WS-Security. Participants often use WS-Security with public keys to start a conversation or session, and they use WS-SecureConversation to agree on session specific keys for signing and encrypting information.
WS-Federation allows a set of organizations to establish a single, virtual security domain. For example, a travel agent, an airline, and a hotel chain might set up such a federation. An end user who logs into any member of the federation has effectively logged into all of the members. WS-Federation defines several models for providing federated security through protocols between WS-Trust and WS-SecureConversation topologies. In addition, customers often have "properties" when they deal with an enterprise, and WS-Federation allows the setting up of a federated property space. This allows each participant to have secure controlled access to each member's property information about the end users.
5.2. Reliable Messaging
In the Internet world, communication channels are typically unreliable. Connections break, messages fail to be delivered or are delivered more than once, and perhaps in a different sequence to that in which they were sent. Communication can become even more of an issue when the exchange of messages spans multiple transport layer connections. Although techniques for ensuring reliable delivery of messages are reasonably well understood and available in some messaging middleware products today (such as IBM WebsphereMQ), messaging reliability is still a problem. If messaging reliability is addressed by Web service developers who are incorporating techniques to deal with this directly into the services they develop, there is no guarantee that developers of different Web services will make the consistent choices about the approach to adopt. The outcome might not guarantee end-to-end reliable interoperable messaging. Even in cases in which the application developers defer dealing with the reliable messaging to messaging middleware, different middleware products from different suppliers do not necessarily offer a consistent approach to dealing with the problem. Again, this might preclude reliable message exchange between applications that are using different message-oriented middleware.
WS-ReliableMessaging addresses these issues and defines protocols that enable Web services to ensure reliable, interoperable exchange of messages with specified delivery assurances. The specification defines three basic assurances:
· In-order delivery The messages are delivered in the same order in which they were sent.
· At least once delivery Each message that is sent is delivered at least one time.
· At most once delivery No duplicate messages are delivered.
5.3. Transactions
Dealing with many of today's business scenarios necessitates the development of applications that consist of multiple Web services exchanging many messages. An example might be a group of financial institutions setting up a financial offering that involves insurance policies, annuities, checking accounts, and brokerage accounts. Such applications can be complex, executing across heterogeneous, loosely coupled distributed systems that are prone to failure, and introducing significant reliability problems. For such applications, you must deal with the failure of any component Web service of the application within the context of the whole application. A coordinated orchestration of the outcome of the participating services that make up the business application is essential so that a coherent outcome of the whole business application can be agreed upon and guaranteed. Therefore, it is important that the Web services involved are able to do the following:
· Start new tasks, the execution and disposition of which are coordinated with other tasks.
· Agree on the outcome of the computation. For example, does everyone agree that the financial packages were set up?
WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity define protocols that are designed specifically to address these requirements.
WS-Coordination is a general mechanism for initiating and agreeing on the outcome of multiparty, multimessage Web service tasks. WS-Coordination has three key elements:
· A coordination context This is a message element that is associated with exchanges during the interaction of Web services. This coordination context contains the WS-Addressing endpoint reference of a coordination service, in addition to the information that identifies the specific task being coordinated.
· A coordinator service This provides a service to start a coordinated task, terminate a coordinated task, allow participants to register in a task, and produce a coordination context that is part of all messages exchanged within a group of participants.
· An interface Participating services can use the interface to inform them of an outcome that all of the participants have agreed upon.
WS-AtomicTransaction defines a specific set of protocols that plug into WS-Coordination to implement the traditional two-phase atomic ACID transaction protocols. However, traditional atomic transactions and the WS-AtomicTransaction protocol are not always suitable. For example, this protocol is generally not appropriate for use with many types of business transactions.
Transaction protocols for business transactions have to deal with long-lived activities. These differ from atomic transactions in that such activities can take much longer to complete. Therefore, to minimize latency of access by other potential users of the resources being used by Web services participating in the activity, you need to make the results of interim operations visible to others before the overall activity has completed. In light of this, you can introduce mechanisms for fault and compensation handling to reverse the effects of tasks that were completed previously within a business activity (such as compensation or reconciliation). WS-BusinessActivity defines a specific set of protocols that plug into the WS-Coordination model to provide such long-running, compensation-based transaction protocols. For example, although WS-BPEL defines a transaction model for business processes, it is WS-BusinessActivity that specifies the corresponding protocol rendering. This, again, is an example for the composeability of the Web services specifications.
Components
The existing Web services standards do not provide for the definition of the business semantics of Web services. Today's Web services are isolated and opaque. Overcoming this isolation means connecting Web services and specifying how to jointly use collections (compositions) of Web services to realize much more comprehensive and complex functionalitytypically referred to as a business process. A business process specifies the potential execution order of operations from a collection of Web services, the data that is shared between these composed Web services, which partners are involved, and how they are involved in the business process, joint exception handling for collections of Web services, and so on. This composition especially allows the specification of long-running transactions between composed Web services. Consistency and reliability are increased for Web services applications. Breaking this opaqueness of Web services means specifying usage constraints of operations of a collection of Web services and their joint behavior. This, too, is similar to specifying business processes.
6.1. Composition of Web Services
Business Process Execution Language for Web services (WS-BPEL, often shortened to BPEL) provides a language to specify business processes and process states and how they relate to Web services. This includes specifying how a business process uses Web services to achieve its goal, and it includes specifying Web services that a business process provides. Business processes specified in BPEL are fully executable and are portable between BPEL-conformant tools and environments. A BPEL business process interoperates with the Web services of its partners, whether these Web services are realized based on BPEL or not. Finally, BPEL supports the specification of business protocols between partners and views on complex internal business processes.
Reference Book:
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
No comments:
Post a Comment