3.4 Enabling Technology
3.4.1 XMLeXtensible Markup Language (XML) is a tag language, derived from the Standard Generalized Markup Language (SGML) and endorsed by W3C, to describe business data in human-eligible format and is intended to facilitate machine-to-machine or system-to-system communication over the Internet. The XML data construct can be defined and validated (with XML parsers) by either:
Referencehttp://www.w3c.org/TR/2000/REC-xml-20001006 Components of an XML DocumentFigure 3-9 shows a Foreign Exchange Option trade sold by ABC Buyer Bank with a trade date Jan. 15, 2002. It illustrates the three key components of an XML document (based on FX trading XML standard fpML): Prolog, Body, and Epilog. Figure 3-9 Sample XML Document<?XML version="1.0" " encoding = "UTF-8"?> <!DOCTYPE trade PUBLIC "-//FpML//DTD 3-0//EN" "" > [ <!- DTD declarations omitted -> ]> <trade> <tradeHeader> <partyTradeIdentifier> <partyReference href="#XYZ"/> </partyTradeIdentifier> <partyTradeIdentifier> <partyReference href="#ABC"/> </partyTradeIdentifier> <tradeDate>2002-01-15</tradeDate> </tradeHeader> <fxSimpleOption> <productType>Nondeliverable Option</productType> <buyerPartyReference href="#XYZ"/> <sellerPartyReference href="#ABC"/> <expiryDateTime> <expiryDate>2002-04-09</expiryDate> <hourMinuteTime>1000</hourMinuteTime> <businessCenter>USNY</businessCenter> </expiryDateTime> <exerciseStyle>European</exerciseStyle> </fxSimpleOption> <party id = "XYZ"> <partyId>CHASUS33</partyId> <partyName>XYZ BUYER BANK</partyName> </party> <party id = "ABCN"> <partyId>ABCANL2A</partyId> <partyName>ABC Seller Bank</partyName> </party> </trade> <!- end of DTDs -> Document Type Definitions (DTDs)DTDs specify rules about the tag names , data structure (for example, string), and permissible elements (for example, repeatable elements). DTDs can be stand-alone or incorporated in an XML document. DTDs include:
DTDs came from SGML and the text/documentation-processing scenario. Today, XML applications have expanded into business applications, and DTDs are fairly limited in providing a data-typing mechanism. For example, DTDs cannot tell us if the data type is an integer or a range of values. This data-typing requirement is particularly important in data validation for business transactions. Hence, W3C has come up with a newer standard to address these issues in "XML Schema" (refer to the next section). When to UseIt is recommended to exchange DTDs with trading partners before exchanging XML documents (if the DTDs are relatively static). Besides, developers are recommended to include DTDs to validate the syntax of the XML document, particularly when there are different versions. OutlookDTDs are not easily readable. XML Schema is widely used in XML Web Services due to its flexibility. W3C declares that XML Schema will be used in lieu of DTDs. Example ”DTD<!ELEMENT partyTradeIdentifier (partyReference)> <!ELEMENT partyReference EMPTY> <!ATTLIST partyReference href CDATA #REQUIRED > XML NamespaceThe XML Namespace is a collection/ group of names ”aka prefix added to XML element to differentiate elements with the same name (such as name, customer:name, or buyer: name ). Using a unique element, this addresses conflicting names while exchanging XML documents with partners. It is identified by a URI reference, qualified names/elements, and attribute names within an XML document (such as buyer:tradeHeader). The syntax is:
What Is Not an XML Namespace
Example ”XML Namespace<trade xmlns:buyer="urn:fpML:www.nextfrontiers.com/fxOptions"> <buyer:tradeHeader> <buyer:partyTradeIdentifier /> ... </buyer:tradeHeader> </trade> XML SchemaAn XML Schema is a more general and flexible way to describe the data structure of an XML document (for example, data type or attributes). Although not required, SOAP uses XML Schema instead of DTD to represent data in the SOAP requests and responses. SOAP can use XML Schema to serialize/ deserialize data from parameters to method calls and returned values. The syntax is as follows : Element <xsd:element name="xxx" /> Simple Types <simpleElement attribute1="name" attribute2="address" /> Complex Types <xsd:complexType name = "Address"> <xsd:sequence> <xsd:element name="address1"> <xsd:element names="city"> </xsd:sequence> </xsd:complexType> Attribute Declaration <attribute name = "USA" use="required" /> Example ”XML Schema<?xml version = "1.0" encoding = "UTF-8" ?> <!-- This XML schema definition conforms to W3C http://www.w3.org/2001/XMLSchema > <xsd:schema xmlns:xsd = "http://www.w3.org/2001/XMLSchema" targetNamespace = "" xmlns:tc = "" > <xsd:annotation> <xsd:documentation> This schema example illustrates a FX option. XYZ bought a FX option from ABC dated Jan 15 2002. </xsd:documentation> </xsd:annotation> <xsd:element name = "trade"> <xsd:complexType> <xsd:sequence> <xsd:element ref = "tradeHeader" minOccurs = "0" maxOccurs = "unbounded" /> <xsd:element ref = "fxSimpleOption" minOccurs = "1" maxOccurs = "1" /> <xsd:element ref = "party" minOccurs = "2" maxOccurs = "unbounded" /> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name = "tradeHeader"> <xsd:complexType> <xsd:sequence> <xsd:element ref = "partyTradeIdentifier" minOccurs = "0" maxOccurs = "unbounded" /> <xsd:element ref = "tradeDate" type = "xsd:date" /> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name = "partyTradeIdentifier"> <xsd:complexType> <xsd:sequence> <xsd:element ref = "partyReference" minOccurs = "1" maxOccurs = "unbounded" /> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name = "partyReference"> <xsd:complexType> <xsd:attribute name = "href" type = "xsd:string" /> </xsd:complexType> </xsd:element> <xsd:element name = "fxSimpleOption"> <xsd:complexType> <xsd:sequence> <xsd:element ref = "productType" minOccurs = "1" maxOccurs = "unbounded" /> <xsd:element ref = "buyerPartyReference" minOccurs = "0" maxOccurs = "1" /> <xsd:element ref = "sellerPartyReference" minOccurs = "0" maxOccurs = "1" /> <xsd:element ref = "expiryDateTime" minOccurs = "1" maxOccurs = "1" /> <xsd:element ref = "exerciseStyle" minOccurs = "1" maxOccurs = "1" /> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name = "expiryDateTime"> <xsd:complexType> <xsd:sequence> <xsd:element ref = "expiryDate" minOccurs = "1" maxOccurs = "1" type ="xsd:date" /> <xsd:element ref = "hourMinuteTime" minOccurs = "1" maxOccurs = "1" type = "xsd:int" /> <xsd:element ref = "businessCenter" minOccurs = "0" maxOccurs = "1" type ="xsd:string" /> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name = "party"> <xsd:complexType> <xsd:attribute name = "id" type = "xsd:string" /> <xsd:sequence> <xsd:element ref = "partyID" minOccurs = "1" maxOccurs = "1" type ="xsd:string" /> <xsd:element ref = "partyName" minOccurs = "1" maxOccurs = "1" type = "xsd:string" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> XML ParsersXML documents are usually validated by XML parsers for their well- formedness . There are three major types of parsers:
When to Use XML Parsers
Some XML Parser Implementations
What XML Can Do
What XML Is Not Good At
3.4.2 Java and Java APIWhy Java ?Java is platform independent. It has a "sandbox" architecture that has inherent application security. Besides, it is easier to write. On the enterprise level, Java 2 Enterprise Edition (J2EE) is the building block for components and integration points. Both Java and .NET have similar programming strengths. Java is more popular with cross-platform deployment consideration, yet .NET is also now available on Linux. What Is JAX Pack?The Java XML Pack (JAX Pack) is an all-in-one download of Java technologies for XML. Java XML Pack brings together several of the key industry standards for XML ”such as SAX, DOM, XSLT, SOAP, UDDI, ebXML, and WSDL ”into one convenient download, thereby giving developers the technologies needed to get started with Web applications and services. JAX Pack is a bag of Java-based APIs for developing and managing XML, SOAP, and UDDI:
JAX Pack ( http://java.sun.com/xml/downloads/javaxmlpack.html ) is a reference implementation for JAX, and is now part of Sun's Java Web Services Developer Pack ( http://java.sun.com/ webservices /webservicespack.html ). JAXPJAXP ( http://java.sun.com/xml/jaxp/index.html ) is a lightweight Java API library for parsing and transforming XML documents. It is a high-level wrapper for different parsers; it can use Xerces or Crimson as the underlying parser. It allows parsing of an XML document using:
Figure 3-10 depicts the components of JAXP. JAXP provides an interface layer to XML parsers. The reference parser is Apache Crimon, but developers can use other parsers such as Apache Xerces. The reference parser supports both event-driven (SAX) and tree-based XML parsing (DOM). Figure 3-10. JAXP Architecture SAXSAX performs well-formedness validation of XML documents. It can be used for reading specific elements. SAX is based on a specific event and enables sequential read access only (that is, one-time access). The strength of SAX is that documents do not have to be entirely in memory, thus it is fast and efficient. However, it cannot modify elements of the XML document. Figure 3-11 depicts the SAX parser architecture. To parse an XML document, developers simply define a Java class that extends the DefaultHandler, which will create a new instance of SAXParserFactory. The SAXParserFactory provides handlers such as startElement, endElement, and characters to process different events during the parsing. Figure 3-11. SAX Architecture Example ”SAX Parser import java.io.*; import org.xml.sax.*; import org.xml.sax.helpers.DefaultHandler; import javax.xml.parsers.SAXParserFactory; import javax.xml.parsers.ParserConfigurationException; import javax.xml.parsers.SAXParser; public class saxParse extends DefaultHandler { public static void main(String argv[]) { if (argv.length != 1) { System.err.println("Usage: saxParse xml-file"); System.exit(1); } // create new instance of SAXParserFactory DefaultHandler handler = new saxParse(); SAXParserFactory factory = SAXParserFactory.newInstance(); try { out = new OutputStreamWriter(System.out, "UTF8"); // call SAX Parser SAXParser saxParser = factory.newSAXParser(); saxParser.parse(new File(argv[0]), handler); } catch (Throwable err) { err.printStackTrace(); } System.exit(0); } static private Writer out; public void startDocument() throws SAXException { display("<?xml version='1.0' encoding='UTF-8'?>"); nl(); } public void endDocument() throws SAXException { try { nl(); out.flush(); } catch (IOException ioExceptions) { throw new SAXException("I/O error", ioExceptions); } } public void startElement(String namespaceURI, String elementName, String qualifiedName, Attributes attributes) throws SAXException { String anyName = elementName; if ("".equals(anyName)) anyName = qualifiedName; display("<" + anyName); if (attributes != null) { for (int i = 0; i < attributes.getLength(); i++) { String aName = attributes.getLocalName(i); if ("".equals(aName)) aName = attributes.getQName(i); display(" "); display(aName + "=\"" + attributes.getValue(i) + "\""); } } display(">"); } public void endElement(String namespaceURI, String simpleName, String qualifiedName) throws SAXException { display("</" + simpleName + ">"); } public void characters(char buffer[], int offset, int len) throws SAXException { String something = new String(buffer, offset, len); display(something); } private void display(String something) throws SAXException { try { out.write(something); out.flush(); } catch (IOException err) { throw new SAXException("I/O error", err); } } private void nl() throws SAXException { String endOfLine = System.getProperty("line.separator"); try { out.write(endOfLine); } catch (IOException err) { throw new SAXException("I/O error", err); } } } DOMThe Document Object Model (DOM) is an API for processing XML documents. It defines the logical structure of documents and a way to access and manipulate it. The strengths of DOM are that DOM can build documents, navigate their structure while in memory, and DOM can add, modify, or delete elements or content of the XML document. However, the in-memory processing is resource-hungry. Figure 3-12 depicts the DOM architecture. To parse an XML document, developers need to define a Java class to create an instance of DocumentBuilderFactory, which will create a new object DocumentBuilder. The DocumentBuilder will then create nodes (objects in the DOM) for different XML elements and tags. Figure 3-12. DOM Architecture Example ”DOM Parser import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.FactoryConfigurationError; import javax.xml.parsers.ParserConfigurationException; import org.xml.sax.SAXException; import org.xml.sax.SAXParseException; import org.w3c.dom.Document; import org.w3c.dom.DOMException; public class DomParse{ static Document doc; public static void main(String argv[]) { // Command syntax if (argv.length != 1) { System.err.println("Usage: java DomParse xml-file"); System.exit(1); } import java.io.*; // Create new instance, and call DOM to parse DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); try { DocumentBuilder builder = factory.newDocumentBuilder(); doc = builder.parse(new File(argv[0])); // Standard exceptions handling } catch (SAXException saxException) { Exception somethingWrong = saxException; if (saxException.getException() != null) somethingWrong = saxException.getException(); somethingWrong.printStackTrace(); } catch (ParserConfigurationException parserError) { parserError.printStackTrace(); } catch (IOException ioExceptions) { ioExceptions.printStackTrace(); } } } JAXMJAXM ( http://java.sun.com/xml/jaxm/index.html ) refers to the Java technology support for sending and receiving SOAP messages, which is based on the SOAP 1.1 and the SOAP with Attachment specifications. It supports higher level and application-specific protocols built on top of SOAP, including multiple transports such as HTTP, SMTP, and so forth. Besides, it supports both synchronous (request “reply) and asynchronous (one-way) mode. JAXM is preferable to JAX-RPC because of its support for asynchronous messaging, multiparty message routing, and reliable messaging (that is, guaranteed delivery). Figure 3-13 depicts the JAXM architecture. JAXM is a pluggable provider class for the SOAP server. The provider class supports different data transports, such as HTTP, SMTP, and JMS. If Company X sends a SOAP message using a SOAP provider over HTTP to Company Y, the JAXM provider will create a connection to the specified URL end-point with Company A's SOAP provider, create a SOAP message instance, and get the SOAP envelope and body. With JAXM, developers can make SOAP messaging reliable with message acknowledgement and guaranteed message delivery using JMS. Figure 3-13. JAXM Architecture Example ”Sending an FX Option Message Via JAXM [View full width]
RemarksDue to some changes in the Java Specification Request 067, SOAP messaging is now supported by both SAAJ (SOAP with Attachments APIs for Java) and JAXM. The package javax.xml.soap was removed from JAXM to become SAAJ. Currently, JAXM APIs do not implement the full functionality of the ebXML Message Service. However, current JAXM reference implementations provide an additional class EbXMLMessageImpl to support ebXML Message Service. There are several vendor products such as Sun, TIBCO, and Sybase that are ebXML Message Service-compliant (refer to the vendor list at http://www.ebusinessready.org/ebxmlms_3Q02UCCFinalReport.pdf ). JAXBJAXB ( http://java.sun.com/xml/jaxb/index.html ) denotes Java Architecture for XML Binding. JAXB creates an XML-to-Java binding schema (XJS), which maps XML elements to Java objects, and stores it in XJS files (.xjs extension). You can compile them with a schema compiler called xjc and output the source code to a set of Java classes for marshalling and unmarshalling. What is an XML-to-Schema Compiler (xjc)? It is a Unix shell script that invokes com.sun.tools.xjc.Main, which reads in a DTD and a XJS binding schema, and generates a set of Java source files. An XJS binding schema file defines the mapping, for example: <?xml version="1.0" encoding="ISO-8859-1" ?> <xml-java-binding-schema version="1.0-ea"> <element name="tradeDate" type="class" root="true"/> ... </xml-java-binding-schema> Figure 3-14 depicts the JAXB architecture. The utility xjc creates Java source files to bind a DTD or XML Schema to Java data objects. Developers can then add additional program code if necessary and compile the Java source files into Java classes for execution. This can potentially reduce some coding effort and processing time to transcode XML elements in an XML document using JAXP. Figure 3-14. JAXB Architecture Example ”Sample Screen Output for xjc CompilerAssuming there are a DTD "checkbook.dtd" and an XJS " checkbook .xjs" and all relevant jar files are placed under D:\Dev\WSPack\Common\Lib, executing the xjc compiler (com.sun.tools.xjc.Main) will render several Java source files in the following output (Figure 3-15): Figure 3-15 Sample xjc Output [View full width] D:\Dev\Test\xjc>xjc checkbook.dtd checkbook.xjs D:\Dev\Test\xjc>java -classpath d:\dev\wspack\common\lib\jaxb-xjc-1.0-ea.jar;d:\dev\wspack\common\lib\jaxb-rt-1.0-ea.jar JAXB version 1.0 now supports both DTD and XML Schema. Developers can use the same xjc compiler to generate Java binding files for an XML Schema by using "-p <output package file name>" as a parameter, such as "xjc checkbook.xsd -p checkbook.xjs" under Windows or "$JAXB_HOME/bin/xjc.sh checkbook. xsd -p checkbook.xjs" under Unix. Please refer to the user documentation ( http://java.sun.com/xml/jaxb/users-guide/jaxb-using.html#about_manual ). Prior to version 1.0, early access versions of JAXB could only support DTD. Using JAXB to bind an XML Schema to the Java data structure, developers can probably write less program code using an XML parser (such as DOM or SAX) to transform XML content into Java data objects. This is a considerable benefit to the productivity. JAXRJAXR ( http://java.sun.com/xml/jaxr/index.html ) is a standard Java API for accessing diverse and heterogeneous Business Service Registries. It is a unified information model for describing business registry content. It provides multi-layered API abstractions for simple, high-level, business API, and flexible, low-level, generic API. It is the enabling technology for Web Services and peer-to-peer computing in the J2EE . Figure 3-16 depicts the JAXR architecture. A JAXR client is basically a registry client (RC) that is connected to the registry service (RS) via a JAXR pluggable provider. The JAXR provider is able to use any capability-specific interfaces such as ebXML provider or UDDI provider that is specific to a particular Service Registry platform. Developers can also write their own JAXR provider class to accommodate any new Service Registry platform. In this way, the JAXR client only needs to use one single set of program code to access different service registries; it need not be rewritten and recompiled. Figure 3-16. JAXR Architecture JAX-RPCJAX-RPC ( http://java.sun.com/xml/ jaxrpc /index.html ) stands for Java API for XML-based Remote Procedure Calls (RPC). It enables Java technology developers to build Web applications and Web Services incorporating XML-based RPC functionality according to the SOAP 1.1 specification. JAX-RPC allows distributed client/server mode over the Web using the Standard Web Services technologies: SOAP, WSDL, and HTTP. Using the JAX-RPC API and the tools, it simplifies the creation of a Web Service for a Java programmer as it hides all the complexities of generating SOAP and WSDL, but provides tools to generate these using Java Interfaces and some additional configuration information. All the code to map Java data type information to XML/SOAP is generated by the tools " wscompile " and " wsdeploy " from Java Web Services Developer Pack (JWSDP) 1.0.1 (which supersedes the tool " xrpcc " in JWSDP 1.0). The JAX-RPC runtime will take care of the transport. This is one of the key technologies in Web Services and will be incorporated into J2EE 1.4 and EJB 2.1. Server-Side Operations
Client-Side Operations
Figure 3-17 depicts the JAX-RPC architecture. In order to invoke a remote business service, the client program needs to install a "stub," which enables it to communicate with the remote application service via the remote "ties." Both the client and the remote server (services) need to install JAX-RPC runtime, which enables both ends to exchange SOAP messages. This is a typical Remote Procedure Call model. Figure 3-17. JAX-RPC Architecture 3.4.3 UDDIUniversal Description, Discovery, and Integration (UDDI) usually denotes a Service Registry like a business Yellow Page for an e-business service. It also denotes a standard specification for service discovery and description. There are at least three public operator nodes: Microsoft, IBM, and Ariba (said to be taken over by HP). SAP now provides a public UDDI node as well. The business challenges for implementing UDDI come from several areas:
Figure 3-18 depicts different roles and operations of the UDDI Service Registry. Figure 3-18. UDDI Roles and Operations Service Requester
Service Registry
Service Provider
The UDDI registry enables businesses/corporations to register public information about themselves (such as service type, products, URL) and provides service categories or classifications using standards code such as NAICS (North American Industry Classification System, a product code classification system for trading used by the U.S. Census Bureau) and UN/SPSC (United Nation Standard Products and Services Classification, a product classification system developed by Dun & Bradstreet). There are mainly three types of information: (1) White Pages ”business names, description, contact information; (2) Yellow Pages ”business categories using standard codes such as NAICS, UN/SPSC, and geographical taxonomy; and (3) Green Pages ”information model to store implementation information of business processes, service descriptions, and binding information. The UDDI information model is a data model that encapsulates the business information of business organizations and service details. Figure 3-19 depicts how these pages are mapped to the UDDI information model. Figure 3-19. Three Types of Information in UDDI Figure 3-20 further describes the relationship between UDDI entities and the WSDL document. In UDDI, a business entity contains the definition of business services (White Pages), and each business service contains a binding template (Yellow Pages) that shows the service end-points URL. The information in the binding template is also stored in the UDDI information model tModel and tModelInstance objects, which are accessed during the service discovery process. Figure 3-20. UDDI Entities and Relationship The same information in the binding template is also referenced in the Implementation section of the WSDL document (Green Pages). The Implementation section is also referenced in the Interface section of the WSDL document. If developers want to store the WSDL document in the UDDI Service Registry, they can reference the Interface section in the tModel object. IBM differentiates six types of UDDI:
Figure 3-21 shows some examples of UDDI implementation from IBM, Microsoft, and Sun. IBM and Microsoft have a public UDDI registry implementation for public testing. Sun has a free UDDI registry implementation for developer testing. Figure 3-21. Examples of UDDI Implementation 3.4.4 SOAPSOAP stands for Simple Object Access Protocol. The original specification has three parts : extensible envelope (headers and body), simple type marshalling schema, and HTTP RPC protocol. In SOAP 1.2, there are some small changes from SOAP 1.1:
Figures 3-22 and 3-23 depict the SOAP server components and how the client interacts with the server. Figure 3-22 elaborates on Figure 3-17 by expanding the logical components of the "stub" into the SOAP RPC layer. The SOAP RPC layer acts as a client proxy that initiates SOAP calls, creates SOAP envelope and message body, and exchanges with the SOAP server. The logical components of the " tier " are elaborated as the SOAP server. The SOAP server handles message routing, marshals, and unmarshals the SOAP messages via RPC router servlet and message router servlet (these are transport listeners). All SOAP messages are transported on top of HTTP or HTTPs, and can even be bound to JMS using customized pluggable providers. Figure 3-22. SOAP Server Components Figure 3-23. SOAP Client “server Interaction Figure 3-23 describes the process of how a SOAP client communicates with a SOAP server. The SOAP client sends a SOAP RPC request to the RPC router servlet. The RPC router servlet looks up the Deployment Descriptor from the service manager. Upon successful retrieval, the RPC router servlet locates the configuration details and passes the request to appropriate pluggable provider. For instance, the pluggable provider is an EJB provider, and it invokes the remote business service via RMI/IIOP protocol. 3.4.5 WSDLWeb Services Description Language (WSDL) V1.1 uses XML to describe Web Services by:
It also defines network accessible services functionality, such as protocol and deployment details. It is submitted to W3 as a basis for XMLP Web Service metadata definition ( http://www.w3.org/TR/wsdl .). Figure 3-24 shows the elements of a WSDL document. The service (service end-point URL), operation name (the remote business service), message name (input or output), and the type (data type) are usually of interest to developers, as they are the key information to build a Web Services client. Figure 3-24. WSDL Elements and Relationship WSDL documents can be stored in the UDDI registry. There is a close relationship between the UDDI information model and the WSDL documents. SOAP clients look up the UDDI registry for a specific business service and find the service key and the associated service end-points from the WSDL or the tModel. Then they can invoke the business service remotely. Figure 3-25 depicts the relationship between the WSDL document and the UDDI's tModel. In a WSDL document, the service name is mapped to the BusinessService attribute of a tModel, the port name to the BindingTemplate, and the service interface section to the tModel and tModelInstanceInfo attributes. Figure 3-25. WSDL and UDDI Relationship Example ”WSDL for FX Option<definitions name="fxOption" targetNamespace="http://nextfrontiers.com/fxOption.wsdl" xmlns:tns="http://nextfrontiers.com/fxOption.wsdl" xmlns:xsd1="http://nextfrontiers.com/fxOption.xsd" xmlns:soap="http://schemas.xmlsoap. org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/" > <types> <schema targetNamespace="http:// nextfrontiers.com/fxOption.xsd " xmlns="http://www.w3.org/1999/XMLSchema"> <element name="fxOptionPriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType> </element> <element name="fxOptionPrice"> <complexType> <all> <element name="price" type="float"/> </all> </complexType> </element> </schema> </types> <message name="GetLastfxOptionPriceInput"> <part name="body" element="xsd1:fxOptionPrice"/> </message> <message name="GetLastfxOptionPriceOutput"> <part name="body" element="xsd1:fxOptionPriceResult"/> </message> <portType name="fxOptionPortType"> <operation name="GetLastfxOptionPrice"> <input message="tns:GetLastfxOptionPriceInput"/> <output message="tns:GetLastfxOptionPriceOutput"/> </operation> </portType> <binding name="fxOptionSoapBinding" type="tns:fxOptionPortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GetLastfxOptionPrice"> <soap:operation soapAction="http://nextfrontiers.com/GetLastfxOptionPrice"/> <input> <soap:body use="literal" namespace="http://nextfrontiers.com/fxOption.xsd" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body use="literal" namespace="http://nextfrontiers.com/fxOption.xsd" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation> </binding> <service name="fxOptionService"> <documentation>Your low cost online FX option service</documentation> <port name="fxOptionPort" binding="tns:fxOptionBinding"> <soap:address location="http://nextfrontiers.com/fxOption"/> </port> </service> </definitions> 3.4.6 ebXMLElectronic Business XML Markup Language (ebXML) is an international initiative to define a framework for finding, exchanging, developing, and implementing business services. It focuses on B2B and Small Medium Enterprise needs, and is backed up by standards bodies (such as OASIS, UN CE/FACT) and communities (such as the Open Applications Group or OAG http://www.openapplications.org/downloads/whitepapers/frameworks.htm ). Figure 3-26 depicts the architecture components of ebXML. Two business applications want to exchange business documents in a reliable manner. Both ends need to establish a trading partner agreement (using CPP, CPA) prior to document exchange. The sender business application initiates a connection, sends the business documents in ebXML manifest (which is wrapped in a SOAP envelope using SOAP 1.1 with Attachment), and waits for message acknowledgement from the recipient business application. The ebXML architecture also allows business process collaboration using a business process specification shared between the business applications.
Figure 3-26. ebXML Architecture A typical ebXML message makes use of the SOAP messaging as the transport and routing protocol. Figure 3-27 shows the message structure and a sample message. An ebXML message consists of a payload (usually called Manifest), which is wrapped by a SOAP envelope (including a SOAP envelope and SOAP body). ebXML encapsulates the SOAP envelope and the payload under a MIME MIME structure, and thus allows capturing either text or binary objects (such as a picture, or an EDI message) in the payload. Figure 3-27. ebXML Envelope and Structure Example ”ebXML Message<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Header> <eb:MessageHeader xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" eb:version="1.0" soap-env:mustUnderstand="1"> <eb:From> <eb:PartyId eb:type="URI">http://www.nextfrontiers.com/remote/sender </eb:PartyId> </eb:From> <eb:To> <eb:PartyId eb:type="URI">http://www.nextfrontiers. com/remote/sender </eb:PartyId> </eb:To> <eb:CPAId>http://webservices.com/cpas/ourcpa.xml </eb:CPAId> <eb:ConversationId>20020509-242342-92343 </eb:ConversationId> <eb:Service eb:type="">fxOptionProcessing </eb:Service> <eb:Action>NewOrder </eb:Action> <eb:MessageId>7ac208cb-a1d4-6a71-9834-afb31c12ca32 </eb:MessageId> <eb:RefToMessageId>20020510-242324-92343@webservices.com </eb:RefToMessageId> <eb:Timestamp>1016592644013</eb:Timestamp> </eb:MessageData> </eb:MessageHeader> </soap-env:Header> <soap-env:Body> <eb:Manifest xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" eb:id="manifest" eb:version="1.0"> <eb:Reference eb:id="bar01" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="cid:bar01" xlink:role="http://regrep.org/gci/fxoption"> <eb:Schema eb:version="1.0" eb:location="http://regrep.org/gci/fxoption.xsd"/> </eb:Reference> </eb:Manifest> </soap-env:Body> </soap-env:Envelope> ImplicationebXML is not an XML message standard like finXML, though XML messaging is used. Unlike SOAP and UDDI, which were designed for B2C, ebXML evolved from standards bodies and is designed for B2B business services. It has unique added values by providing guaranteed message delivery (ebXML Messaging Service), security (for example, ebXML's dependency of digital certificates, encryption, and digital signature to meet different security requirements), business processes (ebXML Business Process), and Quality of Services for transaction processing (for example, ebXML CPP/CPA). This entails areas and applications for which architects may use ebXML Web Services only. http://www.ebxml.org/implementations/index.htm shows a list of existing ebXML implementations and case studies. The adoption of SOAP as the Transport and Routing Protocol (TRP) in March of 2001 marks the beginning of converging some common initiatives in the industry and reducing unnecessary competition between the two technologies. ebXML registry reference implementations are now available. ebXML registry also supports UDDI discovery. SOAP will evolve to cover more business-process and service-negotiation aspects as defined in the ebXML specification (for example, SOAP-JMS binding is one area that addresses the reliability of SOAP messaging across enterprises). The JAX Pack ( specifically , JAXM for messaging service and JAXR for accessing Service Registries) has made it possible to implement both SOAP and ebXML Web Services using a single platform and enabling tool, instead of silo technology. 3.4.7 UDDI and ebXML Service RegistriesCurrently, Service Registry has two variants: UDDI and ebXML. OASIS now supports both variants. UDDI Service Registry (Version 2.0 is in production, and Version 3.0 specification is publicly available) has been on the market for some time. IBM, Microsoft, HP (taking over from Ariba), and SAP manage the public UDDI Service Registry nodes. Although they are intended to be a public Service Registry, most people use them for testing instead. There are also a few open-source implementations of UDDI Service Registries, including UDDI registry from Sun's Java Web Services Developer Pack. Most J2EE Application Server vendors also provide UDDI Service Registry. Another variant is the ebXML Service Registry. This is a standards-based Service Registry. Its functionality is similar to UDDI. In addition, it supports service contracts (that is, CPA, CPP) and work-flow related entities (as per ebXML specifications). There is a reference implementation available at http://ebxmlrr. sourceforge .net/ . When to UseService Registry can be used in the following context:
Selecting the Appropriate Service RegistryWhen selecting a specific Service Registry implementation, there are a few differentiators to consider:
Comparing the UDDI and ebXML Service RegistriesAlthough these two variants of Service Registry provide similar functionality, there are considerable differences in what they provide. It is important to understand that these two Service Registries are not necessarily exclusive, as they have different value propositions for different business and technical requirements.
3.4.8 XML Web Services SecurityMost Web Services security has focused on SOAP message security. As the data contents in the SOAP message are decoupled from the data transport layer, the transport layer security is often overlooked. End-to-end Web Services security should support Authentication, Entitlement (authority and access control), Data and transaction integrity, Confidentiality, Auditing, and nonrepudiation. A broader view of the Web Services security covers:
Figure 3-28 illustrates different areas of Web Services security, and they need to be considered during the design and implementation as a complete picture. Most of the security standards today tend to address one specific area, and the challenge of the architect is to put them into the right context. The scope of Web Services security covers message security (for example, WS-Security protects SOAP messages), data transport security (for example, HTTPs and data encryption secure the data transport layer), and platform security (for example, Solaris platform security hardening and intrusion detection system protect the platform). These are valid security mechanisms to support data integrity, data privacy, nonrepudiation, and traceability requirements. End-to-end Web Services security should also ensure that the identity of both the Service Requester and that the Service Provider is valid and trustable (authentication and authorization requirements). It may involve the use of Public Key Infrastructure, XKMS, Liberty, and SAML. This is particularly important if there is a requirement to perform a cross-domain single sign-on across multiple service providers. There will be more details in Chapter 7, "Web Services Security." Figure 3-28. Broader Picture of Web Services Security Examples of emerging security standards for Web Services include:
ImplicationIndustry collaboration among vendors to agree on common XML security standards is close and healthy . Each XML security standard tends to focus on a particular problem area and specifies interaction and protocols between two entities ”-for example, SAML is designed to address the authentication request/reply between two servers, not from an enterprise/ cross-enterprise perspective. There is a general lack of "a broader picture" to implement all these XML standards for enterprise applications using XML Web Services. |
(childName2); childName2 = envelope.createName("href"); partyReference2.addAttribute(childName2, "#ABC"); // create fxSimpleOption Name childName3 = envelope. createName("fxSimpleOption"); SOAPElement fxSimpleOption = trade.addChildElement(childName3); childName3 = envelope.createName("productType"); SOAPElement productType = fxSimpleOption.addChildElement(childName3); productType.addTextNode("Nondeliveable options"); childName3 = envelope. createName("buyerPartyReference"); SOAPElement buyerPartyReference = fxSimpleOption.addChildElement(childName3); childName3 = envelope.createName("href"); buyerPartyReference.addAttribute(childName3, "#XYZ"); childName3 = envelope. createName("sellerPartyReference"); SOAPElement sellerPartyReference = fxSimpleOption.addChildElement(childName3); childName3 = envelope.createName("href"); sellerPartyReference. addAttribute(childName3, "#ABC"); childName3 = envelope. createName("expiryDateTime"); SOAPElement expiryDateTime = fxSimpleOption.addChildElement(childName3); childName3 = envelope. createName("expiryDate"); SOAPElement expiryDate = expiryDateTime. addChildElement(childName3); expiryDate.addTextNode("2002-04-09"); childName3 = envelope. createName("hourMinuteTime"); SOAPElement hourMinuteTime = expiryDateTime.addChildElement(childName3); hourMinuteTime.addTextNode("1000"); childName3 = envelope. createName("businessCenter"); SOAPElement businessCenter = expiryDateTime.addChildElement(childName3); businessCenter.addTextNode("USNY"); childName3 = envelope. createName("exerciseStyle"); SOAPElement exerciseStyle = fxSimpleOption.addChildElement(childName3); exerciseStyle.addTextNode("European"); // create party information Name childName4 = envelope. createName("party"); SOAPElement party = trade.addChildElement(childName4); childName4 = envelope.createName("id"); party.addAttribute(childName4, "XYZ"); childName4 = envelope. createName("partyId"); SOAPElement partyId = party. addChildElement(childName4); partyId.addTextNode("CHASUS33"); childName4 = envelope. createName("partyName"); SOAPElement partyName = party. addChildElement(childName4); partyName.addTextNode("XYZ BUYER BANK"); Name childName5 = envelope. createName("party"); SOAPElement party2 = trade. addChildElement(childName5); childName5 = envelope.createName("id"); party2.addAttribute(childName5, "ABCN"); childName5 = envelope. createName("partyId"); SOAPElement partyId2 = party2. addChildElement(childName5); partyId2.addTextNode("ABCANL2A"); childName5 = envelope. createName("partyName"); SOAPElement partyName2 = party2. addChildElement(childName5); partyName2.addTextNode("ABC Seller Bank"); } hotPotato.saveChanges(); System.err.println("Sending message to URL: "+ endpoint.getURL()); SOAPMessage reply = hookUp.call(hotPotato, endpoint); System.err.println("Sent message is logged in \"logfile.txt\""); FileOutputStream logFile = new FileOutputStream("logfile.txt"); hotPotato.writeTo(logFile); logFile.close(); System.out.println("Received reply from: "+endpoint); // Display reply message boolean displayResult=true; if(displayResult) { // Document source, do a transform. System.out.println("Result:"); TransformerFactory tFact=TransformerFactory.newInstance(); Transformer transformer = tFact.newTransformer(); Source src=reply.getSOAPPart().getContent(); StreamResult result=new StreamResult(System.out); transformer.transform(src, result); System.out.println(); } hookUp.close(); } catch(Throwable e) { e.printStackTrace(); } } } 
