Technologies for SOA CHAPTER CONTENTS a Q Technologies for Service Enablement Restful Web Services SOAP Web Services XML (eXtensible Markup Language) SOAP (Simple Object Access Protocol) Web Services Definition Language (WSDL) 000000 Platform and Relational Database Support for Web Services Technologies for Service Integration O. Service Integration with ESB Technologies for Service Orchestration SummaryTECHNOL 148 « OGIES FOR so, LEARNING OBJECTIVES ; oe ————— ‘After reading this chapter, you would be able to: © Learn about the technologies . Study the technologies for for service enablement: REST- service integration: Service ful Web Services, SOAP Web integration with ESB. Services; JAX WS for Java EE * Examine the technologies for Platform; XML Web Services for service orchestration, .NET Platform. * Service enablement of relational databases. ——_ mplementation of enterprise-wide SOA involves identification of technolo- Te for service enablement, integration and orchestration and development of SOA layers identified in Chapter 4 with the chosen technologies. ‘Two types of tachnologies can be considered for enterprise-wide SOA: 1. Generic technologies: The following types of technologies are referred to here as generic technologies: © platform-supported technologies; © standards-based technologies. 2. Vendor-specific technologies: Tools from vendors that support generic technologies but offer additional capabilities for improved productiv- ity and quality are referred to here as vendor-specific technologies. (The vendor-specific technologies mentioned in this chapter are meant to be indicative and not a comprehensive source of all the available tools.) This chapter presents generic and vendor-specific technologies for service enablement, integration and orchestration. 9.1 __ TECHNOLOGIES FOR SERVICE ENABLEMENT — oe eee eee Service enablement, as discussed in Chapter 4, involves exposing coarse- grained functionalities as services that are invoked by service consumers. Hence, the technologies for service enablement include those that allow service providers to expose services and service consumers to invoke the exposed services. The generic technologies for service enablement include: 1. RESTful Web services. 2. SOAP Web services.9.1 TECHNOLOGIES FOR S"RVICE ENABLEMENT 149 a . RESTful Web Services REST stands for REpresentative State Fielding, REST is an architectural enablement (Fielding, 2000). The ubiquitous nature of Internet based on Hypertext Transfer Protocol (HTTP) has made it feasible to exchange data efficiently over it. Also, poli- cies of organizations allow HTTP Protocol to be permitted over firewalls for access to the Internet. HTTP, thus, presents a transport mechanism for service invocations. The conversational nature of HTTP can be extended to enable interactions between service consumers and service providers. In RESTful web services (or RESTful web API), service consumers (clients) initiate requests to service providers (servers) which process requests and return appropriate Tesponses. Service consumers can either be transitioning between application states or be “at rest”. A service consumer sends requests using four methods provided by HTTP (namely GET, POST, PUT and DELETE) when it is ready to transition to a new state. The format of data supported by a RESTful web service is MIME (e.g., JSON, XML). When one or more requests are outstanding, the service consumer is considered to be transitioning states. The service “transfers” the state of the service consumer through the response it provides. The representation of each state of service consumer contains a resource (typically a document identified by a Uniform Resource identifier) that may be used when the service consumer subsequently chooses to initiate astate transition (Wikipedia, 2010). Transfer. A term coined by Roy style that may be used for service RESTful web services offer lower overhead in interactions between service providers and service consumers when compared with SOAP web services discussed in the next sub-section. Several vendor-specific tools are available for service enablement of which the key technologies are listed in Table 9-1. SOAP Web Services Akey technology that is platform- and vendor-neutral and widely supported to expose identified functionality as a service is SOAP web services. W3C defines web service as “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 an XML serialization in con- junction with other Web-related standards” (W3C, 2004). In accordance with the W3C definition, the term “web service” is used in this book to mean SOAP web service. (The term “RESTful web service” is explicitly used when REST based approach is used to implementa web service.)150 * TECHNOLOGIES FOR so, TABLE 9-1 Tools for web service development Tools/Products Web Service Vendor Website Reference > Development Vendors Tools Apache Axis http: //ws.apache.org/axis CXF http: //cxf.apache.org/ Embarcadero http://www.embarcadero.com/ JBuilder products/jbuilder IBM RAD for WAS http: //www-306.ibm.com/ software/awdtools/developer/ WSAD http://www.ibm.com/developer- works/library /i-wsad/ application/index.html Microsoft Visual http://msdn2.microsoft.com/ Studio.NET en-us/vstudio/default.aspx Web Service http://msdn.microsoft.com/ Software Factory en-us/library /aa480534.aspx Metro JAX-WS, JAXB https: //metro.dev.java.net Oracle JDeveloper http://www.oracle.com/ technology /products/jdev Proxisoft Netrifex http://proxisoft.com In simple terms, web services involve communication of XML over a transport protocol such as HTTP or SMTP. Web services have two objectives: 1. To enable interoperability between heterogeneous systems. This is achieved through exchange of data based on a technology-neutral XML which is a canonical format. 2. To provide a standard approach to define service interfaces indepen- dent of technology. The Web Services Definition Language (WSDL) based on XML provides such a standard format. The main components of web services as indicated in Chapter 3 are: 1. Service provider: Exposing of functionality as web service by service- provider application. 2. Service registry: Publishing of service description for service consum- ers to discover and consume. 3. Service consumer: Invoking of the web service by service consumer.9.1 TECHNOLOGIES FOR SERVICE ENABLEMENT 151 . Web serv is one of the implement tati ‘i standards supported by Web service ‘ation technologies for SOA. The open 'S are (McGovern et al., 2003): XML for data interchange; HTTP, FTP and SMTP for trai SOAP for messaging; WSDL for interface descri 5. UDDI for registry. insport; PeYPpr ption language; XML (eXtensible Markup Language) XML is text-based extensible markup language without fixed tags (unlike HTML where specific tags are used to specify presentation aspects). An XML document is always structured with tags defining the items that it holds and so XML parsers can be used to retrieve the data from it. Since an XML document is structured, a schema can be specified for it with the XML Schema Definition (XSD) language. XSD is used to specify rules that XML documents for a given purpose need to comply with, and thus, can be used to validate XML docu- ments to conform to the rules. In the case of a web service, data is exchanged as XML with XSD specifying the data contract for the data exchanged between the service provider and consumer. In order to remove ambiguity of tags used, XML namespaces are used in XML data. SOAP (Simple Object Access Protocol) During a web service call, an XML message with application data is wrapped ina SOAP envelope, that is, a header and trailer is added to the application data that describes the message structures passed. The SOAP envelope has a mandatory body section that describes the functions to be called and the parameters that are passed to the service and an optional header for additional processing informa- tion related to QoS and processing restrictions (Woods and Mattern, 2006). The service thus called strips the application data off the SOAP envelope. Figure 9-1 depicts pictorially the use of different technologies during a web service call. The data in service consumer application, say Java EE, is serial- ized as per the data contract of the service provider to XML on the service consumer side. The SOAP envelope and HTTP headers are then added and the data is transferred over HTTP. The service provider receives the HTTP data, removes the HTTP header and SOAP envelope, extracts the XML data and deserializes the data on the basis of the technology of service-provider application (e.g., Java EE). Security is an important concern for web services as XMLis essentially a text. There are two levels of security that may be applied to securing XML data exchanged: 1. wire-level security; 2. message-level security.152 * TECHNOLOGIES FOR SOA uted Suh uaa nOes Seralize pac eae (Based on Data PAREN ARIARAO Contract of Service eGR ers pea Rona Lc SNS HTTP Request Service Exposed) FIGURE 9-1 Technologies in a web service call. While the former may be achieved by enabling HTTPS at web server level, the latter requires a closer look. Message-level security involves security of data in SOAP messages. WS-Security provides a standard approach to encryption and use of digital sig- nature headers in SOAP messages. WS-Security is one of the several standards for web services security. Three of the other important standards are: 1. WS-Reliable Messaging for reliability of web services; 2. WS-AT for transaction support; 3. WS-Policy and WS-PolicyAttachment for policies of a web service (e.g., security, QoS, etc.). Web Services Definition Language (WSDL) Any description of a web service can involve two aspects — functional and nonfunctional. Functional description provides details of how the service isa TECHNOLOGIES FOR SERVICE ENABLEMENT ° 153 .,voked while the non-functional description describes wh ient ii ie service and who the service Provider i seiiey, a client anvokes ce on aspects such a: i i et al., 2004). On the other hand, th i rete yi Graham endpoint and using the communication Protocol specified as binding. WSDL is the description language for Specifying these details for web services. Accordingly, the WSDL has XML elements to describe the 1. Non-functional description * policy. 2. Functional description * abstract interface; * concrete implementation. The layout of a WSDL file is shown Pictorially in Figure 9-2. Most of the XML elements for non-functional description are tags related to the WS Policy. The functional description has two types of XML elements: 1, The abstract interface-related XML elements that include description of custom data types, messages and portTypes. 2. The concrete implementation-related XML elements that include XML tags for bindings to specify the communication protocol to be used and address specified using Uniform Resource Identifier (URI) of the endpoint. following: Table 9-1 lists key vendor-specific tools available for service enablement. ~ Abstract Interface \ Concrete Implementation | FIGURE 9-2 Layout of WSDL.154° TECHNOLOGIES FOR So, Platform and Relational Database Support for Web Services The enterprise application platforms and relational databases provide g nificant support to web services. This section provides details of web sery; enablement capabilities at platform and database level. JAX-WS for Java EE Platform ig. ice Web service development on Java EE platform is supported using a set of tech. nologies collectively referred to as Metro. The Metro stack consists of JAX-Ws, JAXB and WSIT technologies. JAX-WS stands for Java API for XML web services and was formerly known as JAX RPC. JAX-WS is built to make web service development easier than the earlier JAX RPC by providing a library of annotations; a toolkit of Ant tasks and comman¢-line utilities that hide the complexity of the underlying XML mes- sage protocol (Smart, 2006). As in the Microsoft WCF for the .NET platform, the developer uses annotations to define methods either in an interface or directly in an implementation class. The service consumer application creates a Proxy object and then invokes methods on this proxy. Neither the service-provider application nor the service-consumer application is required to generate or parse SOAP messages. The JAX-WS API takes care of this automatically. JAXB is an acronym for Java API for XML binding. It enables generation of Java classes from XML schemas with the help of a JAXB binding compiler or vice versa. XML schema may be provided as input to the JAXB binding com- piler to generate Java classes and interfaces that are based on the rules defined in the input XML schema. Alternatively, XML documer.ts may be created from Java classes with JAXB (Vohra, 2004). Java applications need to read, process and output XML data when dealing with web services and JAXB reduces the effort and complexity in doing so. Web Services Interoperability Technology (WSIT) provides interoperability between Java Web Services and Microsoft's Wndows Communication Foun- dation. It addresses security, reliable messaging and atomic transactions by implementing a number of WS-*specifications. From a functional perspective, the main features supported by WSIT are (SDN WSIT, 2007): bootstrapping communication (WS-MetaDataExchange); securing communication (WS-SecurityPolicy, WS-Security, WS-Trust); optimizing, communication (MTOM, WS-SecureConversation); enabling reliability (WS-ReliableMessaging); enabling atomic transactions (WS-Coordination, WS-AtomicTransactions). VP eye A Java web service written using JAX-WS for the LoanService example dis- cussed in Chapter 8 is shown in Figure 9-3. The LoauService can be deployed on an application server and the WSDL can be extracted by querying the service (http://?wsdl) as shown in Figures 9-4(a) and 9-4(b).a1 TECHNOLOGIES FOR SERVICE ENABLEMENT. © 155 | package com; import javax.jws.WebMethod; | import javax.jws. WebService; | @webService(serviceName="LoanServiceWSDL”, name="LoanSetvice”) | public class LoanService { | be @WebMethod() public boolean regislerUser(User user) { return true; } @WebMethod() public boolean loanRequest(Loan loan) { return true; public String loanStatus(Loan Instatusreq) { return null; | | 3 @WebMethod() > | J FIGURE 9-3 Java web service (LoanService) based on Java-WS. The initial portion of the abstract part of WSDL shows the namespace declarations followed by the data contract whose schema is described by the xsd file LoanServiceWSDL_schemal.xsd (not shown). This is followed by tags for messages and service contract. The concrete portion of the WSDL shows the bindings. It may be noted that the support for web services in both Java EE and .NET platform (to be discussed next) is substantial for most of the “plumbing” code for a web service is generated automatically. XML Web Services for NET Platform Web services are core to the philosophy of Microsoft .NET platform. Hence, there is significant support for web services on NET platform. There are mainly three ways by which web services may be exposed by .NET applications i Microsoft WCF: An example of exposing functionality as a web ser- vice using Microsoft WCF was provided in Chapter 8. Basic .NET platform capabilities. A .NET web service written using, .NET platform capabilities for the LoanService web service is shown in Figure 9-5, A development tool (¢.g., Microsoft Visual Studio) creates a service on compilation that can be deployed in the web server (e.g., IIS). The service can be queried for extracting the WSDL which would be similar to that shown in Figure 8-3. Web Service Software Factory: The Microsoft Patterns & Practices group has developed prescriptive guidance with a collection of tools, patterns and source code to build web services using proven156 * TECHNOLOGIES FOR so, |

