XML-Based Technologies in SOA: XML, Schema, SOAP, WSDL, BPEL

1. Eben Hewitt XML-Based Technologies in SOA:XML, Schema, SOAP, WSDL, BPEL

2. Presentation Goals Provide a quick introduction to the WS technologies used to do SOA XML, Schema, SOAP, WSDL, BPEL, and ESB Give users and participants head-start Foundation for next presentation

3. Service-Oriented Review Platform agnostic Not procedural or OO Business Documents Loose coupling Law of Demeter

4. XML

5. XML Overview eXtensible Markup Language Describes data Invent your own tags

6. Problem with Non-XML Data What is this? 19980704|20071110|hih05|3|28014|2|187 A purchase order? We can make good guesses

7. XML <invoice> <id>19980704</id> <date>20071110<date> <store>hih05</store> <terminal>3</terminal> <prod-code>28014</prod-code> <qty>2<qty> <total-amt>187<total-amt> </invoice> Self-describing Typed

8. Working with XML XML does nothing So you have to write software to process it But you can do so in any language That�s why XML is used in our SOA to represent business documents

9. Doing Stuff With XML Can store it as plain text in a Flat file SQL Database database as text or XML type Native XML database Can transmit it over HTTP or SOAP FTP

10. Common Uses Standard Enterprise Data Traverse the tree of nodes CRUD Transform it into another XML document new version vendor-specific Create new custom languages WML MathML

11. XML Document Requirements Declaration <?xml version="1.0" encoding=�UTF-8"?> Attributes must be quoted Must include �closing tag XML is case-sensitive Proper nesting. OK: <b><i>It�s bold and italic</i></b>

12. XML Constructs Elements: <tag>value</tag> Attributes: <tag attributeName=�value� /> Comments: <!-- my comment --> Documents are Trees

13. Use Attributes Sparingly attributes cannot contain multiple values child elements can attributes are not easily expandable consider future changes attributes cannot describe structures child elements can

14. Well-Formed and Valid Well-Formed �this XML document conforms to all syntax rules� Valid �this XML document is Valid AND conforms to a Schema�

15. Parsing XML SAX is event-based parsing Every time a tag, attribute, text, comment, whitespace or other XML item is encountered, a call-back is fired. Then your code can do something if it�s interested in that event Must implement certain interfaces DOM creates in-memory tree Not as fast as SAX, but makes sense when: You need random access to your document You need access to sibling elements Not appropriate for huge documents New StAX pull-parser Like SAX, but you ask for the events you�re interested in. Very fast Unlike SAX, can write

16. XPath and XQuery XPath Navigate the elements and attributes in the tree: /person/name/@title Not own file type, used within BPEL, Xquery, Java APIs Must know Xpath! XQuery To XML what SQL is to database tables Shares datatypes with Schema Advanced constructs: FLOWR="For, Let, Order by, Where, Return� Save in separate .xqy file Requires Implementation like Saxon-B

17. XML Schema

18. XML Schemas Describe the structure of XML documents! Written in XML themselves Support Reuse Do nothing on their own. Get a validating parser (later slide)

19. Schemas Also... Dictate data constraints Default values Fixed values (enums) Regular Expressions Order of elements Define datatypes Built-in Custom Support namespaces

20. Schema Example: Store.xsd <?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:dte="http://schemas.dte.com/dte/general" targetNamespace="http://schemas.dte.com/dte/general"> <annotation> <documentation xml:lang="en�>A standard DTC Store.</documentation> </annotation> <include schemaLocation="Address.xsd"/> <element name="store" type="dte:Store"/> <complexType name="Store"> <sequence> <element name="storeCode"> <simpleType> <restriction base="string"> <pattern value="[A-Z]{3}[A-Z_\s] \d{2}"/> </restriction> </simpleType> </element> <element name="address" type="dte:Address"/> </sequence> </complexType> </schema> Here XMLSchema is the default NS. So no qualifiers on Schema elements. Target NS is optional, but gives single NS to all elements in the doc. WS-I BP makes it required. Helps you distinguish between imported NSs. Best practice to always define targetNS Not cluttered, consistent. No clear-cut best practice. Show built-in type, include, element use, regex, custom type Root element is store, which contains a code and address. Here XMLSchema is the default NS. So no qualifiers on Schema elements. Target NS is optional, but gives single NS to all elements in the doc. WS-I BP makes it required. Helps you distinguish between imported NSs. Best practice to always define targetNS Not cluttered, consistent. No clear-cut best practice. Show built-in type, include, element use, regex, custom type Root element is store, which contains a code and address.

