SOA Web Services - Differences between B2B and EAI Web Services

Differences between B2B and EAI Web Services

Let us first look at the differences between B2B and EAI. The major differences may be listed as follows:

1. EAI as the name suggests acts within an enterprise to solve a local problem, while B2B as the name suggests acts across the enterprises.

2. EAI aims at integration of application and data sources within an enterprise, while businesses integrate for purposes such as a supply chain or collaborating on a common product design.

3. B2B mandates implementations of community management, user profile management, and sophisticated security management, while such services are not required for EAI.

4. B2B may require a deep support for standards such as OBI (Open Buying on Internet), XML, cXML (Commerce XML), and EDI (Electronic Data Interchange), while EAI has no requirement for such standards.

5. The connectivity to a single application in EAI is relatively small, while in the case of B2B the number of partner connections can be large. Also, the connectivity is unpredictable in B2B.

Having considered the differences between EAI and B2B, let us look at the differences in SOA implementation in the two cases.

Interface Design

As EAI is within an enterprise, the restrictions on the interface design can be relaxed as compared to B2B. You may use the SOA approach for exposing the services. However, you may decide not to use standard web protocols while implementing SOA. The protocols may be totally proprietary if it eases the integration. Secondly, the protocols don't need to be web-based as there may not be a need to access the service over the Web. An example of one such protocol is OpenEAI Message Protocol. This is a messaging protocol that expresses all actions on enterprise data objects in terms of request/reply and publish/subscribe messaging models. It also includes administrative information required for implementing security, routing, logging, and auditing. Other protocols are Omri and Indigo; these are recognized by Microsoft for B2B applications.

Compare this with the B2B situation in which the interface has to be exposed using standard web protocols as the service will be invariably accessed over the Web potentially even by unknown users. Even in the case of known users, there could be differences in the platform and technologies used by the consumer and the server. Thus, the use of standard web protocols becomes a mandatory requirement in order to make your service universally accessible.

The other factor that needs to be considered during the interface design is the security implementation. The messages must be protected and the data integrity must be guaranteed. This is a mandatory requirement in case of B2B, while in case of EAI this may be relaxed. The security can be easily compromised in the case of EAI as the interaction is restricted only within the organization. As a matter of fact, in most of the EAI situations, the security is totally discarded. This is mainly due to the complexities involved in implementing and managing security. Also, the secured channel reduces the system performance.

Now, we will look at the need for and use of a service registry in these two cases.

Use of a Service Registry

The service registry stores the information about the various services. In the case of EAI, as the services are offered and consumed locally, the use of a service registry is not recommended. Only in the case of large enterprises, where the number of services could be large, is a service registry suggested. If the number of services is small, it will be easier to publish them by other means such as paper or electronic documents rather than storing them in service registries. In the case of B2B, the use of service registries becomes a mandatory requirement.

In a B2B situation, it is important that the business must make its services publicly known. An unknown consumer can look up the service registry for a desired service. Once a desired service is identified, the consumer can obtain its interface and bind to the service provider to consume the service.

Using a service registry also requires an additional effort in coding the client applications and managing the registry. It also results in additional processing time. In the case of EAI as the services are available locally, these overheads are unjustifiable. In the case of B2B, there is no option other than to bear these overheads.