Musing Over TP Monitors
CORBA communes with enterprise computing.
Frank Teti
Director and Principal Architect at Cambridge Technology Partners, Conshohocken, PA.Historically, the Object Management Group's (OMG) CORBA specification has emphasizedmessaging, as well as event and location services, but Transaction Processing (TP)services were little more than broad, complex specifications. Recent advances in CORBA TPMonitor support, however have enabled CORBA for enterprise-wide business computing.
I recently landed at a Wall Street firm that wanted to rapidly build an n-tier solutionto enable them to trade electronically with an external site brokerage. My client hadexpectations of rapidly deploying what they considered tactical, external, third-partynetworks.
Being a good consultant, I asked, "Why n-tier?" After all, the client-servermodel with its fat client and its GUI tools was at least as high a productivityprogramming environment; efficient enough for tactical solutions. However, in a two-tierapplication, to connect with a site outside the firewall, an IP route map from the clientworkstation to the firewall has to be configured. And then on to the external sitedirectly. But that went against my client's Internet policy.
Thus, the firm could be compromised. And when the minimum transaction size is a milliondollars, security becomes an essential requirement. Using an n-tier architecture, anapplication server integrates with the external site, and therefore, only the applicationserver needs to be routed directly to the firewall (see n-tier architecture diagram).
Other reasons for using n-tier, such as the workstation footprint, applicationdeployment and multiplexing connections, were also considered, but deemed to be ofsecondary interest. For example, the footprint (the free memory and disk space on thetrader's workstation), with presentation services would be much smaller using n-tier thana two-tiered application. And, the CPU utilization of additional applications on UNIXworkstations with 128MB of memory is nominal.
Actually, from a presentation services perspective, getting real estate on a trader'sterminal is a greater accomplishment. Most traders have 2-to-n terminals for marketwatching and with the brave new world of electronic trading, the trader can now perform ahit, take, bid, or offer himself with an external site, instead of using a "voicebroker."
Application deployment, including version control and configuration with a simplepresentation layer application on the trader's desktop is clearly less complicated.Database and other application shared object libraries can reside server-side. And atwo-tiered solution preempts the possibility of multiplexing connections to the externalsites in order to reduce redundant market data throughput and connection handles.
For example, instead of each trader connecting and subscribing to receive marketinformation on a 30 -year T-Bill and getting an individual notification message pushedfrom the external site, a single supplier process could connect and subscribe to themarket and push messages to an event channel, which acts like a conduit for one or morerelated events, which, in turn pushes notifications to the individual traders. That is theOMG Event Service model, or alternatively known as an Asynchronous Callback Model.
As a UNIX shop, DCOM, which is a native Windows NT distributed solution, wasn't acredible option. Although there were also development organizations within the firm usingthe Distributed Computing Environment (DCE), its reputation as hard to administer andhaving long development lead times made them stay with deploying n-tier solutions usingsockets (see DCE R.I.P.).
For this firm, DCE did not deliver on being a better solution to distributed computingthan sockets. In my opinion, based on the business case and requirements, I now needed tojustify why n-tier CORBA was the right solution, instead of treating it as a my own defacto standard.
CORBA, essentially, is like a 4GL for socket programming -- an n-tier programmingproductivity tool. And, it's important to note that underneath all of these"services" there is still sockets and socket level programming and filedescriptors among other details. These are just handled by the Object Request Broker(ORB). For example, a CORBA server connection is a file descriptor. And it will takedecades before development of operating systems can move away from C and sockets as theunderlying programming API.
For business applications, much of the programming effort within n-tier environmentsinvolves marshaling (the ORB converts a request or a reply into a form that can betransferred across a network) and unmarshaling data (changing the data that passed acrossthe network back into a form that the local machine understands).
In a CORBA environment, complex data types can be used for packaging data, such assequences and objects, which allows the programmer to focus on the business transaction,not the low-level implementation details as is the case with socket programming.
While DCE with its conformant array (a complex data structure used for passing largedata sets across the network) represented a true technological advance over the streamsocket (see Socket Man sidebar), the CORBA sequence type with its Interface DefinitionLanguage (IDL) generated var and ptr classes is a superior technology. The var classperforms automatic memory cleaning as opposed to conformant arrays, which require theprogrammer to allocate and de-allocate memory. In addition, these classes have methods andoverloaded operators built in for easy data manipulation.
Other reasons for CORBA include: well defined server location services, built-inrecovery mechanisms, functionally rich IDL language with powerful CORBA data types,exception handling that allows messages to be thrown across the network (not justenumerated types as is the case with DCE), a well defined Event Service, support forasynchronous function member invocation and callbacks and now transactional services.
Given the demanding requirements for trading systems, this type of functionality, whichis delivered by most ORB vendors, at least gives a development organization a fightingchance to rapidly deploy tactical n-tier solutions.
SOCKET MANA transport level byte stream socket provides for the connection-based, bi-directional,reliable, sequenced and unduplicated flow of data without record boundaries. The read()and write() functions are used to do this, just as they are for normal files. The simplefunction below to read a given number of characters into a buffer demonstrates thelow-level nature of socket programming. While this is a robust mechanism for marshalingdata it is not a highly productive environment.
int read_data(s,buf,n)
int s; /* connected socket */
char *buf; /* pointer to the buffer */
int n; /* number of characters (bytes) we want */
{ int bcount, /* counts bytes read */
br; /* bytes read this pass */
bcount= 0;
br= 0;
while (bcount < n) { /* loop until full buffer */
if ((br= read(s,buf,n-bcount)) > 0) {
bcount += br; /* increment byte counter */
buf += br; /* move buffer ptr for next read */
}
if (br < 0) /* signal an error to the caller */
return(-1);
}
return(bcount);
}
n-tier Architecture 
Representative CORBA architecture using Inprise's VisiBroker. Note: The workstation
(CORBA Java Client) is not directly exposed to the firewall. The external client site
only knows about the IP address of the Application Server.
|