21. aStore.xml <?xml version="1.0" encoding="UTF-8"?> <dte:store xmlns:dte="http://schemas.dte.com/dte/general" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.dte.com/dte/general home/ehewitt/schemas/dte/general/Store.xsd"> <storeCode>AZP 23</storeCode> <address> <street>555 Some Street</street> <city>Phoenix</city> <state>AZ</state> <zip>86001</zip> </address> </dte:store> Note that Store.xsd reuses Address.xsd Show use of xsi to indicate physical path to included schema.Show use of xsi to indicate physical path to included schema.

22. The Importance of Built-in DataTypes Programs or locales can use data differently. When is 07-11-2007? The XML built-in data type "date" requires the format "YYYY-MM-DD". <date type="date">2007-07-11</date> Important datatypes include: String and Token Date and Time, Duration Signed and Unsigned Decimal, Integer, byte, short Boolean Binary data in hex and base64

23. Using XML on iSeries Built-in SAX Parser built into COBOL XML Toolkit for iSeries contains DOM and SAX parsers XMLPR400 for ILE COBOL See www.mowyourlawn.com and www.web400.com for easier wrappers XML Parser QSYS/QXML4PR310 See API spec in library/file/member:QSYSINC/QCBLLESRC/QXML4PR310 The linkage file to facilitate your COBOL application code is library/file/member: QSYSINC/QCBLLESRC/QXML4PRLNK For the COBOL ILE compiler, use the CL command Create COBOL Module (CRTCBLMOD. Use one of the following commands, specifying the parser service program on the bind: CRTPGM PGM(<your_library>/<your_program>) MODULE(<your_library>/<your_modules>) BNDSRVPGM(QSYS/QXML4PR310) See http://publib.boulder.ibm.com/iseries/v5r1/ic2924/index.htm?info/rzakl/rzakltools.htm

24. Schema Conclusion Schemas are very flexible, but very complex There are entire books written on schemas Schemas describe the valid structure of XML documents, which includes: SOAP documents WSDLs BPELs Our custom business objects We use Schemas to perform validation at runtime You must understand schemas!

25. SOAP

26. SOAP Simple Object Access Protocol Reuses HTTP Stateless Request-Response One way Or other bindings (SMTP, RMI, JMS) Transfer XML documents between disparate apps Requires SOAP implementation

27. SOAP Basic Unit: The Envelope <soap:envelope> Header directives meta-data Body required contains payload Attachments just like in email, usually for binary data Fault

28. SOAP Message <soapenv:Envelope xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:qs="http://ns.dte.com/dtc/quickscreen"> <soapenv:Body> <qs:cc1PreApproveApplication> <person> <name> <firstName>Eben</firstName> <middleInitial>M</middleInitial> <lastName>Hewitt</lastName> </name> <usAddress> <street>20225 N SCOTTSDALE</street> <street2>STE #305</street2> <city>SCOTTSDALE</city> <state>AZ</state> <postalCode>85255</postalCode> </usAddress> </person> <storeCode>RIP 22</storeCode> </qs:cc1PreApproveApplication> </soapenv:Body> </soapenv:Envelope>

29. SOAP Faults <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:m="http://www.example.org/timeouts" xmlns:xml="http://www.w3.org/XML/1998/namespace"> <env:Body> <env:Fault> <env:Code> <env:Value>env:Sender</env:Value> <env:Subcode> <env:Value>m:MessageTimeout</env:Value> </env:Subcode> </env:Code> <env:Reason> <env:Text xml:lang="en">Sender Timeout</env:Text> </env:Reason> <env:Detail> <m:MaxTime>P5M</m:MaxTime> </env:Detail> </env:Fault> </env:Body> </env:Envelope>

30. Using SOAP Requires a host language API Java using GlassFish, WebLogic On mainframes IBM has SupportPac for CICS On iSeries COBOL, use Java wrappers and WebSphere Next presentation...

31. WSDL 2.0

32. WSDL 2.0 Stands for Web Services Description Language Written in XML WSDLs define the interface or contract of a Web Service Contract=What must be done, not how it must be done. Because no implementation is given, the client and the service can be written in any language. (Client in Python, Service in .NET, Client in COBOL, Service in Java, etc) Like an interface or an abstract class Tells you only what the service�s API is

33. Using WSDL A client program connecting to a web service can read the WSDL to determine what functions are available on the server. Any custom datatypes used ("DTC Store") are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to invoke one of the functions listed in the WSDL. That process can be automated with tools.

34. WSDL Document Overview

35. WSDL Elements (3 of 5) <types> Describes all data types used by the web service, defined as Schemas (default). When a WSDL file specifies a targetNamespace of 'X', all the things defined within that WSDL file are considered defined under the namespace 'X'. Not necessary if you only use built-in data types (string, integer, boolean, etc) <message> Defines the SOAP messages exchanged in using this Web Service. Each is a one-way SOAP message, either a request or response. Child element is <part>. <portType> Defines the operations performed by the web service. Like a class with a collection of methods. Combines multiple <message> elements.

36. WSDL Elements cont. <service> What is the actual address (URL) of the service? Points to a <portType>. Nothing at that URL if you merely pull it up in a browser. You can specify multiple <service> types for the same binding (ie, for a mirror). <binding> How will the physical transportation of the messages occur? What protocol details do we need to know? transport="http://schemas.xmlsoap.org/soap/http" means "use SOAP over HTTP"

37. WSDL SOAP Binding <binding name="CustomerManagementPortBinding" type="tns:CustomerManagement"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <operation name="lookupCustomer"> <soap:operation soapAction="" /> <input><soap:body use="literal" /></input> <output><soap:body use="literal" /></output> </operation> </binding> How many namespaces are going on here? Why are some names NS-qualified? Is the �output� required?

38. WSDL RPC and Document RPC The SOAP request will include a wrapper XML element indicating the function name. The name of the element taken from the operation name attribute and the namespace taken from the operation namespace attribute. Document Request and response messages will consist simply of XML documents, which is flatter. Client should use pass-through documents defined with XML schemas rather than RPC calling conventions. The message is placed directly into the body portion of the SOAP envelope, either as-is or encoded.

39. Debate: RPC vs Document Style Document Style Allows full use of XML, described in an open format that is human readable, self-describing, and self-validating. does not require a rigid contract RPC Style requires that the structure of the SOAP request body contain both the operation name and the set of method parameters. Use document style for: asynchronous processing maintaining application state publishing services for outside partners easier validation and use of complex documents minimize in-memory processing (can choose DOM/SAX/StAX) We use �document�

40. Encoding Use Models : Literal or Encoded Dictates how to translate a WSDL binding to a SOAP message Literal The body contents should conform to a user-defined XML Schema structure. Advantages: you can validate the message body with the user-defined XML Schema you can transform the message using a transformation language like XSLT. Encoded The message has to use Schema datatypes, BUT the message structure need not conform to any user-defined XML schema. This makes it difficult to validate the message body or use XSLT based transformations on the message body. We use �literal�.

41. BPEL

42. BPEL 2.0 Overview Business Process Execution Language Standard that defines State Transitions Executable XML-based language for Business Process Modeling Requires a BPEL Engine to execute Allows "orchestration" of Web Services via WSDL <portType>s

43. Orchestration Individual Services are built to last a long time. Orchestrations composed of services are built for change. This is where you get agility. Just like WSDL defines the contract for a Web Service, BPEL defines the contract for service compositions.

44. Three BPEL Constructs Programming logic - BPEL Data types - XSD Input/Output (I/O) - WSDL The BPEL is responsible for invoking services as defined here

45. Using Compositions Four Individual Services CreateEmployee (HR) CreateAccount (Payroll) CreateEmailAccount ProvisionWorkstation One Service Composition NewHire CreateEmployee (HR) CreateAccount (Payroll) CreateEmailAccount ProvisionWorkstation

46. BPEL <Process>

47. Partner Links <partnerLinks> <partnerLink name="EmailEsb� partnerLinkType=�emesb:EmailPL� myRole="EmailEsbPortTypeRole"/> <partnerLink name="EmailPartner� partnerLinkType="ns1:EmailLink" partnerRole="EmailRole"/> </partnerLinks> All services are �Partners� �EmailEsb� uses �myRole� because that�s what the BPEL�s own clients invoke in the ESB �EmailPartner� uses �partnerRole� because that represents the invocation of the service The ESB is acting as the service

48. BPEL <sequence> <sequence> <receive name="ReceiveEmail" createInstance="yes" partnerLink="EmailEsb� operation="EmailOperation� portType=�emesb:EmailPortType� variable="EmailOpIn"/> <assign name="Assign1"> <copy> <from variable="EmailOpIn� part="emailMsg"/> <to variable="SendMe" part="emailMsg�/> </copy> </assign> <invoke name="InvokeEmailSendingService" partnerLink="EmailPartner" operation="sendEmail" portType="emailws:Email" inputVariable="SendMe� /> </sequence>

49. BPEL Design View

50. What Can You Do in BPEL? Invoke Services Variables Create local variables XML and WSDL typed variables Access with XPath Transform with XSLT Structured Programming Constructs If-then-elseif-else while, forEach Life Cycle sequences, processes repeatUntil Fault handlers Bindings for Given Protocol HTTP: External support for SOAP over HTTP File: Transport service to a file system FTP JMS

51. Next Presentation SOA III: Working with Web Services Technologies in Java ESB JAX WS 2.0 SOAP APIs including SAAJ, JAXB Ant tools GlassFish v2 Common Dispatcher and client libraries ESB

52. Questions Thank you!