Build Message-Based Web Services for SOA
Download as PPT, PDF5 likes1,422 views
The document outlines the development of message-based web services within a service-oriented architecture (SOA), highlighting the importance of services as autonomous components that utilize XML messages and are defined by WSDL. It provides a step-by-step guide for creating message-oriented and service-oriented web services, including designing data types, implementing interfaces, and generating client proxies. Additionally, it introduces Web Services Enhancements (WSE) for security and messaging capabilities, emphasizing the role of well-defined interfaces and dedicated business logic for efficient service implementation.
![About Me Jeffrey Hasan [email_address] President, Bluestone Partners Inc. A technology services company based in Orange County. We build business applications using .NET; our speciality is Service Oriented Architecture. (Co-) Author of: Performance Tuning and Optimizing ASP.NET Applications, APress, 2003. ISBN: 1590590724. ADO.NET Programmer’s Reference, Wrox Press, 2001. Professional .NET Framework, Wrox Press, 2001. Professional VB6 Web Programming, Wrox Press, 1999. Articles for MSDN Magazine and Advisor Media publications.](https://image.slidesharecdn.com/soa-090326115426-phpapp02/85/Build-Message-Based-Web-Services-for-SOA-3-320.jpg)
Build Message-Based Web Services for SOA
- 1. Build Message-Based Web Services for Service Oriented Architecture Jeffrey Hasan, MCSD President Bluestone Partners, Inc.
- 2. Talk Agenda Overview of SOA Build a Message-Oriented Web Service Build a Service-Oriented Web Service WSDL Overview Introducing the Web Services Enhancements 2.0 (WSE)
- 3. About Me Jeffrey Hasan [email_address] President, Bluestone Partners Inc. A technology services company based in Orange County. We build business applications using .NET; our speciality is Service Oriented Architecture. (Co-) Author of: Performance Tuning and Optimizing ASP.NET Applications, APress, 2003. ISBN: 1590590724. ADO.NET Programmer’s Reference, Wrox Press, 2001. Professional .NET Framework, Wrox Press, 2001. Professional VB6 Web Programming, Wrox Press, 1999. Articles for MSDN Magazine and Advisor Media publications.
- 4. New SOA Book Expert Service Oriented Architecture in C# Using the Web Services Enhancements 2.0 Published by: APress (August 2004) http://www.bluestonepartners.com/soa
- 5. What is a Service? A service is a distributed component that provides a well-defined interface for processing and delivering XML messages A service is the basic building block of a loosely-coupled, distributed application.
- 6. SOA Example
- 8. Services In Depth Services are autonomous components that process well-defined XML. Services provide a well-defined interface that is described by an XML-based document called the Web Services Definition Language (WSDL) document . Services provide endpoints that consumers and other services can bind to, based on the service’s port address (typically a URL) Services are analogous to traditional object-oriented (OO), type-based components
- 9. Services Versus OO-Components Services are described by a WSDL contract, not by type libraries Documents metadata; ports; bindings Service descriptions can be easily extended Services provide flexible binding WSDL document provides metadata descriptions; clients can dynamically bind Services provide a service guarantee Policy files document service agreements and expectations Services allow for things to go wrong Addressing; Reliable Messaging XML messages preserve the integrity of requests; and provide a record of communication
- 10. SOA in Practice
- 11. SOA Architecture - Basic
- 12. Service Interface - Support Communication requirements that the service specifies in its WSDL contract (specifically, in its binding information). This includes the format and transport protocols that the service responds to (e.g., SOAP over HTTP). Security requirements that the service specifies. In .NET terms, the .asmx code-behind can implement code that verifies incoming XML messages to ensure that they contain the required security tokens or headers. Methods (operations) that the service specifies in its WSDL contract. In .NET terms, the .asmx file provides methods that correspond to the service operations, but the actual business processing should be handed off to dedicated components and workflow.
- 13. SOA Architecture - Advanced
- 14. WS Communication
- 15. Why Use Services? A service-based approach makes sense for building solutions that cross organizational, departmental and corporate domain boundaries. A business with multiple systems and applications on different platforms can use SOA to build a loosely-coupled integration solution that implements unified workflows.
- 16. How to Build Message-Oriented Web Services
- 17. XML Messages I
- 18. XML Messages II <Quote> <Symbol>MSFT</Symbol> <Company>Microsoft Corporation</Company> <DateTime>11/17/2003 16:00:00</DateTime> <High>26.12</High> <Low>24.68</Low> <Open>25.49</Open> <Last>25.15</Last> <Change>-0.36</Change> <PercentChange>-0.0137</PercentChange> <Previous_Close>25.49</Previous_Close> <High_52_Week>35</High_52_Week> <Low_52_Week>22</Low_52_Week> </Quote>
- 20. StockTrader Web Service Types
- 21. Step #1: Design Schema Step 1: Design the messages and the data types Conceptually design what the messages and data types will look like. UML class diagrams are the best way to capture this information.
- 22. Step #2: Build XSD Schema Step 2: Build the XSD schema file for the data types Use an XML designer tool to build the XSD schema file for all of the data types that are exchanged by the Web service methods. Visual Studio .NET’s XML Designer is a good tool, but you can use any XML Designer tool that you are comfortable working with.
- 23. Step #3: Create Class Interface Step 3: Create a class file of interface definitions for the messages and data types. The interface definition class file provides the abstract definitions of the Web service methods and its data types. This class file derives from the System.Web.Services.WebService class, so it can be readily implemented in a Web services code-behind file. The .NET Framework provides a command-line tool called xsd.exe for generating an interface definition class file based on an XSD schema file. This will manually generate class definitions for the data types. You can add this class file to your Web service project and then manually insert abstract definitions for the Web methods.
- 24. Step #4: Implement Interface Step 4: Implement the interface in the Web service code-behind file Implement code for the Web methods. The Web service .asmx code-behind class derives from the System.Web.Services.WebService class by default, as does the interface definition class file from Step 3. So you can derive the .asmx code-behind class directly from the interface definition class instead, and then implement code for each of the methods.
- 25. Step #5: Generate Proxy Class Step #5: Generate a proxy class file for clients based on the WSDL document Web services have no reason to exist unless they are being used by clients. In this step you generate a proxy class file based on the Web service WSDL document so that clients know how to call your Web service, and what messages and data types will be exchanged. The wsdl.exe command-line tool will automatically generate this proxy class for you based on the WSDL document. And Visual Studio .NET will automatically generate the WSDL document for you, so no manual work is required (use Add Reference)
- 26. Step #6: Create Client Step 6: Implement a Web service client using a proxy class file The client essentially does nothing more than delegate method calls out to the Web service. Valid clients include Web applications, Windows Forms applications, Console applications, or even other Web services.
- 27. How to Build Service-Oriented Web Services
- 28. SOA Web Services Web services should not implement business logic directly in their methods They should delegate this processing to dedicated business assemblies. This is because you cannot assume that the business logic will always be accessed through a Web service. Web services and their associated WSDL documents should not be the original reference points for interface definitions This information belongs in a dedicated reference assembly, and should be stored as an interface definition that can be implemented in different kinds of components.
- 30. Step #1: Create a dedicated type definition assembly Step 1: Create a dedicated type definition assembly Create a dedicated definition assembly for interfaces and type definitions. This assembly will be referenced by any component, service or application that needs to use the interfaces or types.
- 31. Step #2: Create a dedicated business assembly Step 2: Create a dedicated business assembly Create a dedicated business assembly that implements logic for established interfaces and type definitions. This business assembly must reference the definition assembly from Step 1. This ensures that the business assembly implements every available method definition. Once this step is complete you now have the flexibility to build any kind of n-Tier solution using the definition and business assemblies. This point underscores the fact that in a Service Oriented Architecture, Web services are simply a gateway to a set of methods and types that are controlled by other assemblies. The Web service itself simply provides a set of SOAP-enabled endpoints that are accessible over one or more transport protocols.
- 32. Step #3: Create the Web service Step 3: Create the Web service based on the type definition assembly In the previous version of the StockTrader Web service the definition information for the Web method implementations came from a dedicated interface definition file, which provided abstract class definitions and class-based type definitions. But now this file is no longer needed because we have a dedicated definition assembly. The new Web service simply needs to import the definition assembly to have access to the required types, and to the required interface.
- 33. Step #4: Implement the Interface + Import the Business Assembly Step 4: Implement the business interface in the Web service The Web service needs to import the business assembly so that it can delegate incoming service requests. Remember, the current architecture calls for a different level of abstraction, where the Web service itself does not control its interface, its data types or the processing of business logic. Instead, it relies on other assemblies for this reference information, and for this processing capability. By implementing the interface you are ensured not to miss any methods, because the project will not compile unless every interface method is implemented in the Web service. So, the definition assembly provides the interface definition, while the business assembly provides the processing capability for each method. All incoming Web service requests should be delegated to the business component, rather than implementing the business logic directly in the Web service.
- 34. Step #5: Generate Proxy Class Step #5: Generate a proxy class file for clients based on the WSDL document Web services have no reason to exist unless they are being used by clients. In this step you generate a proxy class file based on the Web service WSDL document so that clients know how to call your Web service, and what messages and data types will be exchanged. The wsdl.exe command-line tool will automatically generate this proxy class for you based on the WSDL document. And Visual Studio .NET will automatically generate the WSDL document for you, so no manual work is required (use Add Reference)
- 35. Step #6: Create a Tightly-Coupled Client Step 6: Implement a tightly-coupled Web service client using a proxy class file and an interface definition assembly The Web service client uses the generated proxy class file from Step 5 to set a reference to the new Web service. The client must also reference the type definition assembly from Step 1, so that they have a common understanding of the data types that are used by the Web services and its associated business assembly. This approach is warranted when you have a sensitive business workflow, and you want to prevent any kind of miscommunication between a service and a client.
- 36. WSDL Overview
- 37. WSDL Overview Web Services Description Language WS-I Basic Profile (WSDL 1.1) WSDL documents: Operations that the WS supports Messages that the WS exchanges Data types that these messages use both intrinsic and custom Everything is qualified Can be generated from VS .NET
- 38. WSDL Elements A WSDL Document contains seven primary XML elements (+ the root <xml> element) Abstract description XML elements that document the Web service interface, including the methods that it supports, the input parameters, and the return types Concrete implementation XML elements that show the client how to physically bind to the Web service and to use its supported operations
- 39. WSDL Abstract Elements <types /> Equivalent to an XSD schema file <message /> describes a SOAP message, which may be an input, output or fault message for a Web service operation <operation /> Analogous to method definitions; groups associated messages into operations Indicates direction (one-way; notification; request/response) <portType /> Abstract definition of a Web service; provided as a summary of operations
- 40. WSDL Concrete Elements <binding /> Links an abstract Web service definition to an actual Web service, by associating the operation/message definitions to an XML namespace <port /> Documents the physical location (URI) of the Web service Contains a <binding /> element <service /> Encloses one or more <port /> elements Provides a unified service definition of the abstract and concrete service elements
- 42. WSE Overview
- 44. WSE Overview WS-Security : A wide-ranging specification that integrates a set of popular security technologies, including digital signing and encryption based on security tokens, including X.509 certificates. WS-Policy : Allows Web services to document their requirements, preferences and capabilities for a range of factors, though mostly focused on security. For example, a Web service policy will include its security requirements, such as encryption and digital signing based on an X.509 certificate. WS-Addressing : Identifies service endpoints in a message and allows for these endpoints to remain updated as the message is passed along through two or more services. It largely replaces the earlier WS-Routing specification. WS-Messaging : Provides support for alternate transport channel protocols besides HTTP, including TCP. It simplifies the development of messaging applications, including asynchronous applications that communicate using SOAP over HTTP. WS-Secure Conversation : Establishes session-oriented trusted communication sessions using security tokens. WS-Reliable Messaging : Provides mechanisms to help ensure the reliable delivery of messages even when one or more services in the chain are unavailable. This specification includes message delivery notifications so that a sender knows whether a receiver has successfully obtained a sent message.