Articles Forum Examples Download Tutorial
Oct 17, 2007
Copyright(c) 2007 by Pocomatic Software. All Rights Reserved.
Handcrafting a large scale distributed application from scratch is hard, expensive, risky, and bound for heavy maintenance headaches. The goal of the CORBA architecture was to reduce these pains by factoring out reusable low level functions/services in order for application developers to focus on high level business logic and domain issues.
With a CORBA middleware, an iteration cycle in developing a distributed application can be divided into the following three sequential phases:
System partition and interfaces design: In this phase, architects/developers partition the application into business logic units (modules and objects) and define their interfaces using the OMG IDL[1].
Implement business logic: In this phase, developers write business logic implementations for the partitioned units. These implementations support all operations of their respective IDL interfaces.
Deployment and configuration (D&C): In this phase, developers assemble individual business logic units together and/or enlist them to the underlying ORB runtime and/or CORBA common services (such as OMG Event/Notification and DDS) with desired policy or QoS configuration settings.
CORBA indeed simplified the first two phases of this development iterate cycle by making distributed applications similar to conventional well understood non-distributed OO applications. However, CORBA also brought in considerable framework level complexities and is far from satisfactory on simplifying the third phase. The programming models (APIs) of ORB server (such as the POA API) and most common services, such as Event/Notification and DDS, are heavily system or framework oriented and are awfully complex to most domain/business application developers and even cumbersome to most system application developers and middleware experts as well as ORB and OMG common services implementers themselves.
This situation[2] calls for a component framework that could substantially simplify CORBA applications for domain users whose skills and interests are not low level middleware plumbing but solving high level domain issues and building sophisticated and/or intelligent business applications. This framework should even allow domain users with little programming skill to quickly, comfortably, and flexibly assemble, deploy, and configure sophisticated CORBA applications.
The CORBA Component Model (CCM) was an attempted solution to address above issues. However, CCM turns out to be more trouble than it's worth.
Firstly, CCM significantly increased the complexity of all three phases of the CORBA application development cycle with much more contrived framework complexities and imposed a steep learning curve even for CORBA experts, not to mention the dreadful entry barrier for business application developers.
Secondly, CCM dictates an invasive component model and therefore introduces a compliance barrier that not only tightly locks in compliant component implementations, but also locks out almost all existing CORBA business logic implementations (servants) and even certain client applications[3] and important OMG common services. To be reusable in CCM, these CORBA application implementations and common services have to be refactored or even completely redefined and reimplemented. All of these largely defeat the very purpose of having this component framework.
For instance, numerous scholastic publications claimed that CCM greatly reduced lines of code of OMG Event/Notification Service applications. Nevertheless, as a matter of fact, the “Events as Valuetypes of IdL” (EVIL) model of CCM not only forces developers to write more rather than less plumbing code[4], but also rules out most existing Event/Notification Service implementations[5] and almost all already deployed, standard based Event/Notification Service applications[6]. These standards/specifications and their service and application implementations had to be significantly rewritten to be compliant to and interoperable with the CCM EVIL. Even if additional plumbing code and such a massive reengineering exercise were acceptable, it would still incur considerable performance overhead and significant network bandwidth penalty due to the EVIL model requires valuetypes representing complex events/alarms to be inserted into and transferred as CORBA::Anys.
CCM was largely influenced by techniques developed during later 90’s in the Apache Avalon project and EJB 1.0. These techniques have been abandoned in the mainstream industry for years and the EJB 1.x/2.x has become a classic negative example of architecture design. Nevertheless, taking either an ostrich attitude or a “if you can’t convince them (users), confuse them!” tactic, CCM is still constantly being hyped with buzzwords such as “advanced”, “mission-critical”, and “lightweight”, even though its techniques are out-of-date, its implementations are vulnerable and heavy. Whenever being criticized for its heaviness and complexity, CCM always responses with its favorite equation claiming that advanced component frameworks for distributed mission-critical applications deserve to be heavy, complex, recondite, and hard to use. Their simplifications could only yield less featured inferior editions.
PocoCapsule/C++ CORBA+DDS framework overturns the above CCM’s equation definitely in the “David vs Goliath” face-off. It reiterates the classic "less is more" aphorism by demonstrating an intuitive, easy to use, and lightweight while substantially powerful and reliable component framework for CORBA applications. This framework comes with the following features out-of-the-box:
The detail descriptions of these features are presented in user/developer guide and out-of-the-box examples. For quick start on PocoCapsule/CORBA, see the tutorial document Getting Started with PocoCapsule/CORBA Component Framework.
PocoCapsule/C++ for CORBA+DDS framework is a component and modeling framework built on top of the PocoCapsule/C++ inversion of control (IoC) (also known as dependency injection) and domain specific modeling (DSM) framework. Therefore, unlike CCM, PocoCapsule/C++ for CORBA does not dictate a non-portable component model but accepts virtually any C++ objects, referred to as plain old C++ objects (POCO), as components and is therefore neutral to all component models. Business logic object implementations and common services that were designed, developed, and built with or without knowledge of PocoCapsule/CORBA framework can all be seamlessly used and manipulated as components by PocoCapsule/CORBA and can still be tested and reused in their respective frameworks without PocoCapsule as well. These components include, for instance, existing CORBA 2.x business logic implementations (servants), CORBA 3.x and CCM components, JTRS-SCA core framework (CF) resources and devices, OMG-RTC components, and existing and new OMG common services such as OMG Event/Notification Service and DDS and their application object implementations (consumers, suppliers, data readers and writers). This POCO component model implies:
There is no compliance barrier. Legacy implementations are seamlessly supported.
There is no ramp up time and no learning curve[7] for another contrived component model.
The straightforwardness of design and implementation phases of CORBA 2.x application development is retained.
Existing and matured asserts (various vertical domain standards and implementations of ORBs, OMG common services, and applications) and investments (trainings) can mostly be preserved and are reusable explicitly with minimum cost, impact, uncertainty, and risk.
For the third development phase, the declarative assembly and deployment model of PocoCapsule/CORBA largely melts away plumbing complexities and eliminates the need for domain/business application developers to deal with or even to learn those low level system details. Many CORBA application scenarios and common services used to be notoriously obscure to CORBA experts and dreadful obstacles to CCM. Now, with PocoCapsule, these scenarios become fairly obvious and handy even to CORBA novices.
Back to the PocoCapsule articles page
This page has been visited:
| free hit counter html code |
[1] In MDA, developers could use UML as modeling language and generate CORBA IDL using tools.
[2] This is a generic situation, also observed in J2EE, WebServices, high performance computing (HPC), robotic motion control applications, or vertically in enterprise (EAI, ERP), healthcare (HL7, EHR/HISA), intelligent traffic and/or vehicle control systems (ITS), datacom and telecom (TMN, IN/AIN, Parlay/OSA, SIP, VoIP, and NMS/OSS/BSS), defense (SDR, ATC, C4I, JBI, and OACE).
[3] For instance, in some CCM implementations, it becomes very difficult to develop OMG asynchronous method invocation (AMI) client applications to access a CCM server.
[4] For instance, event valuetype factories, factory registration, and double dispatch.
[5] Among a handful (more than 6) Event/Notification Service implementation only one (VisiNotify) is able to support interoperable valuetype pass-through without non-portable vendor specific workaround (such as link or load user application specific valuetype factory into the channel executable).
[6] Examples of such applications include, for instance, almost all CORBA/TMN applications based on 3GPP, TMF and ITU-T standards/specifications.
[7] A CORBA, CCM and COS services (Naming and Event/Notification) training course offered by one CCM advocate requires 15 weeks. In comparison, it needs less than 15 hours for a CORBA novice to be able to master mach more features in PocoCapsule/CORBA.