This book has focused largely on what you can do with CORBA today. But what about six months from now, or a year from now, or even further in the future? To plan for the systems you will build tomorrow, you want to know where CORBA is going to be at that time. This chapter looks at some proposed additions to CORBA and examines the overall direction CORBA is taking.
To predict where CORBA is heading, it is helpful to know some of its history. Recall from Day 1, "Getting Familiar with CORBA," that CORBA first materialized around 1990, shortly after the Object Management Group--CORBA's controlling organization--was founded. CORBA 1.0, followed shortly by CORBA 1.1, laid the groundwork for distri-buted object communication. In 1994, the OMG adopted the 2.0 version of the CORBA specification, the primary goal of which was to define a standard for interoperability for ORBs produced by different vendors. (Recall that an ORB, or Object Request Broker, is the component of CORBA that facilitates communication between objects.) CORBA 2.0 was a major step towards achieving interoperability between various products, but it still lacked some capabilities. Most notable was its inability to pass objects by value (as discussed on Day 10, "Learning About CORBA Design Issues"). Simultaneously, the OMG developed specifications for additional functionality in the form of CORBAservices and CORBAfacilities.
CORBA 2.1, adopted in September 1997, made some incremental changes to the CORBA specification:
None of these changes is earth-shattering, but the IDL extensions in particular bring CORBA up-to-date with respect to languages and operating systems that support 64-bit integer types and multi-byte character sets.
Coming up on the horizon is the CORBA 3.0 standard, the next major step in the evolution of CORBA. At the time of this writing, the OMG has not yet announced what capabilities and enhancements will be included in CORBA 3.0, but by taking a look at the current Requests For Proposals (RFPs) and Requests for Information (RFIs), you can make some reasonable guesses about what to expect in the next major iteration of the CORBA specification.
A knowledge of how the OMG operates is also helpful in predicting what CORBA 3.0 might include. The OMG includes two Technology Committees (TCs) that charter various Task Forces to solve particular problems. To this end, the Task Forces issue RFPs and RFIs to find potential solutions from the industry at large.
Currently, the Domain Technology Committee and the Platform Technology Committee have chartered a number of Task Forces that have current outstanding RFPs and RFIs. This section provides a brief overview of these Requests, which will probably drive much of the content of CORBA 3.0 when it is adopted.
The work performed by the Platform Technology Committee Task Forces is included in the CORBA specification itself at some point. For example, there are Task Forces to resolve issues of COM/CORBA interworking (recall that COM is Microsoft's Component Object Model), to create IDL mappings for various programming languages, and to propose additional features to CORBA. Currently, the Task Forces of the Platform Technology Committee include the Object Analysis and Design Task Force (OA&D TF) and the ORB/Object Services Task Force.
Most of the descriptions here are quoted directly from the OMG Web site. Details on the various Task Forces are available at http://www.omg.org/omg00/task.htm; details on the work in progress of the Technology Committees (as well as descriptions of the RFPs and RFIs themselves) are available at http://www.omg.org/library/schedule.htm.
According to the charter of the ORB and Object Services Platform Task Force, its mission is to solicit, evaluate, and select specifications for recommendations to the Platform Technology Committee for adoption by OMG in the areas of ORB technology (which falls under the CORBA specification) or general purpose Object Services (which fall under CORBAservices). Furthermore, the charter states that such specifications should be fundamental for developing useful CORBA-based applications composed of distributed objects, should provide a universal basis for application interoperability, or support higher level facilities and frameworks.
The current RFIs and RFPs issued by the ORB and Object Services Platform Task Force include the following:
The Object Analysis and Design Task Force's charter states that its mission is to enable developers to better understand how to develop applications using OT, thereby increasing the market; to recommend technology for adoption to enable interoperability across the life cycle of, and to enable reuse of, designs/work products developed using OA&D tools; to recommend technology for adoption of common semantics, metamodels, and abstract syntax for OA&D methodologies; to leverage existing OMG specifications; to facilitate advances in the state of the art of OA&D methodologies; and to recommend liaison with other appropriate organizations. Certainly this is a hefty responsibility to be taken on by the OMG's newest Task Force. Already this Task Force has generated two Requests for Proposals, involving a framework for analysis and design tools and a meta-object facility that would enable further interoperability between CORBA tools and applications.
The current RFPs generated by the Analysis and Design Platform Task Force include the following:
The work of the Domain Technology Committee comes to fruition in the form of CORBAfacilities, particularly in the vertical facilities such as health care, manufacturing, and telecommunications.
Currently, the Domain Technology Committee has chartered the following Task Forces:
(Note that many of the Task Forces composing the Domain Technology Committee are organized around vertical domains.)
Again referring to the OMG Web site, the mission of the Business Object Task Force is to define the domain of OMG Business Objects. It will work to facilitate and promote the use of OMG-distributed object technology for business systems; commonality among vertical domain task force standards; simplicity in building, using, and deploying business objects for application developers; interoperability between independently developed business objects; the adoption and use of common business object and application component standards; and issuance of requests and evaluation of responses and proposals for adoption by the OMG specifications for objects, frameworks, services, and architectures applicable to a wide range of businesses.
Certainly the role of the Business Object Domain Task Force is an important one. Because the purpose of most distributed enterprise-level applications is to facilitate the communication between business objects, the goals of the Business Object Domain Task Force have much in common with the goals of the distributed application developer: to enable the development and deployment of robust, interoperable business objects.
The current RFPs and RFIs issued by the Business Object Domain Task Force include the following:
The Manufacturing Domain Task Force, the successor to the Manufacturing Special Interest Group, has a mission to foster the emergence of cost-effective, timely, commercially available, and interoperable manufacturing domain software components through CORBA technology; to recommend technology for adoption that enables the interoperability and modularity of CORBA-based manufacturing domain software components; to encourage the development and use of CORBA-based manufacturing domain software components, thereby increasing the object technology market; to leverage existing OMG specifications; and to recommend liaison with other appropriate organizations in support of the preceding goals.
Current RFPs and RFIs generated by the Manufacturing Domain Task Force include the following:
Electronic commerce is a hot area of computing right now. Fueled particularly by the explosion of the World Wide Web phenomenon, many companies are looking for ways to sell their products through electronic channels and, just as important, to protect their copyrighted works and other intellectual property. The Electronic Commerce Domain Task Force was chartered to address the issues associated with electronic commerce.
The goals of the Electronic Commerce Domain Task Force are to garner Domain Technology support and involvement in OMG; to continue reliance on domain experts and issue RFPs; to seek broad industry and domain response to RFPs (where applicable); and to work toward outlining the scope of work for the Domain Task Force, including more specifically defining content management and rights and royalties, electronic payment, and online retail (electronic commerce).
The Electronic Commerce Domain Task Force has currently issued the following RFPs and RFIs:
The mission of the Telecommunications Domain Task Force is to issue RFIs and RFPs for CORBA-based technology relevant to the telecommunications industry; to evaluate RFI and RFP responses and RFCs for recommended adoption by the Domain Technology Committee; to communicate requirements from the telecommunications industry to the Architecture Board, the Platform Technology Committee, and other OMG subgroups, as appropriate; to assist and advise the Liaison Subcommittee regarding its relationship with telecommunications-related standards organizations and consortia; and to promote the use of OMG technologies as solutions to the needs of the telecommunications industry.
Currently, the Telecommunications Domain Task Force has generated the following RFPs and RFIs:
The mission of the Financial Domain Task Force, or CORBAfinancials, is to promote the use of financial services and accounting software that incorporate OMG standards; to provide an internationally recognized forum for industry focus on financial services and accounting facilities; to identify relevant standards, business architectures, research, and technologies in this area of computing; to coordinate end-user requirements in the financial services domain through a liaison with the End-User SIG; to facilitate advances in the state of the art of OA&D methodologies; to coordinate potential future specification activities with the Common Facilities Task Force, to involve all interested members of the OMG in the OMG Financial Domain Task Force; to create a CORBAfinancials architecture and road map for the financial services industry worldwide; to issue RFIs, RFPs, and RFCs for CORBA-based technology relevant to the financial services industry; to evaluate RFI and RFP responses and recommend technology adoption by the OMG's Domain Technical Committee; and to assist and advise the Liaison Subcommittee regarding its relationship with related standards organizations and consortia. (That's quite a mouthful!)
CORBAfinancials has currently generated the following RFPs and RFIs:
The CORBAmed Task Force is chartered with the following mission: to improve the quality of care and reduce costs by the use of CORBA technologies for interoperability throughout the global healthcare community; to utilize the OMG technology adoption process to standardize interfaces for healthcare objects; to communicate the requirements of the health- care industry to the Platform Technical Committee; and to assist and advise the Liaison Subcommittee regarding the relationship with healthcare standards organizations and consortia. CORBAmed also has the following goals: to educate both the system developers and the user community in the health care industry; to issue RFIs and RFPs related to the health care industry based on CORBA technologies; and to evaluate RFI and RFP responses and RFCs for recommended adoption by the Domain Technical Committee.
Currently, CORBAmed has issued the following RFPs and RFIs:
It is the mission of the Transportation Domain Task Force to promote the development and use of transportation-related systems that incorporate OMG specifications and technologies; to identify relevant standards, business objects, components, and technologies in the field of transportation, and to disseminate this information to the OMG; to work within the OMG committees and task forces to ensure that the CORBA, CORBAservices, CORBAfacilities, Business Object, and domain specifications are conducive to the needs of the transportation industry; to recruit additional Transportation DSIG membership from corporations in the transportation systems development community; and to establish a global forum for the free exchange of distributed object systems development ideas amongst the various members of the transportation community and its partners.
The Transportation Domain Task Force, one of the newest Task Forces in the OMG, has issued the following RFI:
Certainly the OMG is hard at work enhancing current specifications and creating new ones. But what does it all mean? In particular, who stands to benefit from the products of the various Technology Committees and Task Forces?
Again, as of the time of this writing, the OMG had not yet specified the contents, or even an availability date, of CORBA 3.0. Therefore, which of the specifications described here will be included in the next major CORBA release is anybody's guess. When these specifications do become available, however, all CORBA developers will be the winners.
The current Requests for Proposals and Requests for Information issued by the various Task Forces within the OMG give a good indication of where CORBA is heading in the near future. But what about beyond that? How will CORBA affect the development of distributed applications in the not-so-near future? And what challenges will it face? Although it is difficult to predict anything in the area of software development technology, this section addresses some of these questions.
Despite its current shortcomings, CORBA is nonetheless a very powerful development tool already. It still can stand to see some improvement, however, particularly in one area: So far, nobody has ever accused CORBA of being too easy to develop with.
Face it, CORBA's awesome power, plus its unmatched cross-platform and cross-language capabilities, come at a price. Developing for CORBA means learning to develop for yet another platform, as it were. The benefits that come with learning and applying this skill are immense, but in this age of rapid application development, emphasis is often placed on the speed of deployment of an application rather than on the power and robustness of a design. If CORBA is to continue to enjoy success as a development platform, it must learn to play in this world of instant software development.
Does this mean sacrificing CORBA's power, cross-platform capability, or robustness for ease of use? Of course not, although development tools could go a long way towards making CORBA application development easier on the developer. Already, such tools are starting to appear, and initiatives such as the ORB and Object Services Platform Task Force's Java to IDL RFP suggest that additional strides will be made towards making CORBA more seamless with application development.
The seamless concept will eventually be the key to CORBA's success. Although the use of some CORBA services, facilities, and the like will always require some developer knowledge, the developer should be insulated as much as possible from the plumbing of a CORBA application. Details of memory management, reference counting, and perhaps of IDL itself, should be handled by the development tools themselves, invisible to most developers. (Granted, a developer should still be able to drill down to this level of detail when desired, and a good development tool will always enable this level of interaction.) Freed from having to worry about the details of implementation, the developer can concentrate more on the design of the application itself.
In short, CORBA is already at the point where some very impressive things can be done with it. Additional features will push the usefulness of CORBA even farther, but to ensure CORBA's success, development tool vendors must provide tools that make CORBA application development easier than ever. (In the meantime, publishers are happy to bring to you such books as Sams' Teach Yourself CORBA in 14 Days!)
Despite the power and capability of the CORBA architecture and the Object Management Architecture surrounding it, CORBA still faces a number of challenges to its success. These challenges come in the form of competing technologies, or in the very process by which CORBA and related specifications are adopted. This section will briefly describe some of the challenges facing CORBA today.
Not surprisingly, CORBA is not without its competition. Although CORBA has the backing of almost the entire industry, including some very big players, its universal acceptance faces at least one major obstacle. This challenge comes in the form of another distributed object model from a vendor that enjoys an extremely dominant position in the industry. The vendor, of course, is none other than Microsoft, which is heavily pushing its Distributed Component Object Model (DCOM) as a de facto standard for a distributed computing platform.
Microsoft is quite clear regarding its position on CORBA, the open standard backed by just about every other player in the industry. Perhaps this position is best summed up in the words of COM Product Manager Cornelius Willis, as reported by InfoWorld Electric on August 18, 1997: "Of course, we want COM3--now known as COM+--to make CORBA irrelevant." (The original article is available at InfoWorld Electric's Web site at http://www.infoworld.com/cgi-bin/displayArchives.pl?970818.wsoft.htm.) Apparently, Microsoft prefers to extend its already expansive industry domination to include distributed computing standards as well, rather than support a widely accepted industry standard. To its credit, Microsoft has turned over parts of its COM, DCOM, and ActiveX technologies to The Open Group, an independent standards organization, and is partnering with Software AG to provide DCOM implementations on operating systems other than Windows. (More details are available at http://www.activex.org/ and http://www.softwareag.com/corporat/dcom/default.htm.)
Of course, Microsoft is welcome to compete in this space. If anything, competition will help to keep the OMG and CORBA product vendors on their toes, providing the best possible specifications, implementations, and interoperability they can. However, given the near ubiquity of Microsoft's operating systems--and, by extension, DCOM--backers of CORBA will be fighting an uphill battle against Microsoft's leveraging of one of its platforms to create another. However, there is hope--CORBA currently enjoys some advantages over DCOM, as outlined in an article available at the OMG Web site at http://www.omg.org/news/activex.htm. Another OMG article, a response to a report published by the UK-based analyst group Ovum, also provides some relevant information comparing CORBA and DCOM; the article is available at http://www.omg.org/news/pr97/ovumpr.htm.
Of course, there are other challenges facing CORBA as well. Consider, for example, the issues involved with managing an organization with more than 750 members. Granted, not all the OMG members vote on proposals, but the associated overhead is not insignificant. One of the OMG's greatest strengths--its strong backing by the industry--might also be one of its greatest weaknesses because the resulting bureaucracy can slow the development and acceptance of new specifications. The OMG has done exceptionally well so far, especially considering its size. With competition from Microsoft's DCOM, the OMG will need to take great care to ensure that the organization doesn't collapse under its own weight, possibly taking CORBA with it.
CORBA has already come a long way. With a membership of more than 750 and still growing, the OMG has definitely achieved a position of great relevance in the marketplace. CORBA as a standard has been growing and maturing for more than seven years now--an eternity in computer time. CORBA products are available on a wide variety of platforms and operating systems from dozens of vendors. (Among the platforms supported by CORBA are AS400, HP-UX, MacOS, MS-DOS, MVS, OpenVMS, OS/2, SunOS and Solaris, Windows 3.x, Windows 95, Windows NT, and many flavors of UNIX not already mentioned.) Clearly, CORBA has grown from its humble beginnings into an established, mature platform for distributed application development.
CORBA isn't done growing; new capabilities and enhancements are being added all the time. Today you've seen some of the enhancements currently proposed, from horizontal features such as a CORBA object model, support for various languages, and support for passing objects by value, to specifications for vertical facilities such as the healthcare, telecommunications, and manufacturing industries. The OMG has big plans for CORBA, and with the backing of a plethora of vendors producing CORBA products, these plans are being realized. CORBA has already become a powerful, robust platform for the development of distributed enterprise applications and is well on its way to becoming far more useful than it already is. In the future, not only will CORBA become even more powerful and robust, but it will also become more seamlessly integrated with application development. The future certainly has some exciting things in store for CORBA and its developers.
© Copyright, Macmillan Computer Publishing. All rights reserved.