As you review your options, after the brainstorming, you find you essentially have three possibilities.
A Web Site
The first option is to build a private Web site for retailers. After logging in to the site, retailers could check the availability of products.
The main argument in favor of this approach is that it is likely to be familiar to your developers. It would require connecting your Web server to the warehouse management application. You can find tools on the market (known as application servers ) to help you build this solution.
The main issue with this solution is that it involves yet another Web site: To access stock data, the retailer must start his browser, log in to your site, and type his query. Your Web site is completely independent from the retailer's own inventory manager.
However, chances are that the retailer employees need to first search the product in their local warehouse. It's only when the product is not available locally that they will order from you.
Figure 9.1 illustrates this. Notice the two applications: the retailer's own stock manager and yours, which is Web accessible.
Figure 9.1. The wholesaler Web site is independent from the retailer's stock manager.
In practice, companies are increasingly reluctant to train their clerical staff to access third-party Web sites. For the retailer's IT people, it's yet another application to learn and support. For the clerk, it's an annoyance to have to enter her search twice.
Finally, you should consider online retailers. An online retailer wants to publish as much information as possible on its own Web site. This setup forces them to redirect their customers to the wholesaler's Web site, which is seldom a good idea.
Having established that a Web site does not properly serve your customers'needs, you'll strive to offer a more integrated solution.
Traditionally, to integrate applications running on different computers, you would use a distributed object architecture (middleware), such as OMG's CORBA, Microsoft's DCOM, or Java's RMI.
Essentially, the middleware wraps objects, such as Java or C++ objects, with a network layer. In this case, it would wrap the objects in your warehouse management application on a server.
This setup is illustrated in Figure 9.2. For the retailer, this is more attractive because he can integrate your data into his application. He has only one application to support.
Figure 9.2. Because objects are available on a server, the retailer can integrate them in his application.
However, this solution suffers from the following problems:
One of the first practical problems is the use of firewalls. Most corporate firewalls accept only HTTP and SMTP traffic and will block CORBA and DCOM.
Furthermore, because it's an object server, you literally expose the guts of your application. The retailer can grab one of your application's objects and call its methods . This creates a very tight coupling between the two applications.
Who really wants to share her live application objects with outsiders? What happens if they inadvertently issue the wrong calls and crash your server? And we have not even touched on security.
Likewise, who wants to be responsible if problems occur with the retailer's application? He who publishes an object is responsible for its support. Do you really want to take over such a burden ?
To be fair to CORBA, DCOM, and RMI, I must mention that they provide mechanisms to alleviate these problems. For example, HTTP gateways are available to work around firewalls. Also, completely isolating your application from the objects on the server is possible.
Yet, it is when you have to deploy these advanced features that you find distributed object architectures can deserve their reputation for complexity!
Back to square one. At this point, you re-examine the Web site idea. Its main advantages were as follows :
The only problem is the integration issue. However, if you replace HTML with XML, you would have a format that can efficiently transport structured information and that enables integration. In essence, this is the idea behind SOAP.
SOAP is a protocol that formalizes how a Web client and Web browser can integrate using HTTP and XML. The most popular application of SOAP is XML-based remote procedure calls.
The SOAP approach is illustrated in Figure 9.3. As you can see, it combines the best of Figure 9.1 ( reliance on Web protocols) with the best of Figure 9.2 (integrated applications).
Figure 9.3. SOAP offers the same benefits as an object server but over the Web.
However, there is no such thing as a free lunch . The price you pay for the flexibility is efficiency. SOAP is significantly slower than distributed object architectures for the following reasons:
SOAP is another solution to implement a browser on autopilot, as introduced in Chapter 7. However, SOAP specifies what the request and response should look like.