Building Service Oriented Architectures

1. Building Service Oriented Architectures ColdFusion and Web Services Robi Sen department 13

2. Agenda • What are Web Services • How you can create and consume Web Services in ColdFusion • What are Service Oriented Architectures • Why are they important • How to create them Robi Sen department 13

3. What is a Web Service • W3C • Definition: A Web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols Robi Sen department 13

4. My Definition • Encapsulated, loosely coupled, contracted functions offered via standard protocols Robi Sen department 13

5. Three Major Things • Discovery/Description - WSDL • Publish - UDDI • Bind – WSDL and SOAP Robi Sen department 13

6. Why WS/SOA’s • Frankly it’s the best application architecture approach for large and distributed architectures. • More flexibility and more generic • Interoperability is predefined and key which leads to greater ROI, longer life cycles, greater usability • Makes more sense to “real people”  • Creates new opportunities for business, revenue, creativity, and over all usefulness Robi Sen department 13

7. Web Services Stack Evolution Robi Sen department 13

8. Buzz Word Stack Robi Sen department 13

9. SOAP <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAPSDK1:getTemperature xmlns:SOAPSDK1="capeconnect:AirportWeather:com.capeclear.weatherstation.Station"> <arg0>KDCA</arg0> </SOAPSDK1:getTemperature> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Robi Sen department 13

10. SOAP • Defines a unit of communication (header,envelope, body) • Defines error handling through Soap fault • Defines extensibility usually through custom headers • Defines mechanism for representing abstract data including binary data, arrays, and complex data • Defines RPC – common format for distributed computation • Defines Document- Centric approach to information exchange (i.e. B2B) Robi Sen department 13

11. SOAP- response <?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <cc1:getTemperatureResponse xmlns:cc1="capeconnect:AirportWeather:com.capeclear.weatherstation.Station"> <return xsi:type="xsd:string">The Temperature at null is null</return></cc1:getTemperatureResponse></SOAP-ENV:Body></SOAP-ENV:Envelope> Robi Sen department 13

12. Introducing Web Service and CF • CF through CFINVOKE makes working with Web Services as easy as CFQUERY made working with Relation Databases Robi Sen department 13

13. WSDL • http://www.w3.org/TR/wsdl • WSDL is an XML format for describing network services as a set of endpoints operating 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, however, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME. Robi Sen department 13

14. WSDL in layman's speak • Defines what a service does – methods and operations • How a service is accessed – details of data formats and protocols necessary to services operations • Where a service is located – details of the protocol-specific network address, such as a URI/URL Robi Sen department 13

15. WSDL in Specific • portType- abstract interface definition like a java interface definition • Message- Defines the set of parameters referred to by method sigs or operations • Types – Data type def’s • Binding – contains details on how abstract interface is converted to literal representation (I.e. SOAP over HTTP) • Port – specifies actual service node endpoint (I.e. your http url) • Service – bad name. Actual a series or list of ports which you can think of as a collection of web services that model a complex business process Robi Sen department 13

16. ColdFusion data type WSDL data type numeric SOAP-ENC:double boolean SOAP-ENC:boolean string SOAP-ENC:string array SOAP-ENC:Array binary xsd:base64Binary date xsd:dateTime guid SOAP-ENC:string uuid SOAP-ENC:string void (operation returns nothing) NA struct Map query QueryBean any complex type component definition complex type Data Mappings Robi Sen department 13

17. ColdFusion Components (CFC) <cfcomponent> <cffunction name="square" returnType="string" access="remote"> <cfargument name="num1" type="string"> <cfset sum = #arguments.num1#*#arguments.num1#> <cfreturn #sum#> </cffunction> </cfcomponent> Robi Sen department 13

18. Invocation <cfinvoke webservice = "URLtoWSDL" method = "operationName" inputParam1 = "val1" inputParam2 = "val2" ... returnVariable = "varName" > Robi Sen department 13

