5.3 Heterogeneous Synchronous Drawbridges


5.3 Heterogeneous Synchronous Drawbridges

Heterogeneous synchronous drawbridges differ from their homogeneous cousins in that they are designed to link fortresses built on different technology bases ”for example, .NET and WebSphere.

Many organizations standardize on heterogeneous synchronous drawbridges because such drawbridges can accommodate requests from both homogeneous and heterogeneous fortresses, or even from fortresses outside the organization. I usually do not recommend standardizing all drawbridges as heterogeneous. The homogeneous performance optimization is worth using, where you can. As far as external fortresses go, you will never accept an external request through a heterogeneous synchronous drawbridge. Instead you will insist that such requests go through a Web service fortress, a topic I will discuss in Chapter 10 (Internet Fortresses).

To improve your understanding of the technology underpinning the heterogeneous synchronous bridges, it is helpful to spend a moment thinking about why homogeneous synchronous drawbridge technologies fail in the heterogeneous world. Remember that all synchronous drawbridges (both homogeneous and heterogeneous) are based on component systems. The homogeneous flavor is based on proprietary protocols, such as .NET Remote Binary Protocol or Java RMI/IIOP.

The proprietary remote method invocation protocols are what make heterogeneous systems incompatible. Most people assume that the incompatibility is caused by incompatibility of the platforms themselves (e.g., .NET or WebSphere). In reality, the vast majority of the .NET and WebLogic platforms have nothing whatsoever to do with remote method invocation.

There are only two "features" of the .NET and WebLogic platforms that prevent clients on one platform from communicating with components on the other. One is the mapping algorithm that the two surrogates use to map back and forth between byte arrays and method or return values. The second is the communications protocols used by the two surrogates to transfer those byte strings.

The momentum toward agreement in the industry as to both the mapping/unmapping algorithm and the transport protocol is building. The mapping/unmapping algorithm is called SOAP. SOAP originally stood for Simple Object Access Protocol, a rather odd acronym, given that SOAP is anything but simple, has nothing whatsoever to do with objects, and is not an access protocol. SOAP defines the standard mapping between component method requests and a very specific kind of byte array: XML strings. The communications protocol on which the industry has settled for moving the XML string from surrogate to surrogate is HTTP.

HTTP may seem like an odd choice for a communications protocol, given that it was originally intended (and is still largely used) to carry requests from browsers to Web servers for HTML pages. But HTTP requests and HTML pages are both just strings, like XML. Because HTTP is good at carrying strings, it was seen as a reasonable candidate for carrying SOAP requests and replies ”just another kind of string.

Two features of HTTP made it attractive as a likely SOAP communications protocol. One is the fact that it is widely supported by Web servers. The other is that most firewalls, the membranes protecting enterprises from the Internet, are configured to be HTTP permeable.

Ironically, neither the ubiquitous Web server HTTP support nor the firewall permeability has, as yet, turned out to be particularly useful to SOAP applications. The Web server support has fizzled because generally the servers that process standard HTTP requests are not the same as those that process SOAP/HTTP requests. The firewall permeability has fizzled because despite the industry propaganda, very few SOAP requests need to cross a firewall.

Why don't SOAP requests typically need to cross a firewall? SOAP/HTTP needs to cross a firewall when a request needs to cross the protective membrane of the enterprise. In other words, SOAP usually crosses a firewall only when it is being used for inter company collaboration (in which case, it will probably cross not just one, but two, firewalls).

In the real world, few companies are using SOAP/HTTP for intercompany collaboration. Most companies have a much more pressing need than intercompany collaboration ”that is, intra company collaboration. Intracompany collaboration is the business of the heterogeneous synchronous drawbridge. In my experience, this is the most important use of SOAP today ”not for allowing companies to talk together, but for allowing a company to talk to itself. The other use of SOAP, intercompany communication, is a topic that I will cover in Chapter 10 (Internet Fortresses).



Software Fortresses. Modeling Enterprise Architectures
Software Fortresses: Modeling Enterprise Architectures
ISBN: 0321166086
EAN: 2147483647
Year: 2003
Pages: 114

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