Section 10.3. Business-to-Business


10.3. Business-to-Business

In a business-to-business (B2B) environment, a corporation offers some service to another company over public networks such as the Internet. In a B2B scenario, both the service consumer and the service provider benefit greatly from standard communication protocols. The service consumer profits from the increased flexibility gained when changing to another provider or when using several providers at the same time. The service provider can also profitfor example, depending on the type of communication, it might be possible to eliminate the necessity to ship software to the client.

The same goes for the security infrastructure. Because security infrastructures can get very complicated, the client and server must be certain to use a mechanism that can be trusted, where both ends of the communication chain can identify a security violation using their standard system management tools. Standards are also desirable because many interactions create a legal obligation between the parties.

In addition, it is attractive to define a standard format for the actual data being transferred. This saves both sides time and money in service development and integration. UN/CEFACT (ebXML) and RosettaNet provide examples of initiatives to establish data standards.[1] Although the resulting standards are not yet mature and they are not appropriate for all B2B problems, it is worthwhile to see if they are applicable in specific cases.

[1] See the URLs list at the end of this chapter.

Most initiatives that define standard protocols result in the creation of rather large documents that are exchanged in a business transaction. This is basically analogous to a service-oriented approach with very coarse granularity. Because of the latency that can be experienced on a public network connection, it is far more efficient to send a single large document instead of making short procedural interactions.

Although the business process itself can be stateful, it pays to create stateless service invocations. In a B2B scenario, the most common way to achieve this is to pass a token along with every service invocation. These tokens can be used once or on a cyclical basis if the number of tokens is large compared to the frequency of interactions.

Go Stateless for B2B

Stateless semantics are especially important in B2B scenarios. They enable interaction with remote customers over connections with high network latency. They also create much fewer constraints for the calling applications.


Although the authors do not believe that a runtime-naming service or repository is mandatory in an SOA environment, it is of great use in a B2B scenario. The pressure for a service to provide location transparency is far higher than in a controlled enterprise environment. After a business partner uses a service, it might require significant effort to switch to a different version. Even if it can be achieved by configuration only, it still creates an overhead that might result in unwanted downtime. Both service user and provider can be separated by large distancesas much as thousands of miles. This makes location transparency a necessity in order to provide disaster recovery capabilities. If a customer uses a service of a company whose main computing center goes down in a fire, the customer expects to be transferred to the secondary site automatically. Of course, this also includes the service repository itself being failsafe.

Location Transparency for Stable B2B Services

B2B scenarios require real location transparency using service repositories. This enables customers to securely establish long-term relationships regardless of changes to the supplier's infrastructure.


B2B scenarios can include online billing mechanisms, although they are more common in a business-to-consumer (B2C) scenario. A B2B scenario will generally log only access information on the side of the service provider. This information can later be used to create a monthly invoice.

In a B2B scenario, the check-in service can be used by partner airlines to check in customers on a flight leg that is operated by the service provider. In contrast to the examples considered so far, the main difference is that the service provider cannot validate the actual request against its own ticket database. There are several options for handling this situation.

The first option is to trust the remote system because it is well established that the business partner is trustworthy and provides only valid requests. Here, the remote check-in service does not have any information about the tickets that are used on individual flight legs, nor does the service have any information regarding the respective passenger. Data that directly relates to customer service qualitysuch as the customer's meal preferencemust therefore be passed in the check-in call itself. This is shown in Figure 10-8.

Figure 10-8. One-way communication scenario. The ticketing company performs the check-in using the operator's service, passing all the relevant data during the call itself.


The second option is to synchronize all relevant ticket and customer data between the partner companies on a regular basis. The ticketing company forwards the ticket data to the operating airlines, and the operating airlines in turn forward the flight information back to the ticketing companies. Although the check-in process is similar to the ones discussed in earlier chapters, service access within a single corporation is all that is needed during the actual check-in operation.

Finally, the third option in the B2B scenario is that the service provider becomes a service consumer at the other airline's ticket information service. In this situation, both businesses create an effective two-way communication scenario. Because the clients trust each other, the operating airline can validate the tickets of the partner's customers and retrieve some part of the customer preferences. This scenario is shown in Figure 10-9.

Figure 10-9. Two-way communication scenario during the check-in process. The flight's operator uses the services of the ticketing company to validate flight coupons and retrieve customer preferences.


When using external services, care must be taken to cope with the breakdown of the external service. Even if SLAs exists that guarantee a certain availability of the external service, network failures or failures of equipment on the client side should be anticipated. The error should be handled gracefully using the same general principles outlined in Chapter 9.

In general, the best type of service for this scenario depends on both the level of customer service one wants to provide and the technical capabilities and geographical locations of the airlines.

If the partners have weak connectivity, it might be best to use the first option and provide the necessary accounting information separately from the actual process. A common reason for choosing this type of solution is when latency is so high that any additional server-side processing introduces unbearable risks on system performance. Another strong reason for this scenario is when only certain partners are technically capable of operating as service providers.

If the partners are separated by a large distanceconsider a European and a South American carrieran infrequent synchronization mechanism might offer the best solution.

If the partners are located close together and can use a stable connection with sufficient bandwidth, they can use the third scenario. This offers customers the best service, enabling them to buy a ticket from one airline and check in with another airline easily. It also results in the best data quality.



    Enterprise SOA. Service-Oriented Architecture Best Practices
    Enterprise SOA: Service-Oriented Architecture Best Practices
    ISBN: 0131465759
    EAN: 2147483647
    Year: 2003
    Pages: 142

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