19. WSDL – what we care abouthttp://localhost:8500/xml/webservice/square.cfc?wsdl <wsdl:message name="squareResponse"> <wsdl:part name="return" type="SOAP-ENC:string" /> </wsdl:message> <wsdl:message name="squareRequest"> <wsdl:part name="num1" type="SOAP-ENC:string" /> </wsdl:message> Robi Sen department 13

20. Calling Square <cfinvoke webservice="http://localhost:8500/xml/webservice/square.cfc?wsdl" method="square" num1="5" returnVariable="var1"> </cfinvoke> <cfdump var="#var1#"> Robi Sen department 13

21. Same thing with CFSCRIPT <cfscript> ws = CreateObject("webservice", "http://localhost:8500/xml/webservice/square.cfc?wsdl"); resultVar = ws.getSquare(num1=“5"); writeoutput(var1); </cfscript> Robi Sen department 13

22. Consuming Web Services • Read the WSDL file • Get Parameters and figure data types • Use a invocation method Robi Sen department 13

23. CFC Metadata Robi Sen department 13

24. Show Metadata Robi Sen department 13

25. getProducts <cfcomponent> <cffunction name="getProducts" returnType="query" access="remote" output ="no"> <cfargument name="ProductName" type="string" required="true"> <cfquery name="prosearch" datasource="icf" dbtype="ODBC"> SELECT Product.ProductID, Product.ProductName, Product.ProductPricePerUnit, Product.VendorID FROM Product WHERE Product.ProductName LIKE '#arguments.ProductName#%' </cfquery> <cfreturn #prosearch#> </cffunction> </cfcomponent> Robi Sen department 13

26. Complex Data • http://localhost:8500/xml/webservice/productsearch.cfc?wsdl • CFC does not deal well with Queries and Structs <wsdl:message name="getProductsResponse"> <wsdl:part name="return" type="tns2:QueryBean" /> </wsdl:message> <wsdl:message name="getProductsRequest"> <wsdl:part name="ProductName" type="SOAP-ENC:string" /> </wsdl:message> Robi Sen department 13

27. Dealing with Complex Data • Minimize the use of ColdFusion complex types, such as query and struct, in the web services you create for publication. These types require consumers, especially those consuming the web service using a technology other than ColdFusion, to create special data structures to handle complex types. Robi Sen department 13

28. Complex Data <cfinvoke Webservice="http://localhost:8100/xml/webservice/productsearch.cfc?wsdl" method="getProducts" ProductName="ColdFusion" returnVariable="products"> </cfinvoke> <cfdump var="#products#"> Robi Sen department 13

29. PRO’s of CFC Web Service • Simple to deploy • Simple to consume • Based on industry standard/accepted AXIS Robi Sen department 13

30. CONS to CFC’s Web Service • Inability to customize headers • Issues with complex data • Only supports SOAP encoding style • Only Supports HTTP • No UDDI Robi Sen department 13

31. Alternatives • CFHTTP!! • CFOBJECT and MSXML • CFOBJECT and AXIS • CFX_API and AXIS • CFX,CFOBJECT, JSP SERVLET and other third party tools! Robi Sen department 13

32. How SOA’s relate to Web Services • service-oriented architectures are • loosely coupled pieces of application functionality • published • consumed • and combined with other applications over a network. • Web Services • stack of emerging standards • define protocols • create a loosely coupled framework for programmatic communication among disparate systems Robi Sen department 13

33. SOA’s • SOA’s are not so much a radical and disruptive technology paradigm shift like procedural to OO but a natural evolution of best practices. Robi Sen department 13

34. SOA • Loosely Coupled. Senders and receivers (producers and consumers) are abstractly decoupled from each other. Senders construct self-contained messages (including but not restricted to XML documents) and send them using a standards-based communication backbone without knowing the actual location of the receiver. The communication mechanism is responsible for the abstraction between the sender and the receiver. • Coarse Grained. Traditional object-based languages like Java expose their interfaces on a fine-grained, method basis. These fine-grained interfaces need to be aggregated into larger, coarse-grained services that closely resemble real business processes. Service technologies are designed to support the ability to assemble services into larger, more business suitable processes. • Asynchronous. Asynchronous communication is essential for distributed architectures. Senders and receivers cannot always depend on the availability of each other to do their work. Through a system of intermediaries, messages are exchanged in real-time with high performance. Yet, when receivers are unavailable, the messages can be persisted for later Robi Sen department 13

35. SOA • STANDARS BASED: The connections are based upon vendor-independent standards. The development of generally open and accepted standards is a key strength of the coalitions that have been building web services infrastructure. Most previous efforts at distributed computing (e.g., CORBA, DCOM, RMI, and others) were very difficult to implement, because they were dependent upon a particular vendor’s product offering, highly specified, or programmatically complex—usually all of the above. • PROCESS CENTRIC: Systems are conceived from a process-centric perspective. By intent, services are designed with a task-orientation; they function as discrete steps in a larger workflow or business process. A well designed service describes its inputs and outputs in a way that other software can determine what it does, how to invoke its functionality, and what result to expect in return. Robi Sen department 13

36. Why SOA’s • Frankly it’s the best application architecture approach for large and distributed architectures. • More flexibility and more generic • Interoperability is predefined and key which leads to greater ROI, longer life cycles, greater usability • Makes more sense to “real people”  • Creates new opportunities for business, revenue, creativity, and over all usefulness Robi Sen department 13

37. Distributed Process Robi Sen department 13

38. Break Down of Process Robi Sen department 13

39. SOA with CF • Define at a high level of a process and then service • Create a open interface via CFC to other components, templates, tags • You can use getMetaData() to create automated apps and easily discoverable services Robi Sen department 13

40. Change the way you think! • SOA’s require you stop thinking about units of functionality, components, technology but force you to focus on what's important! Figuring out what you need to do and how to model it! Robi Sen department 13

41. Implementations Today Re-Use and Syndication. Software re-use has always been a key part of component-based software models, but it rarely has been practical to implement. Web services may be different. Some early adopters envision syndicating existing software systems (e.g., an investment bank’s derivatives calculator or other complex algorithms) to partners and customers. Other re-use ideas include leveraging the standards-based interoperability to deliver data to a variety of formats and devices(e.g., web browsers, mobile devices, and interactive television). Automation and Productivity. Disparate systems still result in a remarkable amount of manual integration processes. As a result, web services’ interoperability promise to yield tremendous opportunities for productivity improvements through automation of business processes and employee productivity. Example projects might include exposing order status tracking and past purchase history to customers. Automation initiatives could yield results similar to the so-called “ATM Effect,” which has helped significantly simplify the cost structure and increase the profitability of retail banking. Robi Sen department 13

42. More Implementations Visibility into Operations. Businesses consistently seek to improve the accuracy of their inventory and revenue forecasts but are constrained by a lack of clear visibility into operating data. Web services based “digital dashboards” are one way adopters hope to address this challenge. Several specific categories of information that are hot-button issues include demand forecasting throughout the supply-chain, real-time cash flow and operating capital, and production and inventory availability.Bottom-line, better visibility will yield a dramatic impact on a company’s cost structure. Exploring New Business Models. Most companies evaluating web services today are focused squarely on efficiencies and tend to put new web services-based revenue opportunities into a“sometime in the future” bucket. A few early adopters are exploring new subscription or pay-peruse business models, however. Further down the road, companies may spin off non-strategic (but potentially valuable) web service competencies, just as many tangible assets were “unlocked” at an increased value as stand-alone entities over the past ten years. Robi Sen department 13

43. The Future • Support for new protocols • Greater interoperability • Support for complex data types • Support for emerging standards • Exposure of the engine • Orchestration Robi Sen department 13

44. Summary • Super easy to consume and deploy • Supports emerging standards • Has issues with complex data, different encoding, as well as protocols • You have lots of options • Web Services and SOA’s are moving targets and paradigms and we will see change and growth in this space for several years Robi Sen department 13

45. Resources • W3c.org • www.macromedia.com • Alphaworks.ibm.com • www.xml.com • www.webservices.org • www.xmethods.net • Uddi.org Robi Sen department 13