| Lesson 2 | Distributed object middleware |
| Objective | Describe distributed object middleware. |
What is Distributed Object Middleware?
Distributed object middleware enables the deployment and management of
CORBA[1] and/or COM[2] objects across architectures. Also known as ORBs[3] or Object Wrappers[4], these products support the development of complex transactional systems.
For example, when an e-Commerce solution requires multi-phase commit logic of disconnected transactional systems that are each based on different object models, the architect may want to use distributed object middleware. Let's say a Web-based customer service application developed in Java and running on Windows and needs to interoperate with an order management system developed in C++[5] running on Solaris inside of an Intranet. Object middleware could be used to synchronize the transactional commit process between both systems (that is, customer service users should be able to override and alter orders based on customers' wishes). Object middleware allows the objects from both applications to interoperate and share functions, even though the objects were built in different languages, run on different operating systems, and are housed in different network domains.
For example, when an e-Commerce solution requires multi-phase commit logic of disconnected transactional systems that are each based on different object models, the architect may want to use distributed object middleware. Let's say a Web-based customer service application developed in Java and running on Windows and needs to interoperate with an order management system developed in C++[5] running on Solaris inside of an Intranet. Object middleware could be used to synchronize the transactional commit process between both systems (that is, customer service users should be able to override and alter orders based on customers' wishes). Object middleware allows the objects from both applications to interoperate and share functions, even though the objects were built in different languages, run on different operating systems, and are housed in different network domains.
Distributed Object Middleware Considerations, Existing Components and Object Standards
Do not underestimate the complexity of distributed object solutions. Despite attempts of vendors to hide the complex plumbing underlying distributed object processing, it remains one of the most difficult technologies to develop, deploy, and tune. Many object request broker (ORB)[6] based applications also take a heavy toll in terms of computing resources. Adopters of this type of middleware will trade flexibility and application power for a drain on machine and human resources. The expertise base in distributed object technology is slim and high-priced.
To date, the majority of distributed object-based solutions designs have typically involved mission-critical applications. Many early adopting corporations have developed very sophisticated applications based on distributed object designs. The architect should judge the buyer. The mainstream adopter and the laggard are probably not going to enjoy a project based on distributed objects at this time. Perhaps in a few years, when distributed object technology becomes easier to develop and manage, mainstream buyers will enjoy a greater level of comfort and success with distributed objects. Though relatively few e-Commerce solutions make active use of distributed objects, plenty of e-Commerce solutions take advantage of component and object standards (Enterprise JavaBeans[7] and COM[8] objects) which could be used in distributed object solutions. Nonetheless, the design challenge for distributed object solutions remains an order of magnitude beyond basic component-based application designs.
To date, the majority of distributed object-based solutions designs have typically involved mission-critical applications. Many early adopting corporations have developed very sophisticated applications based on distributed object designs. The architect should judge the buyer. The mainstream adopter and the laggard are probably not going to enjoy a project based on distributed objects at this time. Perhaps in a few years, when distributed object technology becomes easier to develop and manage, mainstream buyers will enjoy a greater level of comfort and success with distributed objects. Though relatively few e-Commerce solutions make active use of distributed objects, plenty of e-Commerce solutions take advantage of component and object standards (Enterprise JavaBeans[7] and COM[8] objects) which could be used in distributed object solutions. Nonetheless, the design challenge for distributed object solutions remains an order of magnitude beyond basic component-based application designs.
Distributed Object Middleware Vendors and Tools
- IONA's Orbix: Much of the slack created by the Inprise purchase of Visibroker has been taken up by IONA, an Ireland-based software company. Many think that IONA has been overwhelmed in terms of supplying engineering support due to its newfound role as the most widely distributed independent ORB. Nonetheless, Orbix is probably the most widely used and licensed independent ORB in the market at this time.
- Object ERA's JBroker: JBroker was emerging as a popular Java-specific object request broker. Its performance is considered top of the line. Recently, however, ObjectERA was acquired by application server vendor SilverStream. Though SilverStream plans to sell JBroker as an individual ORB, JBroker's tight ties to the SilverStream product may relegate it to a fate similar to Visibroker's. Other important commercial ORBs and Object Wrappers include:
Inprise's Visibroker is no longer operating as a CORBA vendor. Here's what happened:
- Inprise acquired Visibroker in 1998** from Visigenic, making it a major player in the CORBA market.
- In 2003, Inprise was acquired by Borland.
- In 2006, Borland sold the Visibroker product line to OpenWave Messaging** (later acquired by InterDigital).
- InterDigital discontinued support for Visibroker in 2014,** effectively ending its operation as a CORBA vendor.
Therefore, while Visibroker was once a prominent option, it is no longer actively maintained or supported. If you're currently using Visibroker, you should consider migrating to alternative CORBA implementations or exploring different technologies altogether.
Here are some alternative CORBA implementations you might consider:
- TAO (The Adaptive Communication Environment): Open-source, widely used, and actively maintained.
- OmniORB: Open-source, lightweight, and easy to deploy.
- ORBacus: Commercial option with broader platform support and extended features.
Ultimately, the best option for you will depend on your specific needs and requirements.
Verify your understanding of the concepts we have covered with a self-check quiz.
This quiz will provide you with valuable practice prior to taking the end of course test.
Object Middleware - Quiz
This quiz will provide you with valuable practice prior to taking the end of course test.
Object Middleware - Quiz
[1]Common Object Request Broker Architecture (CORBA):
Enables pieces of programs, called objects, to communicate with one another regardless of what operating system they are running on or what programming language they were written in. To learn more about Corba visit Corba Fundamentals
[2]
Component Object Model (COM): Microsoft's language independent component architecture intended to provide general purpose, object oriented means to encapsulate commonly used features and functions.
[3]
Object Request Broker (ORB): A program that controls communication between clients and objects on servers.
[4]
Object Wrapper: Object wrappers control communication between clients and objects on a server. They allow heterogeneous object environments to interoperate with or without a request broker.
[5]
C++: A high level programming language primarily used for graphical applications.
[6]
Object Request Broker (ORB): A program that controls communication between clients and objects on servers.
[7]
Enterprise JavaBeans (EJB): Define how Java objects interact with other objects. It is actually possible to develop Enterprise JavaBeans in other languages, but they must be translated into Java byte codes, and organized as a EJB component. The EJB is executed within the context of a J2EE or J2SE virtual machine.
[8]
Component Object Model (COM): Microsoft's language independent component architecture intended to provide general purpose, object oriented means to encapsulate commonly used features and functions.