Peer Based Enterprise Architectures with XML
1. Abstract
In response to requirements of eCommerce and the need for a more fluid business environment, enterprises need to integrate their systems with those of their suppliers, customers & employees, forming an Extended Enterprise. This requires much deeper integration between internal and external systems. The integration must also allow the interactions between systems to change, and even in some cases for systems to be added or removed entirely, as business relationships change. XML, and in particular web services, coupled with Peer-to-Peer (P2P)techniques can provide the basis of a solution. This paper discusses some issues involved and proposes some principles for developing a satisfactory solution. Web Services and Sun’s specifications are compared and discussed in this context.
2. The Extended Enterprise and the integration problem
Until recently, integration projects have been limited to systems within a single enterprise or even within a single department within the enterprise. Increasingly applications need to be integrated across entire enterprises and with the third party systems of suppliers and customers. (The problem of cross department integration is often very similar to cross-enterprise integration.) Although the idea of such an Extended Enterprise level integration first appeared in the mid 1990s, the first generation of Extended Enterprise infrastructures are only now emerging across many different industries, including:
| · | Finance (Global Straight Through Processing) |
| · | Manufacturing (Integrated Supply Chain Management) |
| · | Telecommunications (Next Generation Operational Support Systems) |
The primary business benefit that an Extended Enterprise infrastructure delivers is agility, which allows companies to rapidly respond to emerging opportunities and threats while providing significant efficiencies and cost savings. At an IT level, agility is the ability of an enterprise to deliver new product offerings or variations on existing product offerings, and the ability to integrate with new customers or suppliers in shorter timeframes with lower overheads. The lack of agility is a real and pervasive business problem, as illustrated by the Spikes Cavell survey which recorded that 70 per cent of business respondents said lack of integration had a significant cost impact on their business.
3. Peer-to-Peer concepts
Due in no small part to the marketing frenzy around it, P2P has become a term that covers a diverse and apparently unrelated set of technologies. P2P has come to encompass: · ‘Spare CPU cycles ’ utilization approaches of SETI@home and Intel / United Devices Cancer Research Program · Instant messaging systems such as ICQ and Jabber · Collaboration systems such as Groove · File sharing systems, the most famous of which is Napster There are however some common attrbiutes which underpin all of these:
1) Connectivity between peers is not constant and peers may join or leave the network. In the original P2P systems, there are no fixed DNS derived names or even static IP addresses. For the purposes of this paper, I regard this as a technical feature, not a fundamental characteristic.
2) The precise split of processing between systems is variable, and often processing is moved from the core to the fringes of the network. This takes the load, and more significantly the control of the network, away from centrally located servers and moves it to the best location for the task at hand.
3) Peers communicate directly without indirection through a hub. For a pure P2P system a hub should not be used even to discover services.
A notable P2P project is JXTA, the open source project lead by Sun. This attempts to provide an infrastructure for building P2P applications independent of platform, operating system or programming language. The JXTA components provide the minimal generic requirements and form only the base building blocks required to construct any arbitrary P2P applications. This commitment to generality has the potential to allow JXTA to support as yet unthought of P2P applications, but does make it less complete when building any specific application today.
4. XML and Web Services
XML provides a common data format, and in particular separates the middleware choices from the data format selection. This second attribute is often overlooked as most users associate XML with HTTP. In fact, XML could be used with P2P transportssuch as those provided by Jabber or 3Path. In fact, there is a convergence on a small number of middleware infrastructures used under XML: HTTP for Internet based applications and JMS for intranet systems. . There are many industry consortia, such as RosettaNet, ebXML and the ISO15022 group in the financial services industry, working on the next layers up of the architecture stack. These deal with how business level documents can be exchanged within specific industries and define the precise document types and sequence of document exchange. In comparison with the base XML standard, these initiatives are mostly still quite fluid and may take some time to mature. This means that for the foreseeable future the XMLized business will need to handle its own XML, that of its customers and partners, and the industry specific standards as they evolve.
Web Services provide a layer on top of XML focused on architecture for the creation, advertisement and consumption of XML defined services. At its most basic level, a Web Service is a component of business processing that may involve one or more business systems. To allow each component to be integrated in a useful way, two additional elements are needed:
· A standard way of sending and receiving the information required to complete the business processing (e.g. XML, with an additional standardized envelope called SOAP, which is also part of the ebXML standards)
· A standard way of publishing descriptions of the services that are provided. The leading standards are UDDI (which can use WSDL as a way of describing actual XML document exchanges within the conversation) and the forthcoming ebXML registry
The service definitions and communication mechanisms are not dependent on any specific infrastructure or middleware. Hence, the adoption of Web Services will remove one of the obstacles to the integration of the Extended Enterprise by providing a common language to describe the interactions without forcing both parties in the interaction to use one form of middleware.
Figure 1 shows how a client and a Web Service provider can connect and complete a conversation. First the service provider must register itself and the services it provides. A client wishing to use this service must query the UDDI register to identify entities providing the required service and then download the service definition in WSDL. With this information, the client can connect to the service provider and exchange the appropriate SOAP messages and hence complete the required conversation.
If we attempt to match the Web Services worldview with the P2P worldview, we find that there is a good match for the connectivity (attribute 1 of P2P ) and direction connection aspects (attribute 3) of P2P. The final requirement (attribute 2) for a flexible split of processing may appear to contradict the client-server nature of Web services. However, it is possible for a Web Service provider to also be a consumer and hence be a peer to other systems.
5. The Extended Enterprise and P2P
The Extended Enterprise is in a constant state of change and the type of change can be matched to the principles of P2P network. In particular:
1) The external systems to which the enterprise must connect change as new business relationships are created and destroyed.
2) The precise business process executed is often unique to the pair of enterprises involved and a single enterprise will perform different roles in different interactions. In the simplest case, all enterprises are customers to one set of businesses and suppliers to a second set. What an enterprise does in each interaction will depend on its role.
3) In almost every case, the most efficient connection is directly between the businesses. Any intermediary adds latency and more importantly cost, as well as disrupting the inter-company relationship. The only exceptions are when the transactions do not deliver competitive advantage. For example, the automakers are willing to work together on efficient part procurement but are unlikely to pool together on the customer-facing side of the business.
Peer-to-peer principles can be seen to map well to some of the problems faced in integrating the Extended Enterprise. This suggests that P2P provides a potential solution to the integration problems within the Extended Enterprise. However, P2P is not a single architecture and there are no mature implementations that can be adopted.
In comparison, XML is beginning to be accepted as a general data format and hence integration format. Indeed, JXTA makes extensive use of XML. Leveraging XML, Web Services provide some of the features of P2P as will be seen in the next section, but lacks others that will need to be added to the standards or by software vendors in a proprietary manner.
5.1. A peer infrastructure:
Both JXTA and the Web Services standards seek to provide a substrate for developing generic inter-system processing and integration. In the past, inter-system integration has been achieved using distributed technologies such as CORBA, COM and EJB. However, these approaches require homogeneity of infrastructure that is not feasible when we consider the inter-enterprise, or even inter-department system. There are some characteristics of an infrastructure capable of supporting Peer-to-peer communications in the enterprise setting. These are:
| Feature | Description | JXTA | Web Services |
| Group or domain definition | This defines which peers are able to communicate and what services they can access. This is dealt with in more detail in the next section | Peer groups | Not defined |
| Access | The access to services and other resources within a domain must be controlled and access to membership itself must also be controlled | Security Service | Not yet defined: access control and authentication are implementation specific |
| Discovery | Discovery covers how a domain is discovered, how members of a domain are discovered and how services offered by the members are discovered | JXTA discovery protocol | Registries, which are global or at an enterprise level |
| Description | The way the services offered by each peer or peer group are defined | XML-based advertisement | UDDI description of the service provider including a WSDL description of the service |
| Communication | The enabling mechanism for peers to send messages to each other | Pipes (1 way asynchronous connections) which transmit XML-based messages | SOAP supporting both RPC style and document style |
At first look at the above table, it may appear that JXTA is more mature than the Web Services standards. As we will see in the next section, the concept of a domain or peer group is essential to integration in the Extended Enterprise and is missing from Web Services today. Even so, this conclusion would be misleading as JXTA is much more generic, and much of the specifics that would be required for corporate deployment are undefined. In comparison, Web Services are already being used in this environment and it is likely that security in particular will be resolved over the coming year. In the rest of this paper we will consider these two issues: peer groups and handling change in the services published and consumed.
5.2. Peer Groups
JXTA refers to the set of connecting peers as a , where membership is changing with new joiners appearing and leavers disappearing. Once a peer has become part of a peer group it may discover and utilize existing services or advertise its own services.
In the enterprise setting, the peer groups may correspond to groups of companies or systems participating in specified business transactions. It seems likely that it in most cases there will not be uncontrolled access to groups. Registration is something that in the corporate setting will be controlled by business relationships. In general it is likely there will be a group owner. This undermines the principle of cooperating peers, but matches the business realities where most business transactions have one party in a controlling position. There are at least three possible distinct types of group owner:
- An industry organization, such as ACORD in the Insurance Industry or Identrus in Finance, that provides definitions of services through standardization processes
- The driver within the particular value chain (the car makers in the auto industry for instance), which will be the owner and define the services and interaction models
- Neutral match makers. This is likely to be the least common, as can be seen from the failure of most of the on-line market places which attempted to act in this role.
As mentioned in earlier sections, Web Services has the notion of a registry. There are three well known global registry of web-services, run by IBM, Microsoft and HP, and these will continue to play a role in providing generic web services. In addition, it is likely that individual peer groups or even peers will maintain their own registries that will augment the global registries.
5.2.1. Security and Peer Groups
Within any group, there are obvious and significant security considerations. Simple security within WebServices is already straightforward to implement, if not yet standardized. There are other standardization efforts underway to provide full strength security for XML, notably the ongoing work on the XKMS standard for adding PKI style security to XML. This could match a group-based model, as the group registry could also act as an actual or proxy for the certificate authority.
5.3. Handling Changes in Service Definition
There is an underlying assumption behind Web Services and P2P that either service definitions don’t change or that consumers of Web Services are capable of adapting to changes without an unacceptable overhead. Unfortunately this is generally not the case, as any change to a service provided or consumed requires code changes and hence significant delay in changing a system to support a new service definition. This is unacceptable in an Extended Enterprise that must be capable of supporting a new customer or partner as quickly as possible, with minimum risk and disruption to existing systems . Figure 2 shows the traditional approach to the creation of hard-coded interfaces. The consumer and provider of each hard-coded interface have code embedded into their system to manage the interface.
A rules-based system can be used to reduce this problem significantly. The rules can operate at a business level or simply define routing and forwarding logic. In either case, the rules map the incoming XML document to the business logic without creating a static interface. With these rules-based interfaces, shown in figure 3, a new interface can be added by changing the rules. When new business logic is required, it can be added without disrupting the existing rules and logic. and hence without impacting on the existing supported interfaces.
6. Conclusions
The problem of integrating the Extended Enterprise has been shown to share some architectural considerations with the P2P model. The Web Services architecture is already beginning to be adopted for integration across companies, but lacks some critical features. By extending the Web Services architecture with ideas of peer groups, and addressing the issue of changeability, it has the potential to become the basis of Extended Enterprise integrations.