Resource Tier Synchronous Integration

Another place where business processes and assets may require integration is directly at the Resource tier. This is sometimes overlooked, but it is equally important to application-level integration. In some cases it can be straightforwardparticularly if the Resource tiers of the applications are implanted using the same technologies, but in most it is generally a very complex but worthwhile integration. A successful Resource tier integration can lead to more harmonious applications that access these resources and thus ease integration and interoperability challenges at the application layer.

Chapter 6 looks at Resource tier synchronous integration, going into detail on the persistence layers that both .NET and Java EE offer as well as providing lots of hands-on experience in dealing with these to implement Resource tier access and integration for the Supply Chain Management scenario.

In addition to this, the chapter outlines methodologies for accessing non-database resources such as Enterprise Resource Planning (ERP) and other Enterprise Information System (EIS) entities.

Reference

[JIBJAB] Alexa Traffic Monitor for jibjab.com www. alexa .com/data/details/traffic_details?q=&url=http://www.jibjab.com

Chapter 4. Web Services for Synchronous Integration

Web Services Technology Overview

There are a number of ways to describe Web services, but for the purpose of using a standard definition this book uses the W3C definition of a Web service:

A Web service is 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, discussed later). 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 conjunction with other Web- related standards.

In a typical Web services scenario, a business application that could be a Web service uses SOAP message, usually over the HTTP transport protocol, to send a request to another service at a URL. The service receives the request, processes it, and returns a response. In a supply chain scenario, Web services and their consumers are typically businesses, making Web services predominantly business-to-business (B2B) transactions. An enterprise can be the Web service provider and also the consumer of other Web services. For example, a wholesale distributor of spices is in the consumer role when it uses a Web service to check on the availability of vanilla beans and in the provider role when it supplies prospective customers with prices for vanilla beans.

Problem

Integrating diverse business applications into a cohesive, reliable, and secure architecture is a common challenge that most enterprises have to address on a daily basis. In the previous example, depicted in Figure 4-1, a wholesale distributor may be a Java EE system, while a product manufacturer is a .NET or a legacy system.

Figure 4-1. Sample scenario

As can be told from this diagram, the application-to-application interaction represents a traditional Remote Procedure Call (RPC), where two systems are integrated using a synchronous communication mechanism. A client receives information on the order placed based on the results received from the Product Manufacturer. Picking the right technology and determining the style of communication (synchronous versus asynchronous) are important success factors.

Solution

Web services have become a de facto standard to effectively achieve interoperability across diverse sets of enterprise applications and offer a preferred technology choice for integration. Here is the reason why: Interoperability, simplicity, XML-based human readable format, and ease of use help streamline inter-application communication. Therefore, Web services are widely used for both B2B as well as corporate inter-application integration. Conceptually the Web service model involves the following elements:

Agents The agent is the concrete entity (a piece of software) that sends and receives messages.
Services A service is some well-defined operation or abstract functionality that is network-accessible by other systems using its service description.
Provider The provider is the owner of a service and could be a business or an individual.
Requester The requester entity is a business or individual that discovers or invokes the provider entity's Web service.
Service Description The service description is the interface for a Web service and describes the mechanics of message exchange. The description includes the message formats, data types, network location (that is, the URL), transport protocols, and transport serialization formats that should be used between the requester agent and the provider agent.

Web services often used to enable Service Oriented Architecture (SOA), with the primary goal of Web Services Architecture (WSA) being to promote interoperability. Web services provide a means of interoperability across heterogeneous systems, platforms, applications, and programming languages. As part of that, Web services present a useful mechanism for integration of Java EE applications with those built on the Microsoft .NET Framework. When using Web services for interoperability between Java EE and Microsoft .NET, you can gain a lot of architectural flexibility. Because they are XML-based, loosely coupled , and coarse grainedyou can design a flexible adaptable SOA. However, Web services are not the "end all be all" of application integration approaches, and there are limitations in using them that need to be kept in mind. The benefits and limitations of Web services for interoperability are discussed in more detail toward the end of this chapter.

Web Service Technologies

Web services are fueled by XML, which, being a markup language, enables neutrality of platform, language, and vendor. XML is also the key to the loosely coupled nature of Web services. A Web service is an abstract entity defined by an XML-based interface, Web Services Description Language (WSDL), and communicated using an XML-based protocol (SOAP) or Representational State Transfer (REST). This is the essence of the Web services value propositionthe abstract nature of the Web service definition, discovery, and communication, the underlying implementation, be it .NET, Java EE, or something else is completely abstracted away from the consumer. Similarly, there is a flexibility of sending SOAP messages over HTTP/S, FTP, or SMTP transport protocols.

