Distributed Object Protocols

Object Technologies like Component Object Model (COM) and Common Object Request Broker Architecture (CORBA) brought organization to software development.   They also made the need to access the object instances in distributed environments obvious. Microsoft responded with DCOM, Object Management Group (OMG) responded with CORBA 2.0 that defines the Internet Inter-ORB Protocol (IIOP) standard.

Distributed environments have broadened in recent years from the intra-net to the Internet. This little change added a new challenge to distributed object technologies. The firewall became a hindrance to software engineers. Data that flowed freely across the intra-net just hit the wall, the firewall. You can see OMG’s identification of the crisis in 1999. http://www.omg.org/issues/firewall-rtf.open.html and a decade later the Data Distribution Service needs to be routed properly. http://www.omgwiki.org/dds/content/document/deploying-dds-wan-and-gig-dds-router

OMG has been trying to standardize on a solution – but it’s complex. AMQP offers routing as a fundamental part of the broker architecture. DDS instead emphasizes direct, fast data flow. Routing is not considered in the standard. AMQP structures communications as a publication to an exchange, routing between exchanges and queues. http://electronicdesign.com/embedded/what-s-difference-between-dds-and-amqp

There are many ways to get from point A to point B even when there’s a wall in between. Developing a custom proxy is a solution. Knocking a hole in the firewall is a solution. Tunneling through HTTP is a solution.

You can break your own firewall, but don’t expect your customers to break theirs so they can work with you. You can write a custom proxy that does anything you want if you have the time and development resources. Tunneling through HTTP seems to be the easiest solution.

The object technology evolution went from [Object] to [Distributed Object] to [Tunneled Distributed Object] as the environment went from [Single Machine] to [Network] to [Internet].

Tunneling DCOM

The firewall issues kept DCOM behind the wall and outside the gates.   Microsoft responded with a new protocol – Tunneling Transmission Control Protocol (TCP). Not to be confused with Transport Control Protocol (TCP). It requires Internet Information Server be installed on the server-side machine.

Tunneling CORBA

IIOP has had the same firewall struggles. Several ORB vendors now sell a firewall that specifically allows IIOP requests to pass through (Visigenic’s Gatekeeper, Orbix WonderWall). Although CORBA is an “Open Standard”, cross vendor incompatibilities are a well-known problem that plagues the CORBA technology. Add to that now a vendor specific firewall and the incompatibilities will snowball since any ORB vendor will have the ability to make their firewall work best with their ORB.

Industry Consensus

It’s clear that Microsoft and the ORB vendors are trying to solve the same problem, but there is no industry consensus on how the distributed object technologies should get over, around, or through the firewall.

When distributed objects persist to and from streams of XML, the information can be easily tunneled through HTTP. The ORB vendors have correctly identified the need for more intelligence to be programmed into the firewall, but rather than replacing everybody’s firewall (or if you’re Microsoft – their web server) just tunnel through port 80 and pass through a standardized validator in the server.  Tunneling XML through HTTP is completely compatible with every firewall on the market today. There will be no need to use an ORB vendors firewall. This will be a great leap forward for distributed object technologies.

Object state is easy to model in XML. Take for example a simple Customer object:

<Customer ObjectID=’1’>

<FirstName>Bob</ FirstName>

<LastName>Smith</ LastName>

<Address ObjectID =’2’>

<Street>123 Elm</Street>

<Zip>94509</Zip>

</Address>

</Customer>

Likewise method calls are easy to model in XML:

<Invoke object=’Customer’ method=’GetOrders’ oid=’1234567890’>      <start-date>20000418</start-date> </Invoke>

Tunneling DCOM or CORBA through XML

The Proxy or Client Application sends everything marked up in XML with an HTTP Content-Type: text/xml header over port 80 or 443. Any firewall allows the POST to pass through to the stub. The stub is then implemented in CGI or ISAPI and executed by any web server. The Stub can also be implemented as an HTTP fluent socket server so that a web server is not necessary. Once the request has been handed to the stub it is processed like any normal IIOP or DCOM server process requests today.

Now we have a whole new foundation to the Distributed Object Technology. The POST content of type “text/xml” can now be passed through an authentication layer that validates the XML document structure and Get/Invoke security permissions. This “authentication layer” can discriminate access based on the invoking users authority to access specific Objects or methods.

So What’s New

Nothing presented so far is any new industry technology. It simply uses XML as the object markup that tunnels through HTTP to the stub.   It solves the firewall problem, but then the industry is back to where it started right? It will have a distributed object technology that works. – ( now even even with firewalls) Fortunately we get even more benefit. Now that we use a human readable markup over the wire, naturally that is a useful piece of data to have each object expose through a standard accessor.

This creates a new architectural option for client implementation. Refer to Figure A and notice that the proxy can be bypassed by the client application.   In a traditional DCOM or CORBA based system the proxy cannot practically be bypassed since the marshalling must happen somewhere. The binary data over the wire is of no use to any software except the client side proxy for which it was intended.

Using XML as the object transport protocol – many client side consumers other than the proxy have an interest in receiving the raw XML that was intended for proxy. If the client is directly a consumer of XML then a proxy is optional.

Proxy-less Implementation using DTD as IDL

Interface Definition Language (IDL) is the “inter-component contract” in a traditional distributed object based system. Since we chose to tunnel XML through HTTP, the server interface can be completely described in DTD. Anything from a custom sockets application to a browser can directly communicate to the server side stub by POSTing valid XML. Any company can ‘publish’ portions of the DTD that describe the public interface. DTD can model an IDL interface.

Thin Client

A thin client may begin navigating the object model with a list of Customer objects. This is simply a POST to execute a method. The Browser can directly handle the response from the POST.   Said again, the browser can POST directly to the server side stub. No Proxy needs to marshal the response since the browser is perfectly capable of handling raw XML. You can’t do that with IIOP.

The XML returned from the server is displayed with an XSL Stylesheet. Each Customer is then displayed in a list in the browser. Each customer in the list is a hyperlink that POSTs a method call to drill down for more information on that customer. In this way, the browser makes the POST. (Work typically done by a Proxy in DCOM/CORBA systems). Using XSL to render the user interface, we have the ability to navigate the object model with a web browser.

Thin-Thick Client Combination

The thin client has an inherent functionality limitation. The loss of presentation flexibility often outweighs the gain of simple enhancements in a dynamic presentation rendering system. A fat client is the best choice for a top-notch user interface or complex client side processing. In fat client systems, generally some portion of the application can be implemented as a ‘thin client’. Reports (i.e. Monthly summaries) or business documents (i.e. Invoice, receipt) are often pieces of a fat client that can be implemented as a traditional ‘thin client’.

The fat client application just spawns an instance of a browser that POSTs the correct XML request for the object state in XML. The response is then piped into the browser with an XSL stylesheet.

The Bridge

Bridging DCOM and CORBA is not so much a technical problem as a political problem. Implementing the Server Stub as a CGI binary, and switching the protocol to XML can be done without waiting on OMG or Microsoft. Just have every interface object derive multiply from your own common base class in addition to its stub marshalling base class created by the IDL compiler. Your common base class can follow the standard “Serializer Design Patterns” and enable the implementation object to serialize state to and from XML. You may also find a good implementation already done for you.

class CustomerImpl : public virtual CustomerBOAImpl, public virtual XMLObject {};

The Golden Gate

Native, Cross Operating System, Cross Language — Distributed Object Computing.

 © 2015 United Business Technologies, Inc. All Rights Reserved.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s