of 25

Secure & Reliable&Transacted Web Services_ Architecture and Composition | Service Oriented Architecture | Web Service

4 views
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Description
Web Services Technical Articles Secure, Reliable, Transacted Web Services: Architecture and Composition September 2003 IBM Corporation Donald F. Ferguson IBM Fellow and Chairman IBM Software Group Architecture Board Tony Storey IBM Fellow John Shewchuk Web Services Architect Microsoft Corporation Brad Lovering Distinguished Engineer Contents 1.0 Introduction 1.1 Composable Services 1.2 An Example of Composition in Practice 2.0 Web Services: A Service-Oriented Architecture 2.1 Services are desc
Tags
Transcript
  Web Services Technical Articles Secure, Reliable, Transacted Web Services:Architecture and Composition  September 2003 IBM Corporation   Donald F. Ferguson  IBM Fellow and ChairmanIBM Software Group Architecture Board Tony Storey IBM Fellow Microsoft Corporation   Brad Lovering Distinguished Engineer   John Shewchuk  Web Services Architect Contents 1.0 Introduction   1.1 Composable Services   1.2 An Example of Composition in Practice2.0 Web Services: A Service-Oriented Architecture   2.1 Services are described by schema and contract not type   2.2 Service compatibility is more than type compatibility   2.3 Service-orientation assumes that bad things can and will happen   2.4 Service-orientation enables flexible binding of services3.0 Web Service Specifications and Functions   3.1 A Composable Approach to Web Services   3.2 The Basics – Transports and Messaging   3.2.1 Transports – HTTP, HTTP/S, SMTP   3.2.2 Message Formats – XSD   3.2.3 WS-Addressing   3.3 Description   3.3.1 WSDL3.3.2 WS-Policy   3.3.3 Obtaining Descriptions   3.3.4 WS-MetadataExchange3.3.5 UDDI   3.4 Service Assurances   3.5 Security3.5.1 WS-Security   3.5.2 WS-Trust   3.5.3 WS-SecureConversation   3.5.4 WS-Federation   3.6 Reliable Messaging3.6.1 WS-ReliableMessaging   3.7 Transactions   3.7.1 WS-Coordination   3.7.2 WS-AtomicTransaction    3.7.3 WS-BusinessActivity   3.8 Service Composition   3.8.1 BPEL4WS4.0 Web Services in Practice – An Example   4.1 Part 1: The Customer Experience   4.2 Part 2: The Supplier Experience5.0 Conclusions6.0 Acknowledgements 1.0 Introduction  Today Web services—specifically distributed services that process XML-encoded SOAPmessages, sent over HTTP, and described using Web Services Description Language (WSDL)—are being deployed broadly. (The terms XML, SOAP, and HTTP are in common use todayand in many respects their use has moved beyond their srcinal acronyms. Forcompleteness these acronyms are listed here: XML—eXtensible Markup Language, SOAP—Simple Object Access Protocol, and HTTP—HyperText Transfer Protocol.) Web services areused in a range of application integration scenarios: from simple, ad hoc, behind-the-firewall,data sharing to very large-scale Internet retailing and currency trading. And increasinglyWeb services are being applied in mobile, device, and grid scenarios.Web services provide interoperability between software components that can communicatebetween different companies and can reside on different infrastructures. This solves one of the most critical problems that customers, software developers, and partners face. HTTP andSOAP provide communication and message interoperability. WSDL provides the descriptionof the service to support interoperability between development tools; it complementscommunication interoperability with the ability to exchange interface definitions. The basic set of Web service specifications enables customers and software vendors to solveimportant problems. Building on their success, many developers and companies are ready totackle more difficult problems with Web service technology. The very success of Webservices has led developers to desire even more capabilities from Web services. Sincemeaningful tool and communication interoperability has been successful, developers nowexpect the enhanced functions to interoperate.In addition to basic message interoperability and interface exchange, developersincreasingly require that higher-level application services interoperate. Many commercialapplications execute in an environment ( middleware or operating systems ) that providesupport for functions like security and transactions.IBM, Microsoft, and others in the industry are often asked to make Web services moresecure, more reliable, and better able to support transactions. In addition we are asked toprovide these capabilities while retaining the essential simplicity and interoperability foundin Web services today. This paper provides a succinct overview for the set of Web service specifications thataddress these needs. For the details of the specifications we provide references to the actualdocuments. The main purpose of this paper is to briefly define the value these specificationsprovide to our customers. We also describe how these specifications complement each otherto compose robust environments for distributed applications.We face a key engineering challenge: How do we give Web services new security, reliability,and transaction capabilities without adding more complexity than needed?  1.1 Composable Services As we've done with SOAP and WSDL , IBM, Microsoft, and our partners have followed thedesign principle of  composability  in the definition of Web service specifications. Theapproach we have followed is based on the design principle of  composability  in the definitionof Web service specifications. Each specification we developed solves an immediate needand is valuable in its own right. For example, developers can adopt reliable messaging tosimplify their solution development or adopt BPEL4WS to define their service compositions.And while each specification stands on its own, they are designed to be combined and workwith each other.We use the term composability  to describe independent specifications that can be combinedto provide more powerful capabilities. Operating system and middleware providers cansupport composed capabilities, e.g. providers can integrate reliable messaging support forcommunicating BPEL4WS processes. This example combines two independent specificationsto simplify the development of communicating processes by eliminating the need to handlemessage communication errors during process design.Composability enables incremental consumption or  progressive discovery  of new concepts,tools and services. Developers only need to learn and implement what is necessary, and nomore. The complexity of the solution increases only because the problem's requirementsincrease, and is not due to technology bloat. Composability has and continues to be one of the key design goals for Web services. Overthe last several years we have defined the most basic Web service specifications (SOAP andWSDL) to inherently support composition. One of the fundamental characteristics of a Webservice is a regular, multi-part message structure. This structure enables the composition of new functionality. New message elements supporting new services may be added tomessages in a manner that does not alter the processing of existing functionality. Forexample, it is possible to independently add transaction identifiers and reliable messagingsequence numbers. The two extensions do not conflict with each other and are compatiblewith pre-existing message structures.  Figure 1. Composability allows for using elements on an as-needed basis. Figure 1 shows a simple Web services message that contains elements for WS-Addressing ,  WS-Security , and WS-ReliableMessaging . Notice that the WS-Addressing, WS-Security and WS-ReliableMessaging elements are independent and these elements can be usedindependently without altering the processing of other elements. This characteristic enable security, reliability, and transactions to be defined in terms of  composable message elements. The notion of composition also allows for the creation of a specific set of well-definedcomposable Web services that support security, reliability, etc. These well-defined servicesspecify the behavior of services necessary to support higher-level Web service functionality.An example is the Secure Token Service defined in WS-Trust that issues and validatessecurity elements in messages.Moreover, it is important that consumers of a service be able to determine the supportedand required service assurances. The services must document their requirements andsupport for transactions, security, reliable messaging, etc. WS-Policy enables Web servicesto incrementally augment their WSDL to document what transaction, security and reliabilityfunctions they support or require. WSDL and WS-Policy enable composition for the descriptionof services. This in turn enables the other parties to understand what message elements andhigher-level services to employ when interacting with the service. 1.2 An Example of Composition in Practice Figure 2 provides an overview that shows composition in practice. A customer and a supplieruse Web services to process orders.
Related Search
Advertisements
Related Docs
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks