Integration and Interoperability


We have already discussed the trend toward multifunction service-oriented P2P systems. These systems recognize the need for open architectures. Rather than defining a closed API that performs a specific function, P2P open frameworks are emerging that provide hooks, or published interfaces to provide extension and interoperability. This will be especially important if P2P is to become an important component in defining the architecture of a virtual corporation, as illustrated in Figure 5.4.

Figure 5.4. The virtual corporation requires three successive steps of integration: internal employees must be connected; external suppliers and partners must be connected with your internal systems; and both internal and external entities must be able to collaborate.

graphics/05fig04.gif

Virtual corporations integrate their systems employees, customers, and partners into a mesh-like topology. This is a much deeper level of integration, both internally and externally, than is common in most corporations today. However, as supply chain management continues to leverage public networks, the opportunity for this level of integration becomes viable. Virtual corporations also exhibit a much more dynamic relationship with their suppliers and partner systems. Business relationships come and go more frequently, and it must be possible for the systems that support this activity to keep pace.

Web services and P2P techniques that embrace XML can provide the basis of a solution. XML provides a common data format, and enables alternative middleware choices. This is an important attribute, because most large systems have invested significantly in middleware technology. Replacing middleware is never an easy undertaking. Often the middleware implemented is an extension of the current platform selection, and requires a specific transport implementation. XML can be used with a wide array of transports, including those being popularized by Web services and P2P networks.

These technologies are providing a unifying framework for service-oriented architectures. Intersystem processing and integration is not new. Other technologies, such as CORBA, EJB, and DCOM, have built solid frameworks for cross-system integration. However, these technologies often function best when used within the domain of large business systems, where the control of software selection is unified. When used to integrate intersystem processes, they often don't achieve the level required for virtual corporations because they assume a certain level of technology homogeneity.

Combining the dynamics of P2P group formation with the integration potential of Web services will have far-reaching implications. A technology solution to enable the virtual corporation might finally be at hand.

J2EE and Java Messaging Service

Java Messaging Service (JMS) is the J2EE-based messaging service. Messaging services continue to grow in importance because of their capability to loosely couple distributed systems. JMS attempts to standardize the messaging providers interface using Java. It supports popular messaging paradigms such as publish and subscribe. Subscribers register their interest in a topic or a pattern of events, then asynchronously receive events matching their interest, regardless of the event's publisher. Subscribers can come and go as processing mandates and the number of subscribers can change dynamically. Topic-based publish-subscribe communication is similar to group-based communication (shown in Figure 5.5); subscribing is equivalent to becoming a member of a group. Of course, building a system that can scale to support a large network in light of system failures on public networks is still a challenge. JMS will be described in more detail in Chapter 12, "Messaging and Java APIs for XML."

Figure 5.5. JMS topics can provide a bridge to JXTA peer groups. Both provide a level of publish and subscribe event notifications.

graphics/05fig05.gif

A sample implementation of JMS-to-P2P integration is Hive (www.alberg.com). Hive provides a JMS-based framework that enables non-JXTA clients such as browsers to interact with a JXTA client. In the Hive framework, servlets register as a topic in a JMS server. Web site activity triggers events that are published by the JMS server. Any interested entity can receive these events based on topic registration. In effect, topic queues map to state changes during Web site usage, such as when you complete a form.

Illustrated in Figure 5.6, Hive uses JMS as a standard layer over the JXTA Peer-to- Peer Platform.

Figure 5.6. Hive is a sample framework that uses JMS and JXTA to integrate P2P into the enterprise.

graphics/05fig06.gif

Web Services and SOAP-RP

As stated, Web services are not dependent on any specific infrastructure or middleware. The adoption of Web services will remove one of the obstacles to the integration of the virtual corporation by providing a common language to describe the interactions between cooperating entities, without forcing all parties to a specific middleware implementation.

Figure 5.7 shows how a client and a Web service provider can interoperate. It also extends the traditional triangle to integrate with JXTA services. The steps required include the following:

  1. The service provider registers itself and the services it provides. In this case, the service provides connection to a number of JXTA services.

  2. Clients that use this service query the UDDI registry to identify entities providing the required service and then download the service definition in WSDL.

  3. The client can then connect to the service provider and exchange the appropriate SOAP messages.

Figure 5.7. SOAP-RP provides an enhancement to the routing capabilities of SOAP. It enables the specification of routing paths.

graphics/05fig07.gif

We have extended the Web service to integrate with JXTA by translating SOAP-XML to JXTA-XML-compliant messages, and by using SOAP-RP.

SOAP-RP provides an enhancement to the SOAP protocol to extend its routing capabilities. SOAP-RP enables intermediary nodes to be specifically identified over a route path. This would be necessary to gain access to overlay networks. The simple routing of SOAP over HTTP is unable to accomplish this.

CORBA and SCOAP

The Object Management Group's (www.omg.org) Common Object Request Broker Architecture (CORBA) defines the programming interfaces to an object request broker (ORB). An ORB supports the communication between distributed objects. Much like RPC, objects make invocation requests on other objects regardless of network location. The ORB goes further to abstract network communication and programming languages required for object-to-object interaction. CORBA is yet another attempt to make distributed systems interoperate and integrate. CORBA gained modest acceptance during the 90s as specific industry groups, such as telecommunications, began to adopt the technology as the integration "glue" for the growing number of disparate systems that required some level of interoperation.

The Object Management Group's Interface Definition Language (IDL) provides a standardized way to define the interfaces to CORBA objects. IDL is often cited as defining the contract that exists between cooperating objects. IDL separates the interface from the implementation, thus giving implementors flexibility performance, optimizations, and extended features of service implementations. The mapping of IDL to specific languages provides flexibility in language and platform selection, and helps to avoid a "one-way" mentality to service implementation.

Not wanting to be left out of the Web services craze, OMG is positioning its CORBA support. An IDL mapping called the Simple CORBA Object Access Protocol (SCOAP) is being defined to support the SOAP protocol. This will enable SOAP clients to communicate with CORBA services and SOAP servers using CORBA (see Figure 5.8). This will also promote ORB interoperability over the Internet by tunneling IIOP over SOAP/HTTP headers. IIOP (OMG's Internet Inter-ORB Protocol) defines an interoperability protocol for ORBs using TCP/IP.

Figure 5.8. The SCOAP protocol enables CORBA to integrate with Web services. The common element with P2P appears to be XML and HTTP. The CORBA event service already supports the publish/subscribe style of notifications.

graphics/05fig08.gif

This effort once again points to the convergence occurring with architectures based on XML messaging using HTTP.

Jini and JavaSpaces

Jini does not make XML or HTTP fundamental to its integration model. It is based on Java-defined interfaces. You are more likely to use Jini and JavaSpaces if you are developing in a Java language-based environment. This is not a strict requirement, but more of a practical one.

That said, the Jini services provide an optional path to service integration. Fundamen-tally, Jini is about services, and the ad hoc formation of services enabled through a lookup service using multicast or unicast messaging. This maps well to the environment of P2P peer groups.

JavaSpaces is especially well suited to providing the foundation for rendezvous peers. The JavaSpaces service provides a simple programming API that enables distributed applications to share and persist communication. The service also supports distributed transactions using the Jini transaction service. This could play a critical role in enabling distributed transactions between partners in the virtual corporation.

The use of Remote Method Invocation (RMI) as an underpinning in the architecture provides code movement over the network. In other words, it is the only architecture presented that is based on the concept of code mobility. This has two important implications:

  • Administration can be minimized and simplified through dynamic updates.

  • As agent software becomes more prevalent on the Internet, code mobility (RMI) can provide a framework for mobile agents.

There are a number of concepts, such as leasing, that map well to the unstable environment of the Internet, and thus P2P systems in general. We will discuss JINI and Javaspaces in Chapters 14 and 15.



JavaT P2P Unleashed
JavaT P2P Unleashed
ISBN: N/A
EAN: N/A
Year: 2002
Pages: 209

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net