| |

(a) FIGURE 9-4 (continued)9.1 TECHNOLOGIES FOR SERVICE ENABLEMENT :bindingtransport="http://schemas.. . [ Semation name="loanRequest”> S-xmlsoap.ora/soap/http” style="document">

157 (b) FIGURE 9-4 WSDL (a) abstract part; (b) concrete part. architecture and design patterns. It also addresses several challenges related to building ASP.NET (ASMX) and WCF web services such as exception handling and security (Microsoft, 2006). Service Enablement of Relational Databases The extensive adoption of web services has incentivized key database technol- ogy providers to develop features that allow web services to be exposed at database level.158 * TECHNOLOGIES F ORs, [using system; using System.Web; using System.Web.Services; using System.Web.Services. Protocols; using DataLayer; using MessageDefinitions; [WebService(Namespace = “http://tempuri.org/”)] public class LoanService : System.Web.Services. WebService { public LoanService () { } [WebMethod} public RegistrationResponse RegisterUser(RegistrationRequest Regreq) { hes } [WebMethod] public LoanResponse LoanRequest(LoanRequest Lnreq) # Mes Mi [WebMethod] public LoanStatusResponse LoanStatus(LoanStatusRequest Lnstatusreq) FIGURE9-5 .NET web service. Service Broker Feature of Microsoft SQL Server: T-SQL stored procedures may be created at database level and exposed as web services by the use of the service broker feature of Microsoft SQL Server. The steps involved in exposing stored procedures as web service are as follows (Joshi, 2008): 1. Create a stored procedure to expose the functionality as a service. 2. Create an HTTP endpoint for the stored procedure. An HTTP endpoint is an interface using which the service consumers can access the web service. r 3. Create a proxy for the web service (by “Adding Reference” using a tool such as Visual Studio). 4. Invoke the method of the web service. Web Service Feature for Oracle Database Server: PL/SQL, Java stored proce- dures, pre-defined SQL queries, DML, and Oracle Advanced Queuing pro cesses in Oracle database may be exposed as web services. The following are the steps to expose web services using the capabilities of Oracle databaseINOLOGIES FOR SERVICE I 92 TECH INTEGRATION = 159 (Mensah, 2005). JDeveloper automates thes € steps with a wi i wat from user: Ps izard using the te a stored ed 1 Cres te aston procedure/SQL query/DML/AQ Process to be exposed as a 2, Generate a Java proxy for the stored TOK i 3, Publish the Java proxy class as standard [ne er reas eatin, Application Server runtime (OC4J). 4, On invocation of a method of the web servi i the corresponding operation in the database. i Oe eee tionality exposed as a service is then executed in the database and the result set is sent back to the service consumer, Stored Procedure Web Service Feature cedures and SQL queries for IBM datal The following are the steps to expose as web services that IBM RAD (or WS, the inputs from user (Xu, 2006): for IBM DB2 UDB: Java Stored pro- base may be exposed as web services. Java stored Procedures or SQL queries AD tool) automates with a wizard using 1, Create a Java stored procedure or S Service. 2. Generate a Document Access Definition Extension (DADX) group and DADX file for the Java Stored Procedure or query. 3. Create a web service for the generated DADX file. 4, When the web service is invoked the corresponding Java Stored Proce- dure or SQL query is executed. ‘QL query to be exposed as a Web 92 TECHNOLOGIES FOR INTEGRATION _ While service consumers can directly invoke services based on the WSDL pro- vided by the service providers; this approach results in several issues in an enterprise context: 1, It becomes necessary for a service consumer to use the same protocol (e.g., web services) as that of a service provider. In many cases, the ser- vice consumers and service providers may be designed independently to work on different protocols (such as JMS or .NET Remoting). 2. The message format used by the service consumer for service invo- cation may be. different from the format required by the service provider. . 3. A large number of service providers and consumers may result in increased complexity due to several point-to-point connections caused on account of direct invocations between service providers and consumers. To address the above issues, it becomes necessary for the existence ofa mediator to not only integrate the service providers and service consumersTECHNOLOGIES Fo 160 + R04 such that the point-to-point connections are avoided but also to Perform transformation, routing and event handling. The are ectute Pattern thar addresses this requirement is the Enterprise Service Bus (ESB). Different vendors have provided their own implementations for ESB, Products that support the concept of ESB are available from: 1. application server providers; 2. middleware vendors; 3. ERP providers; 4. open source. Table 9-2 lists some of the key vendor-specific tools/ products available today for ESB. Many of the ESB products listed in Table 9-2 come with features and capa- bilities over and above what is required in an ESB. Visual tools are Provided that allow configuration of service providers and service consumers with ESB. TABLE 9-2 ESB tools/products Tools/Products Enterprise Vendor Website Reference > Service Bus Vendors Products IBM WebSphere _ http://www-01.ibm.com/common/ ESB ssi/rep_ca/0/897 /ENUS207-230/ ENUS207230.PDF Message _http://www-306.ibm.com/ software/ Broker integration /wbimessagebroker/ index.html?S_TACT= 105AD02W&S_ CMP=campaign Microsoft BizTalk (+ http: //www.microsoft.com/| biztalk/ ESB Guidance solutions/soa/ ‘esb.ms from Micro- soft Patterns & Practices) Oracle Oracle Ser- http://www.oracle.com/ technologies/ vice Bus soa /service-bus.html BEA Aqualogic http: // www.bea.com/, framework. isp?CNT=index.htm&FP=/content/ prod- ucts /aqualogic/serv ice_bus/ Service Bus Apache Service Mix http:// Servicemix.apache.org/home.html (continued)92 TECHNOLOGIES FOR SERVICE INTEGRATION TABLE 9-2 (Continued ) Jools/Products Enterprise ° 161 Vendor Website Reference a Service Bus Vendors Products J Cape Clear Cape Clear http:// www.capeclear.com/solutions/ Software ESB itshtm] Fiorano Fiorano Busi- http://www.fiorano.com ness Integra- tion Suite Fuse Source FUSE ESB _http://fusesource.com/ products/ (based on _ enterprise-servicemix/ ServiceMix) Mulesoft Mule ESB _http://www.mulesoft.org/display/ MULE/Home RedHat JBoss Enter- _http://www,jboss.org /jbossesb/ prise SOA Platform, which includes JBoss ESB Software AG webMethods Sonic Software Progress Sonic ESB Tibco Active Matrix Service Bus Vitria Business Accelerator ESB WSO2 WSO2ESB http://www.softwareag.com/Corporate/ Images/SAG_wM_ESB_Platform_FS_ web_tcm16-34350.pdf http://www.sonicsoftware.com/ products/sonic_esb/index.ssp http: //www.tibco.com/software/ soa/activematrix_service_bus/default.jsp http: //www.vitria.com/Business_ Accelerator /esb.php http://wso2.com Service Integration with ESB In order to illustrate the use of ESB, the example of loan approval business Process involving process orchestration discussed in Chapter 8 is extended for service integration through BEA AquaLogic ESB.TECHNOLOGIES FOR go, A 162° Loan Proxy {Sen Semen) service (mm ) | 7 | i a OG L eae Acti ‘Apache Axi ‘Srocess aria OnTomeat FIGURE 9-6 Service integration with ESB. Scenario The Loan Service provides web methods invoked during orchestration of loan approval process and is implemented with Apache Axis on Tomcat server, The web methods invoked at various steps of process orchestration are made over the BEA Aqualogic Enterprise Service Bus. Thus, the ESB forms a glue for service integration as shown in Figure 9-6. Aproxy service (Loan Proxy) is registered in AquaLogic for the Loan Service developed with Apache Axis and deployed on Tomcat server. The following invoke activities (shown in Figure 8-10) of loan approval business orchestrated in ActiveBPEL call Loan Proxy service: InvokeLogLoan (step 3); InvokeNotifyLoanOfficer (step 5); InvokeNotifyCustomer (steps 12, 18, 34); InvokeNotifyManager (step 24); InvokeLoanApproval (steps 16, 22); InvokeLoanRejection (steps 10, 29); InvokeLoanConfirmation (step 32). Nou eeye The BEA AquaLogic is configured to route calls to Loan Proxy service to the corresponding methods of Loan Service on Tomcat server. Configuration of BEA AquaLogic ESB AquaLogic configuration involves the following steps: 1. Login into AquaLogic Admin Console. 2. Enter into editing mode by clicking on Create in the Change center panel. 3. Create a WSDL resource using the Loan Service WSDL file. This step Tegis- ters the Loan Service WSDL (which is provided by Apache Axis on Tomcat server) as the WSDL resource. The key portions of the Loan Service WSDL are shown in Figure 9-7. Note that all the resources can be created using the Create resource drop down box available on the right panel. 4. Create a business service using the WSDL resource.92 TECHNOLOGIES FOR SERVICE INTEGRATION + 163 {coxml version="1.0" encoding="UTF-8"7> ewsdl:definitions: > “"notifyRequest"/> Me="notifyResponse"/> “loanNo fixedRate duration | ‘rejectLoanRequest"/> ‘rejectLoanResponse"/ | Instagram

Facebook Facebook

Pinterest Pinterest