Chapter 9. Provide Up-to-the-Minute Information to Business Partners

   

Architecture

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.

graphics/09fig01.gif

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.

Distributed Objects

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.

graphics/09fig02.gif

However, this solution suffers from the following problems:

  • CORBA, DCOM, and RMI have a reputation of being complex. I believe that if you give them the benefit of doubt, you'll find that most horror stories are unjustified but, still, it will be a tough sell.

  • Distributed object architectures were designed primarily to work over local networks and are not optimized for the wider Internet.

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 ?

Warning

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!


SOAP

Back to square one. At this point, you re-examine the Web site idea. Its main advantages were as follows :

  • It is easy to set up because it uses technology with which you are already familiar.

  • It is cheap to operate for the same reason.

  • It has a proven track record for being deployed over the Internet.

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).

Specifically, SOAP

  • Works across firewalls because it runs over HTTP

  • Is as easy to set up and manage as a Web site

  • Is based on well-known technologies

  • Is not limited to a local network but is designed for the wider Internet

Figure 9.3. SOAP offers the same benefits as an object server but over the Web.

graphics/09fig03.gif

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 uses text-based messages that must be parsed on the receiving end and tend to be larger than binary protocols.

  • SOAP relies on HTTP for communication, and HTTP is not the fastest protocol around.

Note

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.


   


Applied XML Solutions
Applied XML Solutions
ISBN: 0672320541
EAN: 2147483647
Year: 1999
Pages: 142

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