SOAP is the technology used for communicating with Web services. While very simple information transfer services can be implemented without SOAP, secure, reliable, multi-part, multi-party and/or multi-network applications are much easier to build if there is a standard way of packaging the messaging information in a protocol neutral way. This also allows the messaging infrastructure (which may be specialized hardware, SOAP intermediaries, or code libraries called by the ultimate recipient of a SOAP message) to provide authentication, encryption, access control, transaction processing, routing, and delivery confirmation services. SOAP envelope (and attachment) structure and header/processing models have proven to be a very robust and powerful framework within which to do this.

Interoperability across heterogeneous systems requires a mechanism to allow the precise structure and data types of the messages to be commonly understood by Web services producers and consumers. WSDL provides a precise description and is the basis of how Web services SOAP messages can be generated for exchange between the consumer and the service. In addition to describing the Web services application interface, WSDL also enables how a Web service is described in a business registry and from where it can be discovered . A business registry is somewhat like an electronic telephone directory, as it contains listings of services and how you can talk to them. Typically these registries are based upon the Universal Description, Discovery and Integration (UDDI), another XML-variant. Finally, the information that Web services interchange can be formatted according to a well-known public XML schema. Depending on the content, there are many schemas available such as Extensible Business Reporting Language (XBRL) and Market Data Definition Language (MDDL).

WSDL, SOAP, and UDDI act as the lowest common denominators for creating and consuming Web services, whereas the service implementing details are different in Java and .NET. The good news is that regardless of one's skill set, each of the platforms provides a means to develop and deploy interoperable services.

Java Web Services

On the Java side, several Java technologies work together to provide support for Web services. These technologies can be accessed via Java Web Services Developer Pack (JWSDP) toolkit or corresponding development tools that might be used to construct Web services. Please refer to [JWSDP] for details and download.

As a starting point, the Java API for XML-Based RPC (JAX-RPC) provides support for Web services using the SOAP over HTTP. JAX-RPC defines the mapping between Java classes and XML as used in SOAP RPC calls. Multiple examples in this book are implemented with JAX-RPC, demonstrating a diverse set of scenarios in which the developer can utilize this technology. With JAX-RPC and a WSDL, one can easily interoperate with clients and services running on Java-based or non-Java-based platforms such as Microsoft .NET. Figure 4-2 outlines key components of JAX-RPC.

Figure 4-2. JAX-RPC overview

On the client side, there are stubs corresponding to Web services, while on the server side Web services are compiled into the corresponding ties. The underlying message and transport protocol should be the same to ensure interoperability between a client and a server. Please refer to [JAX-RPC] for more details. There are three modes in which a JAX-RPC client can interact with the server. The first one is a traditional synchronous request-response ; the second one is a one-way RPC that allows a client not to block or wait for a response; and the third one is a non-blocking RPC where a client can continue execution within the same thread and later block for the receive or poll for the response. This chapter demonstrates how to develop the JAX-RPC request-response application using Java client and .NET server and vice versa.

Aside from JAX-RPC, Java Web Services include the SOAP with Attachments API for Java (SAAJ) [SAAJ]. This API is used to pass business documents (in binary format) by attaching them to the SOAP message. To ensure interoperability of the binary data attachments in the SOAP document, both Java Web Services (via JAX-WS) and .NET offer the SOAP Message Transmission Optimization Mechanism (MTOM), [MTOM].

Developer's Note

Since the release of JAX-RPC 1.0, new specifications and new versions of the standards that it implements have been released. JAX-WS 2.0 [JAX-WS] is the successor to JAX-RPC and relates to the same specifications and standards, but adding significantly to it. It includes the following:

JAXB
SOAP 1.2
WSDL 2.0
WS-I Basic Profile 1.1
Meta Data Annotation for Java (JSR 175)
Web Services Metadata for Java (JSR 181)
Enterprise Web Services (JSR 109)
Web Services Security (JSR 183)

Additionally, it extends and improves support for document-based /message-based SOAs around:

Asynchrony
Non-HTTP transports
Message access
Session management

As part of the SOA, services are often published in the UDDI registry. The Java API for XML Registries [JAXR] provides client access to the XML registry. The Java API for XML Registries [JAXR] allows access to business and general-purpose registries over the Web. JAXR supports the ebXML Registry/Repository standards and the UDDI specifications.

The Java Web Service Developer Pack also includes APIs to bind XML schemas to Java classes, provided by the Java Architecture for XML Binding (JAXB) [JAXB]. The JAXB binding compiler can be used to automatically generate Java domain objects.

Document parsing and transformation often are necessary operations for Web services. For that you can use the Java API for XML Processing (JAXP) [JAXP] that supports processing of XML documents. JAXP can be used with Document Object Model (DOM), Simple API for XML Parsing (SAX), and XML Style sheet Language Transformation (XSLT).

Table 4-1 contains a summary of common APIs included in the Java Web Services Developer Pack:

Table 4-1. Java Web Services API Summary

JAX-RPC	Web Services implementation and invocation
JAX-WS	Java API for XML Web Services
JAXR	Service registry and lookup
JAXB	XML schema binding into Java object tree
JAXP	XML parsing and transformation
SAAJ	Document attachment

Perhaps the most important feature of the Java EE APIs for Web services and XML is that they all support industry standards, thus ensuring interoperability. Various network interoperability standards groups, such as the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS), have been defining Web services standards to allow disparate applications to seamlessly integrate with each other.

Web Services in Microsoft .NET Framework

Microsoft .NET provides two mechanisms for building Web services. The first and more widely used approach to implement Web services is to use the Microsoft .NET System.Web.Webservices namespace in the .NET Framework. A server application might have its methods defined as Web methods using the [WebMethod] attribute. This approach will be used to build a Microsoft .NET Web service for illustrating interoperability with a Java EE client later in this chapter, along with an explanation of the significance of various attributes and directives in WebMethods Framework.

Another technique is to write a custom HTTP handler class that plugs into the Microsoft .NET HTTP pipeline by implementing the IHTTPHandler interface. HTTP Handlers are objects that process requests for individual URLs or URLs with certain file extensions (such as .asmx or .aspx). Building custom handlers requires the use of System.Web APIs to process the incoming HTTP message along with the System.Xml APIs to process the SOAP envelope found in the HTTP body. Writing a custom handler also necessitates manually authoring the WSDL document that accurately describes the Web service implementation. It also requires a solid understanding of the XML, XSD, SOAP, and WSDL specifications. Microsoft ASP.NET ships with a special IHttpHandler class for .asmx endpoints (called WebServiceHandler ), which provides the basic XML, XSD, SOAP, and WSDL functionality that developers need to build Web services.

The latter methodology allows for greater flexibilityparticularly when there is the need to pre- or post-process the contents of the SOAP message, but for the sake of simplicity the former is used throughout this book.

On the client side, proxies are used to communicate with a Web service. These proxies are automatically generated by the wsdl.exe tool that is available within the .NET Framework or from Visual Studio.NET. These proxies, once included in a project and linked in when compiling code, manage communication with the Web methods that are exposed by the service. They are generated by parsing the WSDL file that describes the Web service.

XML Processing, which is central to Web services, is inherently part of the .NET Framework. For SOAP messages being passed in and out of a Web service, the XML processing is implicit, being performed by the runtime on the developer's behalf . So if a Web method is exposed (that expects a string to be passed into it) while the underlying communication from the client to the Web method is a SOAP message, the code simply receives the string passed in as if it were a local method call.

XML can, of course, be used directly, using the classes within the System.Xml namespace [MSXML] to create, load, parse, and edit XML documents, including SOAP examples.

The .NET Framework does not include UDDI functionality by default. If you want to publish or otherwise interact with UDDI servers, the platform UDDI software development kit (SDK) is necessary [MSUDDI]. This SDK implements a .NET assembly that may be used in applications, providing the Microsoft.Uddi namespace.

Following is an example of the UDDI SDK in action where the directory is being enquired for a particular service, and then the business services that match the enquiry are iterated:

UddiConnection myConn = new
    UddiConnection("http://test.uddi.myserver.com/inquire");
GetServiceDetail gs = new GetServiceDetail(strKey);
ServiceDetail servDetail = gs.Send(myConn);
foreach (BusinessService bs in servDetail.BusinessServices)
{
   ...
}

To handle attachments such as Direct Internet Message Encapsulation (DIME) or Message Transmission Optimization Mechanism (MTOM), Microsoft has a suite of libraries as an add-on to the .NET Framework called the Web Services Enhancement packs . These are updates to the .NET Framework that implement the latest WS-* standards in between large scale releases of the framework. More details on the WSE and how it can be used to implement MTOM attachment handling are provided later in this chapter.

For a complete guide on all things to do with Web services in the Microsoft and .NET world, the MSDN Web services developer portal is an excellent resource. [MSDNWSP]

The Microsoft philosophy for software is very much centered around building software as atomic service-oriented components. It is with this in mind that the next generation of Microsoft software development APIs includes a new Windows Communication Foundation, a single API for building software-as-a-service, which adds on to version 2.0 of the .NET Framework. This API, part of a family of foundation APIs (Windows Workflow Foundation, Windows Presentation Foundation, and so on), will be the core API for building connected service-oriented systems. For more information, refer to the "Advanced Web Services" section in this chapter or the MSDN resource for WCF [MSDNWCF].

Buy on amazon.com >>

Fisher M., Lai R., Sharma S.

<< Previous page

Table of contents

Next page >>