More CORBA Articles
CORBA Overview | CORBA Internet Sites | CORBA Books | CORBA Articles |
Record: 32
Title: | Sneaking up on cobra. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Focuses on products targeting the Common Object Request Broker Architecture (CORBA). Microsoft's development of the Component Object Model (COM) and the Distributed COM; Sun's development of the EJB; Necessity for vendors to sell complete products and development tools applicable to all network architectures, infrastructure and operating systems; Expected merger of CORBA and EJB. INSETS: Executive summary. |
AN: | 1832745 |
ISSN: | 1046-4468 |
Database: | Academic Search Elite |
SNEAKING UP ON COBRA
The most elegant component model in the world is useless without products to support it. By the same token, the most well-designed architecture is hamstrung without powerful yet flexible and usable tools with which to implement realworld solutions. These conundrums are influencing the future of the three prevailing models for using and managing distributed objects in a network: CORBA, DCOM and Enterprise JavaBeans.
Although the Object Management Group's CORBA (Common Object Request Broker Architecture) has existed since 1990 and many products support it on some level, it has long been criticized as being too low-level for anyone but highly specialized engineers to use. Microsoft Corp.'s model, which includes COM (Component Object Model), DCOM (Distributed COM) and the upcoming COM+, has a huge installed base and is more mature than Sun's nascent EJB; but while COM and DCOM have a fairly healthy third-party market for tools, they still primarily require users to run Microsoft tools on Microsoft platforms. Meanwhile, despite the fact that relatively few development tools are currently available for Sun's EJB, it has generated strong interest both from vendors and the market. If that interest turns into robust tool sets and truly interoperable, cross-platform products from multiple vendors, it will become a major force to reckon with.
Customers understand the message of object orientation and its benefits, as well as the need for a distributed object technology, says Roseanna Marchetti, senior product marketing manager at Netscape Communications Corp., so vendors don't need to sell the benefits of components. Rather, they must sell complete products and development tools that are easy to implement, use and reuse across whatever network architecture, infrastructure and OS their clients use. Here, CORBA faces its biggest hurdle. The technology proved too difficult to use in many instances, and too complex and expensive to implement and maintain. Although parts of its core technologies undoubtedly will remain vital to many distributed object deployments, and many products will continue to support CORBA in some form, it has likely hit its high-water mark as a separate, integrated model.
By comparison,'Microsoft provided a relatively easy-to-use alternative with DCOM and Microsoft Transaction Server (MTS), and has quickly gained a large share of the market, if not of the revenue; after all, Microsoft delivers the service free, as a part of the Windows NT OS. It remains to be seen if EJB, or a merger of EJB and CORBA, can overcome Microsoft's lead.
CORBA; Merge Ahead!
CORBA is in an interesting, but not necessarily good, place right now. On the one hand, it has a large, committed installed base and a diverse group of vendors that participate in the Object Management Group (OMG). CORBA has been available for much longer than DOOM or EJB (its original specification was released in 1990 and commercial products began appearing in 1992), and many products on the market support it. CORBA objects can be written in multiple languages, including Java, C, C++, SmallTalk, COBOL and Ada. The OMG has just announced version 3.0 of the CORBA specification, which is expected to be released in final form by midyear. This version will include some important additions, such as a new, expanded distributed component model, a scripting language and the ability to pass CORBA/IIOP (Internet Inter-ORB Protocol) through a firewall. If a client supports IIOP connections directly, new interfaces will allow a CORBA 3-compliant firewall proxy to be used on the provider's firewall proxy host, with bidirectional filtering and proxy services. If the client doesn't support IIOP, the fallback is tunneling the IIOP requests through HTTP.
On the other hand, it's been nearly impossible to create connectivity among different vendors' products. Implementing anything substantial has required a great deal of low-level coding by highly skilled staff. It is possible to create large-scale distributed systems using CORBA across heterogeneous hosts and OSes, but the investment in time and talent is huge. Many of the CORBA 3.0 specification's services are already functionally part of the DOOM or EJB specs, and while many vendors support CORBA, enthusiasm for it has been been largely eclipsed by EJB. There's no guarantee that the full 3.0 spec will be widely implemented; it's likely a case of too little, too late. We believe that at least for new system development, EJB (with essential elements of CORBA) and DOOM will soon be the two major distributed object standards in widespread use.
IONA Corp., one of the biggest CORBA boosters, recently purchased an EJB development company, and Netscape, though it supports CORBA clients, does not offer a CORBA server, per se. Rather, according to Komal Parikh, a group project manager at Netscape, the company is looking to Sun to help solidify the relationship between CORBA and EJB. Sun is unlikely to offer pure CORBA services; rather, it's pushing for greater integration between EJB and CORBA.
That's a refrain being heard throughout the industry--that CORBA and EJB are headed for a de facto merger, with elements of CORBA absorbed into the EJB specification. This will be a very fruitful marriage, if Sun and the OMG can avoid a bifurcation. The CORBA 3.0 specification includes some features designed to enhance CORBA-Java interoperability, especially support for Objects-by-Value. The extension of CORBA support to value objects is essential to enable developers to generate CORBA IDL (Interface Definition Language) files from Java-class files, and therefore to allow access to Java applications remotely under CORBA via RMI (Remote Method Invocation), using IIOP as the wire protocol (as Java is extended to make use of HOP).
The CORBA specification's vagueness has always been its major problem, as it allowed vendors to come up with widely varying, incompatible products with limited or no service-level interoperability. Microsoft plays up this weakness in its marketing, saying DCOM presents a more consistent specification and environment than CORBA. Sun is trying to keep a close eye on EJB's cross-vendor interoperability; while EJB is portable, it remains to be seen whether Sun will be able to avoid some of CORBA's intervendor confusion and difficulties. Most enterprise deployments of CORBA are designed primarily to tie together diverse data sources, and most can fairly easily standardize on one vendor. However, that's likely to change as components become commoditized and 'plug and play' becomes a larger issue for IT shops. To do a better job than OMG at cross-vendor compatibility, Sun will need a tight spec, a complete reference implementation and a strong certification process.
CORBA's future as a technology distinct from Java will further dim as many vendors merely assure interoperability with existing "legacy" CORBA assets. However, CORBA/IIOP will almost certainly remain a popular wire protocol for accessing Java components using RMI, and CORBA ORBs will be an essential part of that service; meanwhile, CORBA's IDL and OTS (Object Transaction Service) may well continue to be used, especially in conjunction with Java. CORBA has a loyal base of users in the enterprise, a fair number of success stories and some level of participation from a large number of vendors. Until the advent of EJB, it has been the only standardized cross-platform object model that has had any significant support. However, looking into the future, even shops with a large CORBA investment likely will start to wrapper their existing CORBA code and do new development with either DCOM or EJB. As for much of the remainder of the new CORBA specification, it's doubtful whether many dancers will remain at the CORBA ball.
Microsoft: Poised for COMbat
Microsoft's DCOM has both the advantages and disadvantages of being pushed by a single vendor. There's no "design by consortium," as there is with CORBA, nor even the process of working with "friends and family" that Sun has with EJB. Microsoft can consult with customers, and then implement whatever features and changes it wants. Because DCOM is a part of Windows, Microsoft instantly has hundreds of millions of potential users.
Microsoft has virtually complete control over its specification and implementations, as opposed to either Sun or the OMG. This tends to make DCOM a fairly coherent model in actual use, but also one that's limited to running in Microsoft environments. For instance, one of the most critical pieces of a distributed object model for enterprise use is robust transaction processing. In the DCOM world, that's accomplished via MTS, which runs on NT. Period. On the other hand, eliminating cross-platform interoperability avoids a host of problems.
Microsoft's control of the OS means that, at least on Windows NT servers, OS integration with DCOM is excellent. And in fact, in Windows 2000, COM+, the evolutionary successor to the current COM model, will both add some new services and subsume what had previously been discrete (though bundled) products, such as MTS. Furthermore, the DCOM infrastructure and MTS-COM+ services are distributed at no additional cost over the base OS, unlike products that use CORBA or EJB. David Chappell, an industry analyst and principal at Chappell and Associates, puts it bluntly: "The decision about which component model to use is based on which OS you want to build your server-side business logic. If a Microsoft OS is your choice across the board, use DCOM and MTS. If you don't want to use NT, you can't use MTS and DCOM."
Some NT shops won't find the choice so cut and dried; there will always be reasons to purchase or develop enterprise-level products that use CORBA and/or EJB, such as the need for extremely robust failover and dynamic load-balancing services across LANs and WANs--services that NT by itself either lacks or provides in only a limited capacity. The point about OS choice, however, is an excellent one: DCOM is based upon the assumption that all of a business' new development and business logic will be on NT, probably using MTS. And while Microsoft may be hoping for a future where that's true, most shops still support multiple OSes and platforms, not only for "legacy" data and applications, but for new applications as well, and will continue to do so for the foreseeable future. Microsoft has made a good effort to port COM to various other platforms--namely, Digital Equipment's OpenVMS, IBM Corp.'s MVS, and Unix for Hewlett-Packard Co., Digital, Silicon Graphics and Sun boxes. But this is primarily to ensure access to COM-wrappered "legacy" data sources; there are no plans to port the critical MTS piece to anything but NT, and COM+ is also intended to be a Windows-only offering.
The trade-offs to using DCOM and MTS are familiar ones: You gain a solid, consistent environment, mature development tools, and a distributed component model supported by a huge installed base. On the downside, you lock yourself into a relationship with a single vendor, Microsoft. Despite the company's recent support for "COM on Unix," you can rest assured that support for Unix will always be minimal to induce companies to migrate to Windows-based servers. Microsoft representatives have repeatedly stated that they have no interest in making Unix a stronger platform.
The subject of development tools is laced with pros and cons. Microsoft has spent considerable effort integrating its tool offerings (Visual Studio 6, for example) to make easy use of the COM/DCOM model, and to make it a straightforward proposition to create COM objects in several languages (primarily C++, Java, COBOL and Visual Basic), rather than having to write or wrapper everything in Java with EJB. But that still assumes you're using Microsoft's development tools; you're unlikely to see a Visual Basic IDE from another vendor, for instance, so you definitely hitch your wagon firmly to Microsoft by using its object model. Another double-edged sword is the ease with which COM objects are created. When a developer merely checks a box to create an object or make it transactional, it's easy to lose sight of what's going on under the hood--and what effect that may have on network traffic--and create swiftly written but poorly designed, inefficient systems.
What does the future hold for DCOM? Like Sun and the OMG, Microsoft doesn't want to make radical changes to anything in its object model. Microsoft claims that COM objects built when the specification was released in 1993 will work today. The emphasis, according to Microsoft, will be on stability and performance. Going from COM to COM+ involves folding formerly separate products, such as MTS, into the base OS, and adding some new services, such as dynamic load-balancing, in-memory database, a publish-and-subscribe events service, and a queued-components service. Unless Microsoft changes its mind, however, COM+ will be a reality for the Windows 2000 OS only.
EJB: The Challenger
EJB is the new kid on the block, released as a formal specification in March 1998. Although vendors claimed to support elements of EJB almost immediately, only now are products supporting the full spec appearing. Given the usual development cycle for tools and new products, the next six to 18 months will be crucial to EJB's long-term viability. Sun says six major EJB products are now shipping, with many large enterprise deployments of EJB-based systems expected between fall 1999 and mid-2000. For a year-old technology, that's not bad. However, enterprise systems tend to be built with proven technologies, not bleeding-edge ones, so we anticipate a fairly slow rollout of EJB.
Sun's plans for EJB's future are similar in one sense to Microsoft's plans for DCOM and COM+: They are evolutionary, not revolutionary. Every vendor wants its technology to be viewed as stable, and Sun is no exception. EJB 1.1 is expected at the JavaOne conference in June, but will probably be a tightened spec with some extensions, not a major rewrite. Sun wants to add XML (Extensible Markup Language) to the way EJB is built to help any server understand EJB. It also plans to enhance connectivity to legacy systems, such as IBM's CICS and IMS, without losing portability. Finally, Sun is developing a long-overdue reference implementation of EJB. The beta version of the reference implementation is slated for next quarter, with the final version due in the fourth quarter of this year.
The relationship between EJB and Sun's upcoming Java2 Enterprise Edition has been uncertain, especially whether Java2 would pull resources away from EJB. "Just as the Java Virtual Machine is core to Java2, EJB is core to Java2 Enterprise Edition," says Bill Roth, product line manager at Sun for the Java2 Enterprise Edition platform.
The Java2 Enterprise Edition will include and require many of the other core Java technologies: JNDI (Java Naming and Directory Interface), JDBC (Java Database Connectivity), servelets and Java Server Pages. In addition, CORBA/IIOP is a required part of Java2 (which includes a reference implementation CORBA 2.3-compliant ORB, Java IDL) and forms much of the transport infrastructure for Java2 Enterprise.
"The CORBA technologies represent the plumbing for us, and the real hope for interproduct interoperability," Roth says. Sun's stated goal is to make the underlying CORBA "plumbing" invisible to the Java2 programmer. In fact, while Sun says it is still paying attention to DCOM interoperability via a bridging strategy, Java2 Enterprise is not wire-transport neutral; Sun will use CORBA/IIOP as the communications infrastructure. Interoperability and interobject communication will be through RMI over IIOP, making CORBA essential, but invisible. Sun is planning to take a more public role in the OMG, a further indication of a gradual merging of elements of CORBA and EJB over the coming year.
Because EJB is fundamentally built on the Java language, some of the issues particular to Java have a direct impact on EJB. Primary among these is performance, long Java's Achilles' heel. Sun has released a beta version of the HotSpot compiler, and promises a final version with greatly improved performance. In the meantime, IBM's new version of Visual Age for Java produces native binaries, but that's a short-term solution that contradicts Java's "write once, run anywhere" model. Some heavy-duty, 100 percent Java-written production applications are starting to appear, so clearly the performance problems can be addressed with enough care, and Java has proved itself to have perfectly acceptable performance on the server side for most uses. Also, Sun plans to introduce a new revision to servelets soon, with improved architecture and performance features. Finally, Java's future direction will come into question if Microsoft loses its ongoing court battle with Sun and cuts off its support for Java. That action, while not necessarily fatal, would put a speed bump on the road to Java's, and thus EJB's, widespread acceptance in the enterprise space. On the other hand, it would also provide a rich market for enhancements, such as Sun's Java Plug-In, which allows enterprise developers to configure either Microsoft Internet Explorer or Netscape browsers to use a specific version of Sun's Java Runtime Environment (JRE) instead of the one included with the browser.
Sun is trying to position EJB as "the industry's best hope to deliver true interoperability," Roth says. But the OMG has shown what a difficult challenge such a goal can be. Sun also suggests that EJB can be a simplifying layer on top of CORBA and DCOM. For EJB to succeed, however, it needs to accelerate the availability of third-party development tools, and avoid the pitfalls of specification ambiguity that plagued CORBA, while at the same time not be so dictatorial as to discourage vendors. Sun says it doesn't see EJB as a direct competitor to Microsoft and this is true: EJB by itself is just a piece of paper; it's the supporting products the vendors develop using EJB that will provide competition for Microsoft and DCOM/COM+ based products.
1989 Object Management Group founded by American Airlines, Canon, Data General, HP, Philips Telecommunications, Sun Microsystems, 3Com and Unisys. October 1991 CORBA 1.0 introduced 1992 First CORBA commercial products appear February 1992 CORBA 1.1 introduced, first widely published specification December 1993 CORBA 1.2 introduced December 1994 CORBA 2.0 announced August 1996 CORBA 2.0 introduced, including IIOP and COM connectivity August 1994 CORBA 2.1 introduced, including IIOP over SSL February 1998 CORBA 2.2 introduced, including DCOM connectivity Fall 1998 CORBA 3.0 pre-release Mid-1999 (anticipated) CORBA 3.0 to be released, including new component model, scripting, asynchronous messaging, Java-to-IDL mapping and IIOP through firewalls. OMG has more than 750 members.
COM/DCOM
November 1987 DDE introduced for Windows 2.03 December 1990 OLE introduced for Windows 3.0 April 1993 OLE 2.0 introduced Spring 1993 COM 1.0 introduced Mid-1996 DCOM introduced January 1997 MTS 1.0 introduced December 1997 MTS 2.0 released Q4 1999 (anticipated) COM+ to be introduced as Windows 2000 component
Enterprise JavaBeans
January 1996 Java 1.0 released February 1997 Java 1.1, including RMI and JavaBeans, released March 1998 Version 1.0 of EJB specification released Summer 1998 First EJB 1.0-compliant products available December 1998 Java2 (1.2) released May 1999 (anticipated) EJB 1.1 specification to be released October 1999 (anticipated) First major EJB systems to be deployed
CORBA
PROS * Cross-platform * Multiple vendor support * Can develop in multiple languages * Longevity CONS * Highly complex * Continued cross-vendor interoperability concerns
DCOM
PROS * Easy-to-use development tools * Can develop in multiple languages * Components come from with Windows Large installed base * Large installed base CONS * Still largely Windows-only (with some limited cross-platform support)
EBJ
PROS * Cross-platform * Relatively easy to use * Strong third-party vendor interest CONS * Sparse third-party tools and products so far
~~~~~~~~
By Richard Hoffman
Send your comments on this article to Richard Hoffman at rhoffman@nwc.com.
Title: | A look at CORBA's telecom evolution. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Takes a look at the evolution of Common Object Request Broker Architecture (COBRA). History of COBRA; How COBRA is being used for peer-to-peer application integration; Predictions on COBRA. |
AN: | 1775090 |
ISSN: | 1075-5292 |
Database: | Academic Search Elite |
Section: NETWORK MANAGEMENT
In the late 1980s and early 1990s, the telecommunications industry, as well as just about every other industry that relies on technology, looked to identify and develop a common platform for distributed computing. At the time, there were a number of competitors for the job, but today Common Object Request Broker Architecture (CORBA) is among the victors. Though still maturing to meet telecom's needs, CORBA has found acceptance in a back office environment where tight systems integration is critical to a service provider's ability to be competitive. The technology has its shortcomings, as nearly all do, but CORBA appears to lead the way as more and more general -- as opposed to telecom-specific -- information technology makes its way into the telecommunications industry.
A BIT OF CORBA HISTORY
The late 1980s and early 1990s witnessed the advent of distributed computing technologies such as the distributed computing environment (DCE), remote procedure call (RPC) and the beginnings of message oriented middleware (MOM). Developers chose from a wide variety of nonstandard competing technologies or developed their own, explains Paul Smith, senior vice president of worldwide sales and marketing at DSET Corporation (Bridgewater, N.J.). In May of 1989, 3Com Corporation (Santa Clara, Calif.), American Airlines (Fort Worth, Texas), Canon Inc. (Lake Success, N.Y.), Data General (Westborough, Mass.), Hewlett-Packard (Palo Alto, Calif.), Philips Telecommunications N.V. (Atlanta), Sun Microsystems (Palo Alto, Calif.) and Unisys Corporation (Blue Bell, Penn.) formed the Object Management Group (OMG). The idea behind OMG was to bring these competing technologies together in order to develop "one, agreed-to distributed computing platform so that developers could build applications that would run on anybody's platform and not be relegated to proprietary platforms," says Smith. In 1991, the OMG introduced its CORBA, which today is in its third-release generation.
Smith also explains that originally, telecom's interest in CORBA did not lie in the network management or network operations domain. Rather, the industry viewed CORBA as best suited for business support system functions such as financial systems that are essentially common across many industries and aren't touched by the complex demands of telecommunications networks. In the early 1990s, the Q3 interface standard -- which is associated with the common management information protocol (CMIP) and the guidelines for the definition of managed objects (GDMO) -- was leading the way in network management. Network management application developers were interested in finding a common distributed computing platform as well, but wouldn't consider CORBA, basically due to the old telco belief that says any technology suitable for the rest of the world can't possibly meet telecom's strict requirements.
In 1992, Bellcore and its parent telcos established the Telecommunications Information Networking Architecture Consortium (TINA-C) to research a telecom-specific, distributed computing platform that would essentially compete with CORBA. TINA-C did establish standards, some of which various vendors and service providers have implemented. However, in 1996, the consortium recognized CORBA as a suitable technology to fill some of the telecom industry's needs. Ultimately, Object Request Broker (ORB) vendors, such as Iona, Visigenic (now Inprise; Scott Valley, Calif.) and the recent Vertel acquisition Expersoft (San Diego), further integrated more telecommunications-specific services into CORBA as demand for the technology grew.
Perhaps the greatest force driving CORBA in today's environment is cost. Because CORBA is generic information technology (IT), there is a large development community to support it. Start-up service providers have looked to CORBA to provide more affordable systems than are available with other technologies such as common management information protocol (CMIP). Systems vendors have taken advantage of the relatively large development community and utilized CORBA in product development. "Our CLEC customers often say they can't afford a CMIP solution and want something that's less expensive. CORBA is much cheaper and faster to implement,' says Beth Krevis, product manager for application programming interfaces (APIs) and trouble management at MetaSolv Software (Plano, Texas).
CORBA has found the most acceptance linking applications within the layers of the telecommunications management network (TMN) model. "Peer-to-peer-type applications make very good sense for the CORBA protocol," says DSET's Smith. "Between TMN layers, there's still a little more maturity that needs to develop, but there is plenty of work being done in that area.'
CORBA APIS
One example of where CORBA is being used for peer-to-peer application integration is the competitive local exchange carrier (CLEC) Allegiance Telecom (Dallas, Texas). Allegiance uses MetaSolv's Telecom Business Solution (TBS) as its central operations support system (OSS) application and DSET's OSS Interconnect gateway technology to exchange ordering information with Bell Atlantic (New York). The link between TBS and DSET's gateway is based on MetaSolv's CORBA API.
According to Krevis, MetaSolv's API is based entirely on a CORBA platform with an Interface Definition Language (IDL; see sidebar)-defined interface. Below that IDL definition are business objects that map to the interface. These objects can be written in any language, but MetaSolv uses Java. "Part of our overall architecture is to develop APIs that represent a business function. We use multiple business objects all within the same API to represent a business function," explains Krevis.
One such business function is the Local Service Request (LSR), the process and set of documents a CLEC must file to the incumbent local exchange carriers (ILECs) to initiate a customer switchover. For any LSR there is, naturally, an associated customer, a number of roughly standardized forms, and specific validation rules attached to each form, such as required and optional data fields. The LSR process is defined in an object that has child objects associated with it containing data for the customer and all of the specific forms. The objects for a specific LSR transaction are collected in the LSR API and made available to the gateway for translation and transmission from Allegiance to Bell Atlantic.
MetaSolv's API is also tied into its workflow engine, allowing specific tasks in TBS to be dynamically associated, by the user, to the interconnection process. For example, after LSR information is successfully exchanged, Bell Atlantic will send a firm order confirmation (FOC) to Allegiance. Once notified, TBS can begin the provisioning process. In many cases, this provisioning process is dependent on further transactions with the LEC, such as orders for leased circuits and number portability. Tasks in TBS can be defined in a provisioning plan. Each new piece of required information the CORBA API delivers will kick off the next set of tasks in the plan.
CORBA works in this type of environment because its architecture allows for a granular level of configuration. Rather than utilizing "hard code" to tie applications together, each behavioral aspect or process specific to cross-application interactions can be defined with objects. Object hierarchies allow attributes of a specific object to be changed independently of related objects; global changes can be made to entire classes of objects, or broad changes can be made to a specific subhierarchy of objects. The point of all of this is that it makes it easier to add or change processes and functionality on either side of a CORBA interface without fundamentally changing the way applications exchange data or without having to rebuild a large part of the interface.
However, peer-to-peer or east-west integration involves relatively low transaction volumes. CORBA's object architecture can handle such volume. It's at the high-volume interactions between TMN layers where CORBA's effectiveness comes into question. "We don't see scalability problems in the app-to-app interfaces because the transaction volume is relatively low," says Krevis. "When you're talking about going southbound to network elements, you're talking about thousands of transactions a minute. We're talking about sending LSRs between service providers. You may have a thousand a day, but you're not talking about thousands per hour, minute, or second."
THE SOUTHBOUND INTERFACE
Generally, the highest transaction volumes are found between the network management and element management or network element layers in the TMN model. An enormous amount of data, ranging from billing to activation to fault and trouble to performance is constantly flowing back and forth between the network and OSSs. Network elements do not yet utilize CORBA to send or receive information. They often use standards such as CMIP, signaling network management protocol (SNMP) or the older TL1. There are also a number of proprietary interfaces and protocols in the network.
However, network management platforms are being built on CORBA, and this has created a need for gateways that can translate between network element protocols and CORBA. Companies such as Vertel (Woodland Hills, Calif.) and DSET have developed CORBA-to-CMIP and CORBA-to-TL1 gateways. Essentially, these gateways are specialized mediation devices that receive the flood of information from the network in various formats, translate it into CORBA, and then parse it out to the appropriate applications. This allows for communication between the layers and protects applications from being overwhelmed by the sheer volume of data flowing up from the network.
This can also work in the opposite direction, where gateways receive CORBA commands and translate them into the appropriate network element protocols. Quite often, however, element activation systems are independently designed to communicate with multitechnology, multiprotocol networks. In such cases, CORBA gateways might not be necessary.
CORBA'S FUTURE
CORBA's future in telecommunication looks pretty bright, if for no other reason than the fact that Nortel Networks (Brampton, Ontario, Canada), Lucent Technologies (Murray Hill, N.J.), Tellabs (Lisle, Ill.) and Fujitsu (San Jose, Calif.) have been shopping it to various standards bodies for further development. They first brought the technology before the Sonet Interoperability Forum, which initially rejected it. Now, about a year later, the Sonet Interoperability Forum is taking a hard look at CORBA. The four giants also went to the TeleManagement Forum, which has since established a committee to look at a CORBA IDL interface between the network management and element management layers. The GDMO model has already been converted into CORBA IDL. Although these ideas have not been fully embraced, industry momentum and current investment suggests that CORBA will mature and be utilized in some fashion at all levels of the TMN model.
CORBA basics
The Common Object Request Broker Architecture (CORBA) is designed as a standardized, vendor- and operating system independent technology for client/server, object-oriented application integration. An Object Request Broker (ORB) is a type of middleware, standardized in CORBA, which enables client-server relationships between objects. When applications communicate, one application sends a request to the ORB, which then finds the appropriate object from the answering application to fulfill the request, feeds it the parameters of the request, performs the object's function, and then relays the result back to the requesting application. This essentially shields communicating applications from having to understand how to navigate within each other. ORBs are commercially available from vendors such as Visigenic (now Inprise; Scott Valley, Calif.) and Iona. The ORB provides the architectural details and integration/communication needs of each application through its Interface Definition Language (IDL), another part of the CORBA standard. IDL is designed to help developers avoid building any specialized protocols specific to the interaction of a particular collection of applications.
Editor's note: At the time this article was written, the author was a technical analyst at MetaSolv Software.
Figure 1: CORBA in the lower TMN layers
~~~~~~~~
By Edward Finegold
Title: | Winner of the CORBA Wars. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Focuses on the Iona Technologies, a software firm that has the largest share of the market for distributed object computing called CORBA. Companies comprising the Object Management Group (OMG) that created CORBA; How Iona managed to acquire the largest share of the CORBA market; Difference between Iona and its competitors. |
AN: | 1725279 |
ISSN: | 1085-2395 |
Database: | MasterFILE Premier |
Section: Development & Integration
Driving NT
Suppose you want to write a distributed application using object technology. If your application will run in a purely Microsoft environment, DCOM is the obvious choice. If your app needs to run on Unix or other non-Microsoft systems, though, DCOM isn't especially practical. So what middleware technology should you use?
The answer was supposed to be the multivendor standard for distributed object computing called CORBA. But CORBA isn't very complete, so products
built by different vendors have had a hard time working well together. Even though the vendors backing CORBA intended it to be a bulwark against Microsoft, the real competition turned out to be among the CORBA vendors themselves.
That competition has a clear winner: It's Iona Technologies, a Dublin, Ireland-based company that has the largest share of the CORBA market today. It's hard to know for sure, but it's possible that Iona is the only software company to have actually made a significant profit from CORBA. It's certainly the Only CORBA-based firm to enjoy a wildly successful IPO, something that I'm sure has made its backers quite happy.
As nearly everyone knows, CORBA was created by the Object Management Group (OMG), which has done an outstanding job of making its Work visible. OMG's original members included all the big guns, including IBM, Sun, and HP. How did Iona, a small start-up operating out of a far-away city in an economically depressed country, manage to acquire the largest share of the CORBA market?
The story is instructive. First, the big hardware vendors in OMG all seemed to believe that CORBA really was a standard, and so most of them built products that only ran on their own systems. The truth, however, was that the CORBA standards were so loosely specified that making different vendor's products interoperate was at best very challenging. What customers wanted was something that allowed them to create distributed object applications that ran on all of their systems, not just those from a single vendor. As a result, the CORBA-based products produced by hardware vendors were never very successful, and all of those original products have essentially left the scene today.
Iona understood what customers wanted from the beginning. Since the company had no vested interest in promoting any particular hardware platform, its CORBA implementation targeted multiple vendors' systems --including Windows NT and several flavors of Unix -right from the start. Iona benefited from the ultimately untrue but very appealing "CORBA is a standard" message promulgated by OMG, yet still provided a way to solve customer problems. All those customers had to do was install Iona's products on all of their systems. If pressed by their management, Iona customers could claim that they were buying a fully standards-compliant product. In reality, they were creating an effective, workable, single-vendor middleware environment.
Another difference between Iona and its competitors was in how it saw Microsoft. From the beginning, cynics observed that OMG was really the "Oppose Microsoft Group," and most CORBA vendors touted their superiority over COM. !Iona, by contrast, licensed COM from Microsoft. Iona's company slogan is "Making Software Work Together," clear evidence of their pragmatic perspective.
Just as Iona's dominance in the CORBA world has become clear, however, the game has changed. Purely CORBA-based products are on the wane as Enterprise Java moves to the fore. Enterprise Java adopts a few parts of CORBA, most notably IIOP, its core protocol. But good support for Enterprise JavaBeans (EJB) is emerging as the sine qua non for multiplatform distributed object middleware. No matter how many OMG standards a product implements today, it's nothing without EJB.
Iona understands this, as evidenced by their recent purchase of a small EJB company. But while they are the leader in the pure CORBA world, they're arguably a little late to the Enterprise Java party. Tough competitors -- IBM, BEA, and others -- have gotten there first.
The lesson for Iona, as for every organization, is that there's always another battle. Winning one may leave you in a good position to begin the next one, but that next battle is sure to happen. The lesson for end users is that pragmatic, customer-focused companies make the best partners, while religious fervor over some new standard is meaningless.
ILLUSTRATION (COLOR)
~~~~~~~~
By David Chapell
David Chappell is principal of Chappell & Associates (Minneapolis), an
education and consulting firm. Contact him at david@chappellassoc.com.
Title: | COM, CORBA bridges emerge and evolve. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Provides information on Microsoft Corporation's Component Object Model (COM) and the Common Object Request Broker Architecture (CORBA) as of November 18, 1998. Integration of Microsoft Transaction Server with OrbixOTM, a CORBA-compliant middle-ware suite from Iona Technologies P.L.C.; List of other products that provide COM/CORBA integration. |
AN: | 1333459 |
ISSN: | 1085-2395 |
Database: | MasterFILE Premier |
Section: Application Development
During the last few years, Microsoft Corp.'s Component Object Model (COM) and the Common Object Request Broker Architecture (CORBA) have developed side-by-side as competing methods of communication among distributed objects. Historically, COM and CORBA objects haven't interacted well with one another. During the past several months, though, a number of independent software vendors unveiled initiatives on the COM/CORBA integration front.
In late May 1997, for example, Microsoft Corp. agreed to integrate its Microsoft Transaction Server with OrbixOTM, a CORBA-compliant middle-ware suite from Iona Technologies P.L.C. (Cambridge, Mass., www. iona.com). Other products that provide COM/ CORBA integration are Object-Bridge, a COM/CORBA bridge from Visual Edge Software Ltd. (St. Laurent, Quebec, www. visualedge.com) and M3, an object transaction manager that supports both COM and CORBA from BEA Systems Inc. (Sunnyvale, Calif., www.beasys.com).
More recently, InterNova Corp. (Westport, Conn., www. internova.com) released the Professional Edition of the Colibri Engine and Development Suite. Rather than providing COM/CORBA integration services, however, this product provides developers with the ability to create COM objects using Microsoft's Visual Basic development environment and then bridge them with CORBA components using integrated scripting technology, such as VBA or Javascript.
While several tool vendors have developed similar technology -- like the new version of Borland Delphi rapid application development (RAD) environment from Inprise Corp. (Scotts Valley, Calif., www.inprise.com), which can create components that are both COM- and CORBA-enabled --InterNova's Colibri Engine and Development Suite is one of the first tools that allows developers to employ discrete integrated development environments, such as Microsoft's Visual Basic or Inprise's Delphi, to do the actual development work.
According to Brock Hotaling, CEO of InterNova, because the Colibri Engine and Development Suite heavily leverages scripting technology, it provides COM to CORBA bridging functionality in an everything-under-the-hood development environment that requires very little experience in developing for either distributed component architecture.
"We have built into this engine a COM/CORBA bridge, so you don't need to worry about whether you're developing COM, or CORBA or whatever. It's all smooth," Hotaling says. "Our clients are scared of CORBA, scared of Java, and they just can't find qualified people to do CORBA or Java programming. This allows them to hire different people, because a huge population of programmers knows how to do scripting."
The Colibri Development Engine functions by linking the Microsoft COM desktop environment and CORBA services via a COM-CORBA Bridge, then bridges to an ODBC- or JDBC-compliant database, such as Oracle 8 from Oracle Corp. or SQL Server from Microsoft, with automatic persistence mechanisms using ODBC/JDBC or native drivers.
In addition to a Colibri Client Suite, the Colibri Development Suite includes Colibri Studio, the Colibri Management Console and a CORBA Template Starter Kit, which features sample templates that enterprises can use to customize business services.
InterNova's Hotaling indicates that many of his company's customers require COM/CORBA integration services because they are standardized on COM on the desktop and on CORBA in the backend. By Hotaling's account, this isn't about to change anytime soon. Although CORBA is a newer, sexier technology, it simply doesn't have the maturity or functionality of COM on the client-side. "To be honest with you, right now the Microsoft desktops are just far and away better than their CORBA counterparts," he explains.
Mike Gilpin, vice president and senior analyst, research services, with consultant Giga Information Group (Norwell, Mass., www. gigaweb.com), concurs, but cautions client-side application developers must now be attuned to the presence of the CORBA standard in the backroom. "I think that everybody knows that COM has established a firm ownership of the desktop environment as a standard, but what's making this integration more important is that in the context of Internet standards CORBA is gaining more popularity, particularly in the areas of Java and Enterprise Java Beans functionality (EJB)," Gilpin notes. "Anyone who wants to create an application available in a Windows environment now needs to provide some sort of interoperability solution [between COM and CORBA]."
~~~~~~~~
By STEPHEN SWOYER
Title: | COM and CORBA: Not really competitors. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Describes the Component Object Model (COM) and the Common Object Request Broker Architecture (CORBA) standards for system software. Limitations of CORBA; Tips on building distributed object applications; Options beyond COM and CORBA. |
AN: | 1333465 |
ISSN: | 1085-2395 |
Database: | MasterFILE Premier |
COM AND CORBA: NOT REALLY COMPETITORS
Microsoft's COM and the Object Management Group's CORBA have long been portrayed as fierce competitors. Forests have been leveled to generate paper for the voluminous written attacks by partisans in both camps, and megawatts of electricity were expended to convey their electronic equivalents. COM vs. CORBA is one of the most visible industry conflicts of the last few years.
But it's not really correct.
Don't worry. I'm not going to explain how COM and CORBA can actually live in harmony, or how the Microsoft lion will lie down with the OMG lamb and peace will reign in the land. None of that is going to happen. All the hopeful predictions of the eventual technological union between COM and CORBA are wrong. These two technologies will remain distinct --although the CORBA camp has understood the necessity of defining mappings to COM, if only to support those ubiquitous Visual Basic clients.
If COM and CORBA were really competitors, however, you'd be faced with situations where you were forced to choose between them. In fact, this almost never happens. And if you don't get to choose between two technologies for a given application, then, by definition, those technologies can't be competitors.
To explain what I mean, let me start by pointing out that there are some important cases where CORBA just doesn't apply. The OMG never really defined a standard for running objects in the same process as their client, for example, while this is a critical part of COM. A more correct comparison, then, is between CORBA and Distributed COM. Both CORBA and DCOM focus on the same thing: creating and communicating with objects running on remote machines. So the real question becomes, when are you faced with a choice between DCOM and CORBA?
Suppose you've decided to build an application using distributed object technology. If your clients are Windows 9x or Windows NT machines, and your servers run NT, DCOM is the obvious choice. You certainly could go out and purchase an appropriate number of licenses for your favorite CORBA-based product and use it instead, but why would you? DCOM is free, it has reasonable security (something that's harder to find in CORBA-based products), and it has great tool support on Microsoft platforms.
If, on the other hand, you'd like to use Unix or the mainframe for your server, DCOM isn't really an option. True, Microsoft and others do sell DCOM products for operating systems other than Windows and Windows NT, but it's hard to take these products seriously. Microsoft has said publicly that COM's next release, COM+, won't be available anywhere except Windows and Windows NT, which means that COM on non-Microsoft systems is already becoming legacy technology. But more fundamentally, do you really believe that Microsoft cares about operating systems other than its own? While it's plausible that they're interested in connecting to existing applications and data on those systems, it's much less believable that Microsoft will help you build new business logic on those systems. All of this means that choosing to build a new server application on non-Microsoft platforms using DCOM, while technically possible, is a very risky choice.
So here's the very simple decision tree for building distributed object applications: If both client and server run Microsoft operating systems, use DCOM. If not, use a CORBA-based product. Once you've chosen the operating systems, the choice of a distributed object technology is already implied. The apparent competition between DCOM and CORBA is really just an artifact of a much more titanic struggle: the fight between Windows NT and everything else.
One final note: The COM vs. CORBA battle gets so much attention that I sometimes think other middleware choices don't get the consideration they deserve. In particular, there are plenty of situations where message queuing middleware, such as IBM's MQSeries, makes much more sense then either COM or CORBA. And some projects that are built using distributed objects might have been doable as Webbased applications instead. Despite the hype around objects, there are other choices worth considering than just COM or CORBA.
~~~~~~~~
By DAVID CHAPPELL
David Chappell is principal of Chappell Associates (Minneapolis), an
education and consulting firm. Contact him at david@chappellassoc.com.
Title: | Keeping track of expanding market scope. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Discusses the Object Request Broker (ORB) technology which provides users with the application development environments required and the access to diverse services demanded by Web-based clients. Four main types of middleware that support applications; ORB design according to the Common Object Request Broker Architecture (CORBA); Object Management Group's responsibility for the CORBA specifications. |
AN: | 1297879 |
ISSN: | 0319-0161 |
Database: | MasterFILE Premier |
Section: Feature
As more users take advantage of distributed computing, and Internet technologies become more prevalent, many middleware trends are appearing. These trends aim to provide organizations with the application development environments required and the access to diverse services demanded by Web-based clients.
Of the four main types of middleware that support applications --Application Development Environments (ADE), data access services, message-oriented middleware (MOM), and object/component services --Object Request Broker (ORB) technology is apparently getting the most ink.
ORBs, designed according to the Common Object Request Broker Architecture (CORBA), allow objects within an application system to interact. In a distributed environment, the ORB keeps track of objects and their location on the network. Applications requesting services need only make the request to the ORB, which routes the request transparently.
Because of the complexity of the object/component environment, there is a clear need for standards. The Object Management Group (OMG) maintains responsibility for the CORBA specifications, and is also responsible for the Internet Inter-ORB Protocol (IIOP), which is intended for similar object services over the Internet. CORBA, however, is primarily deployed in the Unix and large-scale systems domain.
Then there is Microsoft's COM/DCOM (Distributed/Component Object Model), an ORB that is available on Windows platforms only and that does not comply with CORBA specifications. DCOM allows COM-enabled applications to interact with other COM-enabled applications over a network. Although proprietary, it is able to take advantage of operating system functions and services by effectively re-using them.
There is now an ongoing CORBA-versus-COM/DCOM debate and there isn't likely to be a clear winner in the short term. CORBA is today more open, mature, robust and scalable, while COM/DCOM is rapidly gaining because of the widespread use of Microsoft operating systems.
An emerging class of "object" middleware involves Object Transaction Monitors (OTM), which combine the power, robustness and scalability of Transaction Processing Monitors (TPMs) with the re-usability and flexibility of ORBs. Microsoft's Transaction Server (MTS), because of its strong integration with DCOM, fits in this category. It can manage any ActiveX object, and any component built with development tools such as Java++ and C++ can be managed by the MTS. OTMs are also available in the Unix world where CORBA has developed a specification called Object Transaction Server (OTS). Sybase's Jaguar Component Transaction Server is built using this standard.
With the emergence of Enterprise Resource Planning (ERP) systems, middleware is evolving to solution-oriented implementations. Packaged solutions from companies such as CrossRoads Software link two or more ERP applications in plug-and-play fashion. CrossRoads provides the application components and the underlying middleware components to enable interoperability between ERP systems.
Specific solutions are evolving for the Internet. Java Database Connectivity (JDBC) provides access from Java applications to distributed databases and the Remote Method Invocation (RMI) is the Java equivalent to Remote Procedure Calls.
The greatest change due to the Internet will be componentization. To isolate an unknown number of "browser-based" users from various segments of an enterprise's applications, enterprises will increasing rely on application (or component) servers.
These middleware servers will take advantage of many of the services described above, but attempt to package them in a single product offering.
Application servers will typically allow "browser-based" clients to access a variety of distributed applications, transparently providing them with the required underlying middleware support.
As this is new technology, applications will likely be developed using newer Web application development tools (e.g. Java, JDBC, IIOP, Web Server-specific APIs) and be developed as objects or components where possible.
However, applications will still require access to basic middleware services such as data access, message-oriented middleware and ORB technology.
In the short term, enterprises developing distributed computing applications can expect to use a combination of middleware types. As Internet technologies gain greater acceptance, middleware that enables application development and deployment in this environment will become widespread.
Although some features and functionality of different types of middleware are converging, enterprises can expect to use multiple types to address their specific needs.
~~~~~~~~
By Geoff Ribek
The author is associate director in DMR's Technology Consulting Practice
based in Ottawa. His e-mail is geoff(underbar)ribek@dmr.ca.
Title: | The MICO CORBA compliant system. (cover story) |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Discusses the compliant system implementation of Object Management Group's Common Object Request Broker Architecture (CORBA) which describes the architecture of a middleware platform that supports the implementation of applications in distributed environment. Overview of the components required for a CORBA 2.0 compliant implementation; Steps toward creating a distributed application with CORBA technology. |
AN: | 1188357 |
ISSN: | 1044-789X |
Database: | MasterFILE Premier |
THE MICO CORBA COMPLIANT SYSTEM
The Common Object Request Broker Architecture (CORBA) describes the architecture of a middleware platform that supports the implementation of applications in distributed and heterogeneous environments. The CORBA standard is issued by the Object Management Group (OMG), an international organization with over 750 information software vendors, developers, and users. In contrust to other middleware platforms (like Microsoft's DCOM), CORBA is a specification that does not prescribe any specific technology. In fact, the specification is freely available from the OMG (http://www.omg.org/) and anyone can implement a CORBA-compliant system. In this article, I'll present one such system-MICO (short for "Mico Is COrba"), a freely available CORBA implementation.
The MICO sources are available at http://www.icsi.berkeley.edu/~mico/. The compilation and installation of MICO requires the usual GNU tools. Precompiled binaries as well as a more detailed manual are available from Morgan Kaufmann Publishers (http://www.mkp.com/). The distribution currently contains binaries for IBM-AIX, Linux, DEC Alpha, and HP-UX. It should not be difficult to port MICO to any platform where GNU tools are available (for instance, we were able to compile MICO under Windows NT).
The current version of MICO supports:
• IDL to C++ mapping.
• Dynamic Invocation Interface (DII).
• Dynamic Skeleton Interface (DSI).
• Graphical Interface Repository browser that lets you invoke arbitrary methods on arbitrary interfaces.
• Interface Repository (IR).
• IIOP as native protocol (ORB prepared for multiprotocol support).
• Support for nested method invocations.
• An interface for inserting and extracting constructed types that were not known at compile time.
• Full Basic Object Adapter (BOA) implementation, including all activation modes, support for object migration and the implementation repository.
• BOA can load object implementations into clients at run time using loadable modules.
• Portable Object Adapter (POA).
• Support for using MICO from within XII applications (Xt, Qt, and Gtk) and Tcl/Tk.
• Naming service.
• Event service.
• Trading service.
• Dynamic Any.
• Interceptors.
• Support for secure communication and authentication using SSL.
Overview of CORBA
Figure 1 presents an overview of the components required for a CORBA 2.0-compliant implementation (depicted in gray), as well as the embedding of an application in such a platform (white components). The Object Request Broker (ORB) is responsible for transferring operations from clients to servers. This requires the ORB to locate a server implementation (and possibly activate it), transmit the operation and its parameters, and finally return the results back to the client.
An Object Adapter (OA) offers various services to a server such as the management of object references, the activation of server implementations, and the instantiation of new server objects. Different OAs may be tailored for specific application domains and may offer different services to a server. The ORB is responsible for dispatching between different OAs. There is only one OA required for a CORBA 2.0-compliant implementation--the BOA. As its name implies, it offers only basic services to a server.
The BOA has access to the Implementation Repository (IMR), which contains information concerning the activation of servers; for example, the location of the executable to handle particular incoming operations. The ORB, on the other hand, has access to an Interface Repository (IR) at run time. The IR holds information about the interfaces (IDL specifications, for instance) used within the domain of the ORB.
The interface between a client and server is specified by an Interface Definition Language (IDL). According to the object paradigm, an IDL specification separates the interface of a server from its implementation. This way a client has access to a server without being aware of the server's implementation details. An IDL compiler generates a stub for the client and a skeleton for the server, which are responsible for marshalling the parameters of an operation.
The Dynamic Invocation Interface (DII) allows a client to invoke a remote operation without requiring a stub, and likewise, the Dynamic Skeleton Interface (DSI) enables a server to receive an operation invocation without requiring a skeleton. Thus the DII and DSI represent generic methods for sending and receiving operations. A possible application for the DII and DSI is a gateway, which provides bridges between CORBA and other middleware platforms. Without the DII and the DSI, the gateway would have to be recompiled with the appropriate stubs and skeletons and restarted every time a new IDL specification is introduced to the system.
Design Criteria for an ORB
If someone sets out to implement the CORBA standard, it is necessary to decide on the design criteria according to which the implementation should be structured. The design principles which guided the implementation of MICO include:
• Start from scratch. Use only what standard UNIX API has to offer. Don't rely on proprietary or specialized libraries.
• Use C++ for the implementation.
• Make use of widely available, nonproprietary tools.
• Omit bells and whistles. Only implement what is required for a CORBA-compliant implementation. Run-time efficiency is not an issue.
• A clear design, even for implementation internals, ensures extensibility.
The result of 10 months work and 90,000 lines of code, MICO is a fully CORBA 2.0-compliant implementation. Since MICO implements the Internet InterORB Protocol (IIOP), it is fully interoperable with other CORBA implementations. Interoperability was successfully tested with Orbix from Iona, VisiBroker from Inprise, and Sun's JDK 1.2 beta 2 (which now includes a "little ORB").
MICO's Modular Architecture
The design of our ORB as the central component of a CORBA implementation follows a microkernel approach. This means that as much functionality as possible is moved outside the ORB in order to keep it small and efficient. Our implementation of IIOP demonstrates this principle.
The way parameters and operations are coded and transferred via TCP/IP between two ORBs is defined by the CORBA standard through IIOP; thus, it should be possible to run one application across ORBs from different vendors if they correctly implement IIOP. The CORBA standard purposely does not prescribe any specific technology for the implementation of IIOP. To facilitate the integration of future transport mechanisms between ORBs, we located the implementation of IIOP in MICO outside of the ORB.
In Figure 2, the implementation of the IIOP protocol is located in a special-purpose OA (IIOP client) and an object (IIOP server). When a client sends an operation, this operation first enters the ORB. The ORB then dispatches the operation to one of the OAs that have previously registered with the ORB. The decision of where to send the operation is solely decided on the basis of the object reference; the ORB itself has no knowledge of remote or local objects. If the server object resides in a different address space, the operation is dispatched to the IIOP client.
This special-purpose OA opens a TCP/IP connection to a remote IIOP server. The IIOP server behaves like an ordinary CORBA object and forwards the operation to its local ORB. Here, the operation is dispatched by the ORB via the BOA to the server object.
Once an OA has taken over the responsibility of an operation invocation, the ORB does not need to know what the OA is doing with it. Whether the OA opens a TCP/IP connection or does something else is out of the jurisdiction of the ORB. Using this microkernel architecture we have also implemented the various activation modes CORBA prescribes for a compliant implementation by means of a special-purpose OA. This guarantees a modular and easily extensible architecture.
Which Came First?
An IDL compiler translates an IDL specification into the stubs and skeletons. The code that the IDL compiler generates for stubs and skeletons must be in the same programming language used in the implementation for the client and the server (client and server need not be written in the same programming language). The CORBA standard defines mappings from IDL to several high-level programming languages. According to the rules for CORBA compliance, an implementation has to offer at least one IDL language mapping to one high-level programming language: MICO implements the IDL-to-C++ mapping.
An IDL compiler works in two steps: The IDL specification to be translated is checked for correct syntax and semantics, and then code is generated for the target language according to the language mapping. These two steps are called the "front-end" and "back-end" processing in compiler construction terminology.
The front end of the IDL compiler must somehow pass on information to the back end. This data structure is commonly known as a "syntax tree." In this case, a careful analysis shows that the logical structure of the syntax tree is equivalent to the logical structure of the Interface Repository (IR). As previously noted, the IR is responsible for storing and retrieving IDL specifications.
Since the IR is mandatory for a CORBA-compliant implementation, MICO's IDL compiler makes use of the IR to pass information from front-end to back-end. Here, however, lies an interesting problem: Because the IR itself is a proper CORBA object, its interface is defined in terms of an IDL specification; this leads to a chicken versus egg problem, since implementing an IDL compiler requires an IR, and, since a stub and skeleton are necessary for the implementation of the IR, the converse is true as well. However, this issue is easily resolved via a bootstrap process: The stub and skeleton for the IR are first generated manually by the developer, and then later replaced by the ones automatically generated by the IDL compiler. If you download the sources for MICO, you will find code generated by the IDL compiler during this bootstrap process.
Another specialty of MICO is related to the code generated by the IDL compiler. The stubs and skeletons generated by the IDL compiler are responsible for marshaling the parameters associated with an operation. MICO's marshaling is done via a standard interface offered by the ORB, while other CORBA implementations came up with their own (and proprietary) interface. The stubs and skeletons in MICO use the DII and DSI that are mandatory for a compliant implementation; therefore, the code generated by the IDL compiler also demonstrates the uses of the DII and DSI interfaces of a CORBA platform.
Sample Application
The first step toward creating a distributed application with CORBA technology such as MICO is to define the interfaces between the objects of the application using IDL. As an example, I'll use a banking scenario: The server models a bank account where a client can deposit and withdraw money. Listing One (at the end of this article) shows one possible IDL specification for this.
The server implements three operations: deposit, withdraw, and balance. The keyword in denotes an input parameter, and similarly, the keywords out and inout denote output and combined input/output parameters. The IDL specification in Listing One is fed into the IDL compiler to generate a stub and a skeleton for this interface. Next, the server must be implemented as in Listing Two. The server provides an implementation for all the operations listed in the IDL specification. This implementation is represented by the C++ class Account(underbar)impl, and is derived from class Account(underbar)skel: a class part of the skeleton. The class Account(underbar)skel receives an operation invocation and dispatches it to the proper C++ method. The three methods of class Account(underbar)impl are declared as pure virtual methods in class Account(underbar)skel.
The first step of every CORBA application is the initialization of the ORB and the BOA. Following this, a new account object can be instantiated. The function object(underbar)to(underbar)string converts the object reference of the newly created object from an internal binary representation to an ASCII string. This string is called an Interoperable Object Reference (IOR) by the CORBA standard and allows clients to locate the account object. Clearly, the IOR must encode a hostname and port number for this to work. The question is how to transfer the IOR to the client. For the scope of our little example, we simply use a UNIX file to store the IOR. A better (but more complex) way would be to use CORBA's naming service.
Listing Three presents the implementation of the client which uses the account object. Like the server, it first initializes the ORB, and then the client reads the IOR from the previously created UNIX file. The client does not need to initialize the BOA, because the BOA is only required for server functionality. Subsequently, the function string(underbar)to(underbar)object is used to convert the ASCII representation of the IOR back to a binary representation. This leaves you with an object reference to an interface Obect--the base interface of all CORBA interfaces. The interface must now be downcasted to the proper type. This is accomplished by the function (underbar)narrow, which is also generated for every stub.
Once the object reference is downcasted to match the interface type "Account," the client can invoke any of the operations belonging to the interface. The operation invocation is indistinguishable from a normal C++ method call and it is transparent to the client whether the server resides in the same address space or on a remote host. In fact, if the server happens to reside in the same address space, then the operation invocation is mapped to an ordinary C++ method call with no extra overhead. Just as the server's location is transparent to the client, so is the programming language with which the server is implemented.
If you have installed MICO on your system, compiling the example is easy. MICO provides you with some wrapper scripts, which add proper command-line arguments to the compiler and linker (such as include directories). From a UNIX shell, use Example 1 to generate the executables of the bank demo. This example is part of a tutorial from the MICO documentation that comes with the sources. The tutorial enhances the example by showing how to use the CORBA activation modes or the persistency mechanism. Another component of MICO is a graphical browser for the IR.
IR Browser
A CORBA-compliant implementation must provide an Interface Repository (IR) which can be seen as a database for IDL specifications accessible at run time. The information managed by the IR is organized hierarchically. Two different types of objects are managed by the IR: those objects which can contain other objects (called "Container") and those which are contained in other objects (called "Contained"). The IDL-type const is an example of a Contained, whereas the IDL-type "interface" is a Container as well as a Contained (for example, it contains other objects like const declarations and can itself be contained in a module).
Upon starting the graphical IR-browser, top-level objects are represented by icons. Moreover, the IDL source code can be shown for each object. The contents of the objects representing containers may be viewed as if the user had descended one level along a branch of the hierarchy.
Figure 3 is the IR browser in action. Prior to starting the IR browser, the IR was fed the IDL specification from Listing One. The interface Account is a Container containing three Contained objects. Each of these Contained objects represents one of the operations belonging to the interface Account. The upper window shows the content of the interface Account, and the three icons on the right side denote the operations deposit, withdraw, and balance. The left side of this window shows the IDL source code of the currently selected operation, deposit.
The IR browser also permits calling arbitrary operations at run time using the DII. Using the information from the IR, the tool constructs a graph representing the signature of an operation. This graphical notation is derived from a knowledge representation technique called "conceptual graphs" (CG). The lower-right window from Figure 3 displays the signature of the operation deposit as a conceptual graph. The lower-left window shows the same conceptual graph; this time in its textual notation (white nodes are surrounded by square brackets and black nodes by round brackets).
Some of the white nodes represent actual parameters which can be edited using the tool. In Figure 3, the value of the node ULONG is changed from 0 to 100. The resulting conceptual graph represents the operation invocation deposit(100). The tool can also be used to construct arbitrary IDL types like struct or sequence on-the-fly via conceptual graphs. The MICO homepage contains an online demonstration in the form of a Java applet that connects you to an Account object running on one of our machines.
Lessons Learned
The CORBA standard represents a specification of a middleware platform. It leaves room for design and implementation decisions which must be carefully considered. Some parts of the CORBA Standard, such as the BOA, are underspecified. This led to different implementations of the BOA for different ORB vendors, making it impossible to just exchange the underlying ORB and recompile the application. The OMG has recognized this problem and has released the specification of a Portable Object Adapter (POA).
Although MICO is not a commercial product, it is used by many research institutes and companies. Universities find it useful for term projects, while other groups find the availability of the source code advantageous for their own research. Gnome (http://www.gnome.org/), a set of applications and desktop tools similar to CDE but based entirely on free software, uses MICO for the internal communication and activation of its components.
The CORBA standard is far from complete. Version 2.2 of the specification was released by the OMG early in 1998. Our goal is to keep MICO compliant to the most recent version of the standard. We hope that placing the sources under the GNU General Public License will encourage other programmers to contribute to MICO's development.
Listing One
// File: account.idl interface Account { void deposit( in unsigned lonbg amount ); voide withdraw( in unsigned long amount ); long balance(); };
Listing Two
// File: server.cc #include <fstream.h> #include "account.h" // Implementation of Interface Account class Account(underbar)imp1 : virtual public Account(underbar)skel { private: CORBA::Long(underbar)current(underbar)balance; public/: Account(underbar)imp() { (underbar)current(underbar)balance = 0; } void deposit( CORBA::ULong amount ) { cout << "Operation deposit( "<< amount ")" << end1; (underbar)current(underbar)balance += amount; }; void withdraw( CORBA::ULong amount) { cout << "Operation withdraw(" <<amount << " )" << end1; (underbar)current(underbar)balance -= amount; } CORBA::Long balance() { cout << "Operation balance() => " << (underbar)current(underbar)balance << end1; return (underbar)current(underbar)balance; }; }; int main( int argc, char *argv[] ) { // ORB and BOA initialization CORBA::ORB(underbar)vara orb = CORBA::ORB(underbar)init(argc, argv, "mico-local-orb" ); CORBA::ORB(underbar)var boa = orb->BOA(underbar)init(argc, argv, "mico-local-boa"); // Create new Account object Account(underbar)impl* server = new Account(underbar)imp1; // Write IOR to file ofstream out ( "account.ior" ); CORBA::String(underbar)var ref = orb->object(underbar) to(underbar)string( server ); out << ref << end1; out.close(); // Start processing incoming operations bo->imp1(underbar)is(underbar)ready (CORBA::ImplementationDef::ni1() ); orb->run(); CORBA::release( server ); return 0; }
Listing Three
// File: client.cc #include (iostream.h> #include <fstream.h> #include "account.h" int main( int argc, char *argv[] ) { { // ORB initialization CORBA::ORB(underbar)var orb = CORBA::ORB(underbar)init(argc, argv, "mico-local-orb" ); // Read IOR from file ifstream in( "account.ior" ); if( !in ) { cerr << "Can not open file 'account.ior'" << end1; return - 1; } char ref[1000]; in >> ref; in.close(); // Generate object reference from stringified IOR CORBA::Object(underbar)var obj = orb->string(underbar) to(underbar)object( ref ); Account(underbar)var client = Account::(underbar)narrow ( obj ); of( CORBA::is(underbar)nill( client ) ) { cerr << "IOR does not refer to an Account object" << end1; return -1; } // Invoke operation on remote object client->deposit( 700 ); client->withdraw( 250 ); cout << "Balance is " << client->balance() << end1; return 0; }
DIAGRAM: Figure 1: An overview of components required for a CORBA 2.0-compliant implementation.
DIAGRAM: Figure 2: Implementation of the IIOP protocol is located in a special-purpose OA (IIOP client) and object (IIOP server).
PHOTO (COLOR): Figure 3: IR browser in action.
PHOTO (COLOR): Example 1: Generating executables of the bank demo.
~~~~~~~~
By Arno Puder
Arno is working for the Deutsche Telekom AG and is currently on sabbatical at
the International Computer Science Institute in Berkeley, California. He can be
contacted at puder@icsi.berkeley.edu.
Title: | OMG pushes computing integration with COBRA. |
Subject(s): | |
Source: | |
Abstract: | Highlights the efforts of Object Management Group (OMG) to launch the CORBA 3.0 initiative, a computer software. Features of the software. |
AN: | 1272730 |
ISSN: | 1074-4770 |
Database: | MasterFILE Premier |
Section: INDUSTRY WATCH
Executives from BEA Systems, IBM and Oracle were among Object Management Group (OMG) members and customers announcing the new CORBA 3.0 initiatives at a Sept. meeting in San Francisco.
OMG members, whose goal is to set the standards for distributed computing, feel CORBA 3.0 will achieve a new level of capabilities for both experienced distributed computing programmers and less technical business analysts.
This version will simplify the use of CORBA ORBs for developing distributed object applications and should facilitate CORBA's adoption into the enterprise, OMG says.
The CORBA Component Model is a feature specifying the framework for "plug-and-play" and facilitates integration with JAVA.
CORBA objects by having the creation, life cycle and events for one object for clients to explore. It also facilitates integration with JAVA.
A simplifying feature is the scripting language specifications. These remove
the need for memory allocation and de-allocation as well as compilation and
linking procedures. Passing information in an object-oriented form across a
network can be achieved through CORBA support for
Objects-by-Value.
www.omg.org
Title: | Muddied Waters: Distributed APIs. (cover story) |
Subject(s): | |
Source: | |
Abstract: | Discusses the competition between Component Object Model (COM), Common Object Request Broker Architecture (CORBA) and Enterprise Java Beans (EJB) as the application programming interface (API) set for distributed computing. How the success of the Java programming language in enterprise computing will depend on its acceptance as a distributed computing framework; Why businesses need to choose between COM, CORBA and EJB for their middleware. |
AN: | 1165875 |
ISSN: | 1046-4468 |
Database: | Academic Search Elite |
Section: JAVA
Just when it seemed that big business was ready to tap into distributed computing by choosing between Microsoft's COM (Component Object Model) and the Object Management Group's CORBA (Common Object Request Broker Architecture), Enterprise JavaBeans (EJB) came along to muddy the waters.
To be fair, it isn't just EJB that makes distributed computing look like California in the mud season. While ISVs eagerly eye Microsoft's COM and COM&PLUS;, most large businesses seem to have concluded that they'll need to write to both COM and CORBA, and now momentum is also mounting for EJB as the API set to which businesses will write their distributed applications.
Ultimately, the long-term role of Java in the enterprise will hinge on its acceptance as a distributed computing framework-either alone or in conjunction with CORBA. But that role has yet to be assured for Java, COM or CORBA. In fact, some of the most important interfaces could actually arrive as private APIs from companies that are virtually unknown today. That's because just about every major vendor and a slew of innovative startups see a huge market in building combo packages that leverage some or all of these frameworks. And these new middleware combos-commonly packaged as application servers-represent an ever-increasing accordion of disparate APIs, vendor-specific extensions and platforms that intermingle components (see "Some Well-Known Application Servers,").
Middleware now seems to stretch from the simplest application servers to high-end transaction services like BEA Systems Tuxedo. Mudware, in fact, may be a better name.
The traditional wisdom is that 1998 is the year for big businesses to choose between COM and CORBA. Since that choice will reflect a recognition that support must be provided for both, users must now select an integration platform as well. Then they must choose an API set, since, for example, platforms like CORBA may also have their own distinct APIs. Finally, they will have to choose the middleware server product on which to write their applications and provide component services-a choice that increasingly entails committing to a proprietary API.
John Rymer, president of Upstream Consulting, is among those predicting the emergence of a wide variety of standard and proprietary distributed computing interfaces and platforms to unify disparate frameworks. The private APIs are intended to provide a layer of API abstraction in front of existing CORBA, COM or EJB APIs, to simplify the task of writing to multiple frameworks or to add value to those frameworks. Private APIs will also be used to flesh out the limited functionality of EJB.
Rymer says he expects OMG to vote on CORBA 3 this fall, which will position CORBA as a platform to bridge multiple object models. He also points to private application server superAPIs-from Sun's NetDynamics to Novera Software and ObjectSpace-that create their own entry into various distributed computing frameworks.
But how these superAPIs are implemented highlights possibly dramatic differences in the world of application servers. Vendors such as BEA Systems, for example, plan to support both a superAPI and a repository approach providing direct access to APIs for frameworks like EJB. Sun's NetDynamics is moving toward supporting EJB atomically within its BusinessBeans private API set.
In fact, Rymer expects most application server providers to distinguish their products by extending their own APIs or those proffered by OMG and Microsoft. The trade-off for this added functionality is user lock-in. It's a price many businesses are willing to pay to cut development cycles. Some application server platforms, for example, are credited with cutting COM and CORBA development time in more than half-primarily by offering prepackaged components and services that users would otherwise have to build.
An interesting example of yet another type of emerging integration platform with private APIs is ObjectSpace's Voyager product series, with its popular Object Request Broker. Voyager provides CORBA and RMI compatibility, with DCOM compatibility promised in an upcoming version.
But what really impresses software developers is how ObjectSpace lets them create special components, known as agents. These agents can move independently from one device or program to another-a mobile code talent that's particularly suited to tasks like dynamic load-balancing.
Java deployment may be further delayed by the sheer volume of competing products and the lack of uniform feature sets between them. For example, many application servers are ramping up to support EJB exclusively, with others adding CORBA and an even smaller set also adding COM.
What is clear from the emergence of so many APIs is that it makes sense for large users to select platforms that at least blend support for frameworks. Sun and the OMG have taken the first steps toward common ground with OMB's RMI over IIOP specification. David Curtis, formerly OMG's director of platform technology and now with Inprise, says the specification allows RMI to be mapped to CORBA's Interface Definition Language. RMI over the Internet InterORB protocol (IIOP) lets an RMI program talk to a CORBA object without requiring IDL knowledge on the part of the Java programmer. A key advantage of the specification is that applications addressed by CORBA won't have to be rebuilt to become part of a Java infrastructure.
Still, concern remains over the nuances of shipping a JDK that supports not one, but two approaches. Certainly, duplication generally heightens complexity and boosts overall cost-which explains why some enterprises would prefer even tighter EJB-CORBA integration.
The Fortune 1000's Distributed Computing Alignment by the Year 2000
50% Java/COM pragmatists: Will rely on Java development with COM and Microsoft-flavored JVMs (these pragmatists will devote resources to Dynamic HTML and will be prepared to migrate from NT to Unix on the server if necessary) 25% Java/CORBA opportunists: Will rely on Java development with CORBA and without Sun-pure JVMs (these object opponunists will tap COM-CORBA bridges and rely on development tools that make it easy for 4GL programmers to migrate to Java) 20% Low-tech COM adherents: Will rely on Java development, CORBA and Sun-pure JVMs these dreamers will spend 30 percent or more on application development to gain a market edge or leapfrog client/server) 5% Java/CORBA dreamers: Will ignore Java, tap COM and steer clear of Sun-pure JVMs (this low-tech group will probably write in VB, buy inexpensive PCs and rely extensively on packaged applications) Source: Forrester Research
ILLUSTRATION
Title: | CORBA's next revision will show its value. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Discusses the Common Object Request Broker Architecture (CORBA) specification. Key issues on CORBA that resulted to differences in opinion about the specification; Enhancement in CORBA version 3.0; Complimentary to both Microsoft's Component Object Model and Java. |
AN: | 1112550 |
ISSN: | 1096-9969 |
Database: | Academic Search Elite |
Section: INTRANET APPLICATIONS: APPLICATION LOGIC
Specifications lead an interesting life. In particular, take a look at the Common Object Request Broker Architecture specification, which is now entering its third major revision.
CORBA has received many kudos, but it also has received an equal amount of criticism. This vast difference in opinion on CORBA is due to three key issues:
First is the problem it is intended to solve. CORBA is a specification for defining how to integrate apps in a manner that is independent of the development language, hardware and operating system, using an object-oriented programming paradigm.
Second, CORBA defines no implementation detail.
Third, CORBA is defined by a committee whose members are primarily vendors that sell CORBA implementations.
Regardless of where you stand on CORBA, version 3.0 will require many' developers to re-examine their past decisions about this technology.
Today, the CORBA developers are mainly elite programmers with experience building distributed applications using third-generation languages. But this could all change with the appearance of version 3.0 object request brokers (ORBs) on the market. One of the key changes in 3.0 is the development of a CORBA component model and a corresponding scripting language facility. This single addition changes the resource requirements for CORBA to include scripting and RAD programmers as well.
Other additions to the specification include an enhanced persistence service that makes it easier to save and load CORBA objects; asynchronous messaging support for easier operation in an occasionally networked environment; and firewall support for using CORBA in a secure manner from the Internet.
Changes also were made to the naming service to make it easier for ORBs from different vendors to find one another's objects; minimum footprint requirements for embedded CORBA implementations; and requirements for using CORBA in a real-time environment.
The CORBA specification has persevered through rapid changes in the computer industry. It has adapted where necessary to complement both Microsoft's Component Object Model and Java, and remains the pre-eminent leader for large-scale application integration tasks. With version 3.0 implementations, CORBA will once again prove its value to the industry.
PHOTO (COLOR): JP Morgenthal
~~~~~~~~
By JP Morgenthal
JP Morgenthal is president of NC.Focus, which provides strategic planning,
analysis and consulting of application integration technologies. Contact him
with your comments at jp@ncfocus.com.
Title: | OMG to define CORBA 3.0 with EJB support. |
Subject(s): | |
Source: | |
Abstract: | Reports that Object Management Group will define the pending CORBA 3.0 computer program language specification that has an object-packing scheme supporting the Enterprise JavaBeans specification at the Enterprise Comdex in San Francisco, California on September 9, 1998. |
AN: | 1053112 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: NEWS: NEWS BRIEFS
On Sept. 9 at Enterprise Comdex in San Francisco, the Object Management Group
(OMG) will define for the first time the pending CORBA 3.0
specification. New to CORBA 3.0, which will arrive in a
preproduction release in the fourth quarter, will be an object-packing scheme
that supports the Enterprise JavaBeans (EJB) specification. That will allow EJB
to be reusable as CORBA services. Also new are enabling
visual-application envrionments for CORBA component design,
support for CORBA objects on asynchronous real-time
message-queuing transports, a quality-of-service specification, and other
specifications to provide integration with legacy environments.
Title: | Edwards to support COM, CORBA. |
Subject(s): | |
Source: | |
Abstract: | Announces plans of enterprise resource planning vendor, J.D. Edwards to support both Microsoft's Component Object Model (COM) and the Object Management Group's Common Object Request Broker Architecture (CORBA). |
AN: | 854458 |
ISSN: | 1096-9969 |
Database: | Academic Search Elite |
Section: INTRANET APPLICATIONS
IN BRIEF
Enterprise resource planning vendor J.D. Edwards recently unveiled plans to
support both Microsoft's Component Object Model (COM) and the Object Management
Group's Common Object Request Broker Architecture (CORBA). The
company plans to use the component models to better integrate third-party
applications with OneWorld, its suite of products.
Title: | Productivity is the object. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Deals with the debate on the relative merits of object models and component architecture. Why the debate was considered a waste of energy; Pros and cons of Microsoft's COM and Object Management Group's Corba architectures; Implication of the debate. |
AN: | 841031 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
Section: TECH VIEW
The enterprise software and middleware industry spends a healthy amount of energy debating the relative merits of object models and component architectures. Lately, the debate has come down to two major camps: Microsoft and its minions rally around the COM architecture, while a sizable part of the rest of the industry is preaching the virtues of an architecture based on the Object Management Group's Corba.
The question is whether anyone other than the vendors really cares about this debate, or whether the participants are having delusions of grandeur. Under current conditions, the debate seems like a waste of oxygen.
There's a simple explanation for this--right now, those of us who have to actually work with technology to solve problems are more focused on being productive than on what the underlying technology is. Architecture seems to be the furthest thing from most IT professionals' mind right now--their plates are too full with other concerns, like year 2000 problems and demand for Web applications.
And it's not as if an emphasis on architecture would buy anyone any additional productivity right now. Religious dedication to one or the other doesn't particularly lend itself to quick solutions to enterprisewide problems. Both Corba and COM have their shortcomings for example, the absence of a common implementation of Corba, and the limited manageability and scalability in COM.
There are other problems with neat compartmentalization of this debate. Even though Corba is the richer of the two architectures, it is also the slower-moving of the two. Microsoft can issue a new specification for its architecture to adapt to new technologies once a week if it wants to and sometimes, that seems to be the case.
Corba is driven by approval committees, and some parts of its functionality progress faster than others. The result may be that Corba goes the way of ODI in the networking world, with the most useful pieces such as IIOP and some of Corba's brokering services outlasting the standard itself.
Microsoft's architecture clearly isn't a single best answer either. While Microsoft has brought COM along quickly, the Distributed interNet Application "architecture" is still a year or two away from providing even a majority of the pieces required of the solution.
In the interim, anyone seeking to build large, complex applications will end
up having to rely upon a piece of this, a piece of that, and some vendor's
proprietary implementation of both in order to get any solution out the door
quickly. That doesn't make for pretty IT, and it's not exactly a long-term
strategy for success. But who thinks long-term these days anyway? Let's just get
past next year first.
--Sean Gallagher can be reached at sgallagh@cmp.com
~~~~~~~~
By Sean Gallagher
Title: | CORBA 3 on deck. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports that Irish firm Iona Technologies Ltd. will release its next-generation object transaction monitor and integration tool codenamed Art which will support Object Management Group's CORBA 3 object specification. Art's capability to dynamically load components, transport, transaction and messaging protocols. |
AN: | 818252 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
CORBA 3 ON DECK
Iona Technologies will become one of the first middleware providers to move to a protocol-independent component-based architecture with the release of its next-generation object transaction monitor -- code-name Art -- later this year.
This new architecture will give developers an integration tool that dynamically straddles the major competing object models, such as Microsoft's Component Object Model (COM), Sun Microsystems' JavaBeans, and the Object Management Groups (OMG's) CORBA.
These technologies have been locked in academic battles, forcing customers to either chose only one or use bridges that function as gateways between different implementations.
Art achieves protocol-independence through support for the OMG's CORBA 3 object specification, which allows Art to dynamically load components, as well as transport, transaction, and messaging protocols, according to Annrai O'Toole, Iona's chief technology officer.
"Art is like an empty shell with a small kernel," O'Toole said. "It not only loads the object but it also loads what it needs to run that object"
This means that when Art encounters an Enterprise JavaBean (EJB) it will load a Java virtual machine at run time and run the objects.
"The key is that it will load any component or object," O'Toole said. "We are calling these objects '*.Objects.'"
Iona will bundle a software development kit (SDK) that will enable third-party vendors to integrate their applications with Art.
This should make it easier to develop applications for Art, according to Mike Gilpin, vice president at the Giga Information Group, a consultancy, in Cambridge, Mass.
"This means that you are not tied to deciding what protocols you have to support when you develop the application," Gilpin said.
Building CORBA-based applications is generally perceived to be a black art because of the complexity of using Interface Definition Language, or IDL. However, according to O'Toole, the company will soon be making some partnership announcements with tools vendors that are intended to help those difficulties.
"With Art it will be possible to build components through a graphical user interface," O'Toole said.
The technology is being developed in Ionas Boston facility by the ex-Hewlett-Packard object request broker guru Steve Vinoski, and will be designed to support services including events, transactions, trader, and security, and it will also support features of CORBA 3, such as portable object adapters.
However, Iona is not currently a licensee of Sun's server-side COM EJB, but will support the model in future releases of its product, according to O'Toole.
Art will be rolled out as Orbix, Version 4.0, toward the end of this year and will go into early pre-release in the third quarter.
Iona Technologies, in Dublin, Ireland, can be reached at 35 (31) 662-5255 or http://www.iona.com.
~~~~~~~~
By Niall McKay
Title: | Link systems integration to business benefits. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Opinion. Discusses problems encountered in the banking industry as it pertains to systems universality, while suggesting that banks link their computer systems to accommodate their customers. Complications affecting the universality of banking systems; Advantages of product customer linkages; Reference to the Common Object Request Broker Architecture system (COBRA); How CORBA can facilitate the integration of banking systems to accommodate customers. |
AN: | 730342 |
ISSN: | 0002-7561 |
Database: | Academic Search Elite |
Section: Technology
Comment
Systems universality-one of banking's largest goals-is also one of its most elusive and expensive.
The ability to consolidate and use any and all data pertinent to a transaction, customer, or product is lacking in most large banks today. For example, most customers cannot get a mortgage balance or a mutual fund return by visiting a bank branch; rather, they must place a phone call.
When it comes to determining the services an individual uses, most large banks are hamstrung by their systems. The situation is only becoming worse as banks expand into areas such as brokerage, indirect lending, and life insurance.
Nonetheless, the strategy of adding products to maximize the ability to cross-sell and ultimately cement lifetime customer relationships is in vogue.
Anyone following this year's mergers knows that the Citigroup transaction assumes improvements in front office cross-selling and customer relationships, not back-office rationalization.
Even before the merger wave, the advent of multiple delivery channels was driving banks toward the same end. With usage of the Internet and call centers increasing, customers will expect to have access to all their accounts or products, to open new services easily, and to see data that is consistent and correct regardless of channel.
The increasing complexity and proliferation of products also is leading toward systems universality. The implication of the highly touted "market of one" is a very tailored, complex product mix. High-volume distribution also has made it less expensive to put extra products-like credit cards-in people's pockets.
With bank products becoming commodities, product-customer linkages offer a new way to differentiate. The result is the absolute need to have a complete view of the customer, to know when to cross-sell, to have data consistent between channels, and to ensure any decisions on customer treatment reflect customer-specific data, not rote or mechanistic rules.
But systems universality is very expensive, mainly because of banks' "stovepipe" systems and the sheer volume of data banks possess.
Stovepipes are specialty systems that handle specific products or transactions and create or use highly specific data. For example, a deposit system is precisely tailored for what it does; no other system needs to post 20 million debits per night. Theorists decry stovepipes in favor of integrated systems, but for several reasons stovepipes are not likely to vanish soon.
Also creating difficulties and driving up costs is the increasing volume of data. Each time a transaction occurs-at the ATM, call center, Internet, or branch-a record is captured and stored somewhere in the systems. Even daily balances of funds or investments can be tracked.
The issue then becomes: what data to access, when, and why. The possible combinations are endless, and the number of calculations and statistics that could be derived are astronomical.
Complicating the issue is the fact that banking is a mass production business. A sophisticated data mining tool might let a skilled analyst investigate all data pertaining to one customer. But unless the customer is a large corporation, this will never pay off. For the hundreds of millions of retail customers, simplifications must be made. Banks end up trying to find simple combinations of data that can be matched across a wide array of customers.
To cope, a cost-benefit ratio must be applied to systems universally.
Picture the banking industry as a large cubed matrix. Down one side run about 150 lines of business, ranging from stock transfer to factoring. Down another side run the channels used for reaching the customer. Down the third side run aggregations of customer groupings, ranging from wealthy families to small businesses to importers-exporters. There would be about 50,000 cells in all, reflecting about 10 channels and 30 to 40 major customer groupings.
If only 20% of the cells have a combination of product, channel, and customer group that makes business sense, there are 10,000 viable units. Within each, there is the potential for at least one shared application system. Certain cells share common channels, for example, both the equity mutual fund cell and the securities cell go through the broker channel. Other cells have common back-end reporting or analysis.
The result is an extremely complex matrix. Connecting all these cells, for example, through true systems universality would require about 50 million connections. Even if none of the retail cells were connected to any of the wholesale cells, we could still envision a reduced set of high-probability connections in the millions.
Take some examples from Citigroup. In its commercial lines business, Travelers Group writes involuntary workers compensation pool coverage. Should the systems that support that line of business be connected with Citibank's retail businesses? Presumably not, so performing that cost benefit would be easy.
But how about connecting with the Citibank unit that lends to insurance companies and states-the same customer grouping as the involuntary workers comp business? Here the decision isn't so easy and requires in-depth analysis.
On top of the systems work, the people, processes, and policies within and around any cells that get connected may have to be changed dramatically. Training, new products, repricing, or even re-engineering may all be needed. The bottom line is enormous difficulty in determining where cell connections make sense and where they don't.
There are some technology solutions that can help reduce the costs of systems universality. One such trend is called "middleware," a layer of software that sits between all the other applications, such as those in our cells. Instead of a separate connection between each set of systems, all systems connect only once, to the middleware.
To make the middleware effective, data must be passed back and forth in a standard way. The best standard for large financial institutions with multiple legacy systems is called CORBA, which stands for Common Object Request Broker Architecture. CORBA is a specification for programmers that is produced and controlled by a nonprofit industry group with some 700 members called the Object Management Group.
Worldwide, financial institutions' spending on CORBA-based middleware is growing about 38% a year and should reach $380 million this year. The spending is touted as a way not only to reduce the cost of systems universality but also to enhance the longevity of banks' legacy systems.
CORBA is not a silver bullet in any way, shape, or form. Talk of systems universality will probably remain just that. Banks that understand this will be the best equipped to avoid wasting costs where no business benefits can be derived.
PHOTO (BLACK & WHITE): Diogo Teixeira
~~~~~~~~
By By DIOGO TEIXEIRA, Tower Group
Title: | Tool stresses interoperability. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on the scheduled unveiling of NobleNet Inc.'s Nouveau compiler-based tool. Automatic generation of communication code for Component Object Model (COM) and Common Object Request Broker Architecture (CORBA); Extension of NobleNet's remote procedure call-based Interface Definition Language; Features of Noveau. |
AN: | 744945 |
ISSN: | 1096-9969 |
Database: | Academic Search Elite |
Section: News & Analysis
A small development tools vendor believes it has the answer not only to COM and CORBA interoperability, but also to integration of the object world with programming's procedural past.
NobleNet Inc. this week will take the wraps off Nouveau, a compiler-based tool that lets developers automatically generate communication code for Component Object Model (COM) and Common Object Request Broker Architecture (CORBA), Java and remote procedure call (RPC) applications.
The new tool offers an alter-native to emerging COM-to-CORBA bridges or component wrapper technologies, which NobleNet executives said come up short anyway.
The company, which was founded in 1991 but just this year received its first venture funding-including an investment from Intel-has some big customers for its current NobleNet RPC technology, including The Sabre Group and Wal-Mart Stores Inc.
But with Nouveau, the company is extending its RPC-based Interface Definition Language (IDL) technology to work with COM, CORBA and Java as well, said Bob Blauth, vice president of marketing at NobleNet.
"We looked at all of these environments and said, 'Is there a common denominator?' " Blauth said. "The common denominator is the IDL. We take any IDL in, compile to a common data representation and put any IDL out."
NobleNet's tricks don't end there. With Nouveau, the developer also has found a way to "use IIOP [Internet Inter-ORB Protocol] to marshal requests between clients and servers so that the client thinks it is always talking to a native server," according to Blauth.
Nouveau also generates open, readable source code, which enables programmers to better understand how the whole thing works, Blauth said.
Meta Group analyst Doug Lynn said, "It's a great idea if it works from a performance perspective. I have to question: Am I going to lose functionality when I do this translation?"
NobleNet's Blauth said the problem to be solved isn't just COM-to-CORBA integration, but interoperability with legacy procedural applications as well.
"Where vendors have fallen down is [when they are] not paying particular attention to the need to bring object and legacy apps together," he said. "We don't ask people to replace investments [in applications] that they've already made."
Nouveau version 1.0 ships July 29 on Windows 95/NT, Sun Solaris, HP-UX, IBM-AIX and SCO Unix. It costs $5,000 for the first developer seat and $1,500 for additional seats, plus a concurrent user license per application server.
Highlights of the company's latest offering:
• Supports interoperability across middleware environments
• Generates CORBA, COM, Java and RPC-based communication code
• Open, readable source code
Source: Noblenet
Chart by Dawn Landi
~~~~~~~~
By Richard Karpinski
Title: | OMG ready to say `I do' to CORBA messaging spec. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports that the Object Management Group is expected to launch the voting process for Common Object Request Broker Architecture (CORBA) Messaging. Benefits of the marriage of CORBA and enterprise messaging; Asynchronous method invocation to CORBA. |
AN: | 744958 |
ISSN: | 1096-9969 |
Database: | Academic Search Elite |
Section: Intranet Applications
CORBA and enterprise messaging are about to be married.
Object Management Group (OMG), caretakers of the Common Object Request Broker Architecture (CORBA)-the standard for object-oriented programming-is expected this week to launch the voting process for CORBA Messaging, a specification that for the first time will bring asynchronous messaging to the CORBA environment.
Among other things, the new capability-which is expected to be approved formally later this summer and deployed in vendor products beginning later this year-will enable CORBA applications to tap into commercial enterprise messaging systems from BEA Systems, IBM, Tibco Inc. and others.
By bringing enterprise-class messaging into the CORBA object world, developers should be able to build more scalable and more robust distributed object applications.
"If you think about CORBA, in order to remain a viable option for the enterprise it really has to be able to live in a world with existing messaging platforms and has to support them," said Judith Hurwitz, president of Hurwitz Consulting.
J.P. Morgenthal, president of consulting company NC.Focus, added, "What's important to walk away with is that OMG is trying to build a generic services layer, such that you could build portable distributed object applications and just hook into any set of ORB services and use them."
CORBA Messaging is not precisely a CORBA service, but rather an extension to the core specification, said David Curtis, OMG's director of platform technology.
Specifically, it brings asyn-chronous method invocation to CORBA. Today, method calls are made synchronously, which means an application makes a call and is blocked until the call is passed back.
A major benefit of this addition is that CORBA applications will be able to take advantage of the more sophisticated message queuing capabilities of products such as BEA's MessageQ and IBM's MQSeries.
"CORBA developers have expressed a strong desire to have some melding of ORBs and the kind of message queuing and middleware products they are using today," Curtis said. "They want the reliability, scalability and load distribution they are used to in their messaging systems, but in the context of the ORB programming model."
Other benefits of CORBA Messaging include enabling disconnected applications, such as the exchange of data between a server and an off-network palm computer, and the addition of quality-of-service metrics to CORBA applications, said Jon Goldberg, senior software engineer at Inrpise Corp. and primary editor of the CORBA Messaging spec.
Messaging and ORB vendors view the CORBA messaging spec as an important step forward.
"Overall, adoption of CORBA within the enterprise has accelerated. Messaging has been on a parallel growth path," said Alistair Rennie, marketing executive for IBM's Component Broker. "A well-architected connection between the two has grown substantially in importance."
Since IBM plays in both the ORB arena with Component Broker and in messaging with MQSeries, Rennie said, it should be fairly simple for the vendor to implement the final CORBA Messaging spec.
Meanwhile, BEA, which last week launched its M3 Object Transaction Monitor, helped draft the CORBA Messaging spec. "CORBA today is basically request- and response-oriented. We'd like to see the architecture support store-and-forward messaging as well. I see it as being very important," said Ed Cobb, technical director of systems architecture for BEA.
The latest draft of CORBA Messaging was put on OMG servers in mid-May. It is expected that OMG task forces will vote on the proposal this week. Next will come an electronic poll of OMG membership, a process that could take several months to complete. Hurwitz, however, criticized the OMG process of bringing new technologies like CORBA Messaging to market. "They are going to start voting, yes, but voting and getting it done are two different things," she said. "The pace of this is probably not what it should be."
~~~~~~~~
By Richard Karpinski
Title: | CORBA runs National Ignition Facility lasers. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports that Lawrence Livermore National Laboratory scientists have chosen Objective Interface's ORBexpress software to run a research laser system. Comments from John Woodruff of Lawrence laboratory; Features and applications. |
AN: | 762220 |
ISSN: | 1046-9079 |
Database: | Academic Search Elite |
Section: PRODUCT APPLICATION DESIGN solutions
Design and development tools
Scientists at the Lawrence Livermore National Laboratory in Livermore, Calif., needed an automated object-oriented software application to run a research laser system. The found their answer with the ORBexpress object request broker developed by Objective Interface systems in Reston, Va.
The laser system, at the National Ignition Facility at the Livermore lab, is part of the Integrated Computer Control System (ICCS), which uses the laser to produce an energy reaction similar to the ignition of a small sun.
"ICCS must be highly automated and robust, and must operate continuously around the clock," says John Woodruff, lead architect for supervisory software at Livermore. Designers are building the software control system with the Ada 95 programming language on a "modern object-oriented software framework that will be extensible and maintainable throughout the facility's lifecycle," Woodruff says.
The software's "reference domain concept allows us to isolate and use multiple versions of application software or operating systems," says Robert Crey, an ICCS computer scientist. "And it is visibly speedier than earlier versions, which is important in applications involving huge amounts of data."
Within the ORBexpress environment, Livermore programmers can develop code that is "reusable across multiple platforms applications, and indeed other projects," Woodruff says. The ICCS is a $1.2 billion laser facility to be completed in 2003 to maintain the U.S. nuclear stockpile without resorting to underground testing.
The system will integrate more than 40,000 control points to manage 192 laser beamlines that deliver 2-megajoule pulses onto a BB-sized fusion fuel capsule in a pulse 25 nanoseconds long to simulate the fusion energy of a sun.
ORBexpress is a third-generation, CORBA 2.2-compliant object request broker.
For more information on ORBexpress or Objective Interface Systems contact
Allison Alberich by phone at 800-800-6477, by fax at 703-295-6501, by post at
Objective Interface Systems, 1892 Preston Dr., Reston, Va., 20191-5448, by
e-mail at info@ois.com, or on the World Wide Web at http://www.ois.com.
Circle 107
~~~~~~~~
By John McHale
Title: | Looking for standard objects. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Deals with the effort of the Object Management Group (OMG) organization to raise standards for risk management software. How the company will use the Corba interface definition language (IDL); Drawback of wrapping established routines; Benefits from introducing Corba to risk management. |
AN: | 612688 |
ISSN: | 1060-989X |
Database: | MasterFILE Premier |
Section: innovations
Until recently, as long as a new risk management product worked reasonably well and did the job of integrating into a firm's established technology, it could anticipate at least a basic acceptance and use on Wall Street. But the Object Management Group (OMG), a non-profit organization founded in 1989 by eight technology companies (now over 800 members) to create a component-based software marketplace, plans to raise the bar on this process. Instead, it wants to measure how good a product is by how easily it integrates with a firm's approach to risk management -- risk management defined by actual business needs rather than by the products available.
To this end, the OMG's Risk Management Working Group has issued a Request for Information (RFI) to anyone who deals with systems that handle financial risk: banks, investment houses, traders, brokers, exchanges, regulators, tax offices and software vendors. The RFI elicits comments and input on the requirements, projects and products related to risk management system interoperability. Its intention is to establish "reusability, portability and interoperability of object-oriented software components in distributed computing environments" (according to information posted on the OMG Web site).
In a way, the RFI aims to take software components to their most flexible state, in order for a firm to be able to purchase a risk management system and then have a standardized way of interfacing to it -- way standard sockets that can plug and play with the rest of the systems. At present, it is often the case that all the connections have to be developed and redeveloped each time something new comes along.
OMG's Corba interface definition language (IDL) will be the technology for expressing the outcomes of the RFI and its subsequent Request for Proposal (RFP). (Corba is a type of middleware code that sits underneath applications and translates while different systems communicate with each other.) "It's a specification, a set of documents, put out by the OMG, that details how any application -- in the Microsoft world, the UNIX world, any program or software -- can communicate seamlessly by using Corba-enabled objects or components," says Doug Moss, spokesman for the working group and division director of the quantitative applications division at Macquarie Bank, in Sidney, Australia. At present, Corba is most extensively used by firms writing entirely new applications. (Motorola has 50 satellites around the earth communicating with each other and the ground using Corba. By mid-'98, this Corba project will enable global cellular communications.) But it's possible to integrate the language into established apps. "We're teasing out the core bits of an app and putting them inside software objects," says Moss. "We create a wrapping of the Corba protocol that allows Java or Excel apps -- any app -- to communicate to the part that is. say. doing some analytical pricing function on a UNIX server, for example."
A potential drawback to wrapping established routines into an object is a slow-down in processing time. But that doesn't have to be the case in using Corba, says Kevin Tyson, who is principal systems architect for consultant firm, Enterprise Engineering Associates, in Marlboro, N.J., and who is on the OMG architecture board. "There are different points at which you can integrate with Corba." For example, an object interface with an app that does transaction processing against a Sybase database can be new code that goes directly against the database, rather than just wrapping the existing code.
Potential benefits abound from introducing Corba to risk management: 1) Being able, for example, to quickly and easily integrate a new program that cuts processing time down from two hours to five seconds-- instead of building it yourself. 2) Outsourcing becomes easier, because you're able to outsource just bits and pieces instead of all or nothing. 3) This, of course, would have an impact on the number of staff needed, says Moss. "You might be able to share those resources with 10 other banks and not lose any competitive advantage since it is such a basic function." 4) Once standards develop, ratings for software components--like ratings for disk drive efficiency -- would become possible. "It will be like authorized Mercedes parts for your Mercedes automobile," says Moss.
PHOTO (COLOR): The Object Management Group's request for information can be found on the group's Web site at www.omg.org
~~~~~~~~
By Laure Edwards
Title: | Distributed object dreams. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Presents Object Management Group's Corba standard. Capability of the Corba standard; Features of Corba; Java's Remote Method Interface (RMI); Alliance between Java and Corba. |
AN: | 633084 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
Section: Behind the News
DEVELOPMENTS
Computing utopians have dreamt of a day when many kinds of applications running on many kinds of hardware and software platforms would seamlessly interact with one another. Platform interoperability, we visionaries foresaw, would honor software legacies, give users maximum choice, and simultaneously enable applications to work together to accomplish increasingly ambitious tasks with ever-greater efficiency. A series of advances--PCs, client-server, objects, the Web--all seemed to be major steps toward platform openness, but the goal has remained elusive.
The most promising development of recent years has been the Object Management Group's Corba standard. Corba provides standardized plumbing for connecting heterogeneous objects written specifically to their home platforms. It lets these objects communicate with one another. Corba now has several years worth of enhancements behind it, and the support of hundreds of vendor-partners. Building applications with Corba is quite rewarding, but it's also very complex, requiring specialized skills and strong motivation.
Recently, an exciting alternative has emerged. Java's built-in distributed object mechanism, Remote Method Interface (RMI), makes everything that is hard to do in Corba--debugging, distributed object creation, cleanup--virtually effortless. Credit is due to solid engineering, but RMI's real strength is the power of the Java-based architecture.
Java objects are truly portable. More than that, they are mobile and can move around the network on a moment-by-moment basis. This makes distributing the computing radically easier. Objects don't stay put and shout to each other; they can actually zip over and pay a visit, execute a bit of behavior at the location that makes the most sense, then return home or move somewhere else.
Java objects can execute anywhere because Java works everywhere. This is the advantage of a universal language. While Corba works like a magical translator that lets English speakers, Russian speakers, and Farsi speakers understand each other, RMI gets everybody speaking Esperanto. Conversations are effortless, and everybody can operate equally well in any country.
To old openness idealists like ourselves, RMI presents a quandary. Its amazing interoperability comes at the expense of inclusiveness. Java embraces all platforms, but it talks only to itself and excludes all other object models. Do we really want to cut our C++, Object Cobol, and Smalltalk objects out of the picture entirely?
A Java-Corba alliance is in the works. Sun declared last year that it would make RMI speak Corba's on-the-wire protocol, permitting interoperability with non-Java objects. But you can't use any of the fancy functionality of RMI when talking to a Corba object, so every compromise in this direction removes a little of RMI's raw power.
It would be interesting to let the best mix of Corba and RMI emerge over time, but we may not have time. Here, as everywhere else, the Microsoft juggernaut threatens. Microsoft's own Distributed Computing Model is far inferior to either Corba or RMI, totally proprietary, essentially platform-specific, and technologically mediocre. But it comes built into Microsoft products, pushed by Redmond both overtly and covertly. This model for distributed objects will sweep the industry unless the alternative is virtually irresistible.
The dilemma, then, is how much openness we can we afford with Microsoft looming on the distributed-object horizon. How much power and ease of use can RMI give up to achieve a Corba alliance?
Is the sadder but wiser course to go for broke with Java, on the theory that the only way to counter one sweeping world-view juggernaut is with another?
It's wonderful that interoperability really does seem to be within reach, even if not in as pristine a form as we'd once hoped. Our industry, particularly in the Gates era, turns idealists into pragmatists fast.
~~~~~~~~
By Tibbetts & Bernstein
John Tibbetts and Barbara Bernstein are partners in Kinexis, a San Francisco
consulting firm. You can visit them at their Web site at www.kinexis.com.
Title: | Corba vs. DCOM: Does anyone care? |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Provides information on the competition between two distributed object or component softwares, Microsoft Corporation's DCOM and Corba. Effect of a distributed object standards on software reuse and component based development; Various comments about the importance of the systems. INSETS: DCOM and Cobra: Who needs 'em; Merill Lynch digs DCOM. |
AN: | 463302 |
ISSN: | 0897-8085 |
Database: | Academic Search Elite |
Section: Application Development
In the old days, IT organizations often found themselves sucked into marketing battles when new technologies hit the scene. As the vendors duked it out, their corporate IT customers would try to put their money on the best bet--sometimes with disastrous results. But those days are gone. Customers today are more savvy about the ways of vendors and are less likely to buy into their marketing hype--even if it means taking far longer to make purchasing decisions.
Nowhere is this more evident than in the distributed object or component software market. This emerging development strategy could have tremendous impact on IT organizations--lowering development costs through software reuse while making the entire development process more flexible and timely.
Thanks to its potential, the distributed object software market is a hotbed of activity, with the battle lines drawn between Microsoft and its allies on one side, and vendors like Oracle, Sun, and IBM--who support the Corba spec--on the other. Despite the awesome firepower of these vendors, few customers seem to be getting rattled by this conflict or hurried into making a decision. Instead, they are approaching distributed objects as a business issue and are crafting strategies based on their existing infrastructure and business requirements. To avoid being victimized as early adopters, most IT shops are proceeding cautiously, experimenting with ad hoc solutions rather than buying into one architectural vision or another.
"We are playing this a little loosely," says Ron Heiner, a consultant with Boardroom Inc., a publisher in Greenwich, Conn. Boardroom is a Sybase customer doing some preliminary software component design. "We just don't know what the hot technologies will be next year. So we want to stick with good, sound fundamentals. That means using tools from reliable vendors and using good programming techniques and good relational database design. We aren't in a position where we can spend a huge amount of money every year, so we try to leverage the tools we have."
Heiner is moving toward a multi-tier architecture, adding a Sybase Power-Dynamo application server that will let Boardroom run Web sites from its database. While Heiner is skeptical about the Corba vs. DCOM battle, he expects multiple tiers and component software to bring him greater flexibility. "The marketing people are constantly coming up with new ways to do business," he says. "The only way we can adequately prepare for that is to design a system that will be as nimble as possible."
Despite the technical issues that make choosing component suppliers complicated, the decision to select one set of distributed object standards over another is primarily a business issue. Few IS shops are willing to rip out their existing infrastructure so they can adopt a particular flavor of object standards.
"In reality, it's the hottest solution looking for a problem," says Tom Loane, senior VP and CIO at Transport International Pool, a GE Capital company. "If you rate the problems that we are trying to solve this week, it isn't on the list. It is not ahead of Y2K or the Euro. But it's a method for new development, so it's wonderful for the consulting community to shove around."
Like his colleagues in other companies, Loane is leery of buying into any architectural vision that makes his existing infrastructure obsolete. "We are heavily invested in PowerBuilder and we wouldn't throw that away," says Loane.
A similar attitude prevails at the Wholesale Markets Division of GTE. Their long-term strategy is to adopt a distributed object architecture, but they're in no hurry, either. "It is just not a short-term solution," says Cliff Belliveau, a technical lead for the division. Currently, Belliveau is working on a data access application based on components. "Longer term, we are moving to distributed objects, but you can't get there all at once," he says.
Belliveau echoes the same disenchantment with Corba/DCOM as his colleagues, and says the only sensible approach to distributed object standards today is an incremental one. "There's a lot of `this vs. that' right now, so companies are cautious and not ready to spend lots of dollars on big projects."
In the Microsoft model of distributed object computing, customers use Visual Studio to create reusable ActiveX components based on DCOM, the rules describing how objects are designed so they can be distributed across a network. The development environmental includes a standard notation system and repository so the components can be labeled, found, and reused. Components are dropped into Microsoft Transaction Server (MTS), a distributed app server whose message-oriented middleware and transaction services can be used to package and deploy components in multi-tiered apps. The sole proviso is that these applications must run in a Windows NT environment. Companies that are ripping out Unix or avoiding it altogether in favor of NT say ActiveX, DCOM, and MTS make the most sense for them.
The principal alternative to Microsoft is the OMG's Corba spec. Theoretically, Corba ensures platform and application interoperability by establishing middleware standards for ORBs and related services that allow components to work with each other, The OMG has selected notation language and defined repository standards to support reuse. Organizations with a mix of mainframes, Unix servers, and Wintel desktops tend to lean toward distributed objects la Corba.
Financial Services
Merrill Lynch and Co. is currently putting the final touches on a component-based order management system that should be ready for prime time in Q2/98. The software, which uses Microsoft' DCOM interfaces and was written in Visual C++ and Visual Basic, is a multi-tier, component-based system with interfaces to series of heterogeneous data sources at the back end.
The components software will support a mission-critical order management application and will be used both internally by some 25,000 Merrill Lynch financial consultants as well as externally by customers placing orders electronically.
Andy Spicer, director of order management system, says a chief benefit of the components-based design was ability to use the same software in different configurations for both internal and external order management systems. In effect, Spicer's staff was able to put different pieces of the code on different tiers to achieve maximum efficiencies for these related, but distinct, order management applications.
In the internal order management process, financial consultants need to perform immediate order validation and therefore needed a fat client with business intelligence up close on the workstations. For external orders, the validation doesn't need to happen in realtime and therefore that code didn't need to reside on the front end. There, a thin client was appropriate.
"Our business is extremely dynamic and we need to respond even faster than in the past," says Spicer. "So the business rules are their own component and it is dependent on interaction with other software. We don't have to risk breaking the system to change them."
In the internal order management system, the client-side software contains user interface and business rules components, as well as some communications components. The middle tier is Microsoft's IIS 4.0 and MTS 2.0. This NT 0based transactions server handles the communications to the back-end data sources on the third tier. The third tier relies on IBM MVS, with Tandem and Stratus hardware running DB2, DB2/6000, and IMS.
Spicer and his team evaluated the distributed object models of both Microsoft and the OMG before choosing DCOM. They observes some glitches in cross-platform compatibility in Corba implementations. "Plus," says Spicer," we had existing skill set in Microsoft and there had to be compelling reason to move away from that." He adds, "Microsoft offers me a complete suite of product in this space. The products may not always be best, but they continue to make them better."
When evaluating development tools, how important are the following OO capabilities? More important Supports Corba 3.25 Supports object databases 3.92 Supports Microsoft's DCOM 3.92 Supports object languages like C++ 4.14 Supports objects access in relational databases 4.29
~~~~~~~~
By Rose Cafasso
Title: | Iona pushes CORBA efforts. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on Iona Technologies' unveiling of new products and partnerships designed to push its Orbix object request broker product line into new markets. Hongkong Telecom's signing of an agreement for 100,000 copies of Iona's OrbixWeb for use in set-top-boxes; Release of OrbixMX middleware. |
AN: | 409723 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: CLIENT/SERVER
At its first ever user group meeting last week, Iona Technologies unveiled new products and partnerships designed to push its Orbix object request broker (ORB) product line into new markets.
With the announcements, Iona is hoping to portray the CORBA technology -- upon which its Orbix products are based -- as a viable, mainstream architecture. To that end, the company announced that Hongkong Telecom has signed on for 100,000 copies of Iona's OrbixWeb for use in set-top boxes.
"People are building large-scale systems on CORBA, and it is working ... in the real world," said Mark Evensen, senior manager for research and development at Hongkong Telecom.
Iona unveiled OrbixMX, ORB-based middleware for managing multimedia data and integrating it with an organization's IT infrastructure, said Annrai O'Toole, Iona's chief technology officer. (See "Iona brings Orbix to multimedia, OpenView," March 16, page 6.)
Designed to integrate multimedia with traditional data, OrbixMX consists of Iona's Orbix ORB; Orbix MediaStreams -- based on the CORBA A/V Streams specification -- which initiates, manages, and terminates streams; CORBA Trading and Naming; and Orbix's Internet Inter-ORB Protocol (IIOP) engine, which has a 16KB footprint that allows it to run on small, mobile devices, O'Toole said. It is slated for third-quarter release.
Iona also announced that Hewlett-Packard will sell and support the Orbix product line. And HP revealed plans to integrate Orbix products into a number of its own offerings, including OpenView.
Iona pinned a third-quarter release date on its COMet Server, a bidirectional bridge that integrates Microsoft's Component Object Model (COM) code into a CORBA environment and allows either IIOP or Distributed COM to be the wire protocol, O'Toole said.
And finally, Iona inked a partnership with NEC, which will sell and support the Orbix line, and will allow Iona to offer its implementation of Object Management Group's Notification Service in its product line.
Iona Technologies Inc., in Dublin, Ireland, is at http://www.iona.com.
~~~~~~~~
By Cara Cunningham
Nancy Weil, a Boston correspondent for the IDG News Service, an InfoWorld
affiliate, contributed to this article.
Title: | Sun ISV chooses COM over CORBA. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Deals with the plan of Landmark Graphics company to use Microsoft Corp.'s Component Object Model (COM) for integrating Unix and Windows NT applications. Why the plan concerns computer industry; Implication of the plan on its support with Sun Microsystems Inc.; Background information on the business of Landmark. |
AN: | 405975 |
ISSN: | 0893-8377 |
Database: | MasterFILE Premier |
Section: SOFTWARE
REASON: Got to start somewhere
LANDMARK GRAPHICS, one of Sun Microsystems Inc.'s largest resellers and ISVs, opted to use Microsoft Corp.'s Component Object Model (COM) for integrating Unix and Windows NT applications.
The announcement raised eyebrows because Landmark, based here, chose COM over CORBA, the component model espoused by many Unix and non-Microsoft powers.
Bill Curtis, director of computer science for Landmark, downplayed the significance of this announcement, vis-a-vis Landmark's relationship with Mountain View, Calif.-based Sun, a rival of Microsoft, Redmond, Wash. "The advantage to us is we intend to move forward with a component-type architecture, and you have to start somewhere," he said.
The pact will not diminish Landmark's support for other platforms, Curtis said, adding: "We'll need high-end Unix platforms for years to come, especially for computer graphics applications."
Landmark specializes in oil and gas exploration packages that use graphics-intensive seismic charts.
While Microsoft bragged about the deal, Ted Rozsa, Landmark's director of strategic relationships, said the pact is limited to interoperability and has no effect on Landmark's relationship with Sun or other vendors.
Microsoft has ardently wooed key Sun resellers and ISVs for at least a year, flying in reseller executives to Redmond for high-level briefings. That effort mirrors Microsoft's courting of important ISVs and VARs in the Lotus Development Corp. Notes/Domino communities and Oracle Corp. database developers and partners.
Microsoft has had a particularly vivid love/hate affair with Unix. Two years ago, Microsoft Chairman Bill Gates gave the keynote address at Unix Expo in New York (the show was subsequently renamed Unix and Windows NT Expo). But last May at a Microsoft-sponsored scalability day, Gates slammed Unix/RISC solutions for being expensive and proprietary, compared with Wintel counterparts.
Sun maintained Microsoft overemphasized the Landmark deal and that Landmark remains an important Sun reseller.
~~~~~~~~
BY BARBARA DARROW, Houston
Title: | Vendors queue-up messaging. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on various software industry initiatives in the United States, aimed to provide varying degrees of standard interfaces and methodologies messaging. Companies working to make asynchronous messaging an integral part of their component models; Release of the CORBA 3 specification; Support for asynchronous message-queuing protocols. |
AN: | 287374 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: CLIENT/SERVER
Enterprisewide messaging
Although individual vendors have produced tools and APIs for shielding developers from the complexities of messaging software, several industry initiatives are now under way to provide varying degrees of standard interfaces and methodologies messaging.
The Object Management Group (OMG), Microsoft, and Sun's JavaSoft are all working to make asynchronous messaging -- which handles the transmission of messages between systems at different times, through store-and-forward mechanisms, or message queues -- an integral part of their component models.
With the release of its CORBA 3 specification this year, the OMG will add support of asynchronous messaging to the popular object architecture and services.
CORBA-based object request brokers (ORBs) have leveraged message queueing for some time, but the addition of asynchronous messaging to the CORBA architecture is important from a competitive standpoint, according to Eric Brown, an analyst at Forrester Research, a market research company, in Cambridge, Mass.
"CORBA is a unifying force for IBM, Oracle, Netscape, and Sun to bring together their application-server strategies around a consistent interoperability model as the only viable alternative to Microsoft's model," Brown said. "Asynchronous messaging is a critical component of distributed systems, and it must be expressed through some sort of object model. It's necessary for there to be a meaningful [CORBA] specification that the key vendors can implement."
CORBA 3 will support asynchronous message-queueing protocols as part of the base communications interfaces, so that messages can be passed on to methods for later execution.
The change is seen as essential but not innovative.
"It's not a ground-breaking move, other than the fact that there is a standard," Yefim Natis, research director at the Gartner Group, in Stamford, Conn. "I expect mostly smaller vendors will make the biggest investments in supporting it -- companies like Iona, Visigenic, and BEA, as opposed to IBM and Oracle."
CORBA already supports some asynchronous communications, according to Natis.
The CORBA Dynamic Invocation Interface, which allows client applications to make requests to objects whose definitions and interfaces are unknown when the client application is compiled, already has an asynchronous communications API, although there is no standard method for using it, Natis explained. With CORBA 3, message queueing will be one option, he said.
Asynchronous messaging support in CORBA 3 still will require the use of a message-queueing engine, which will likely become one of the requisite pieces of ORB packaging, according to Natis.
"You need to acquire a messaging engine. The protocol is just a veneer," Natis said. "Then, there has to be a class library that offers the OMG-defined interfaces. So, the ORB gives you an object adapter, IIOP [Internet Inter-ORB Protocol] engine, Interface Definition compiler, and now a messaging engine, with API libraries to include the functions to make calls to this engine."
"You need consistent APIs, because they're easier to learn and design with," Natis said.
Similarly, although in the context of a single-vendor's component scheme, Microsoft's Component Object Model (COM) and forthcoming COM+ represent asynchronous messaging as one of a series of system-level services.
Developers will be able to invoke Microsoft Message Queue Server and Microsoft Transaction Server, Windows NT 5.0's Active Directory, and other services at a higher level through a well-defined interface.
Meanwhile, Sun Microsystems' JavaSoft division is attempting to define a standard messaging API for the Java language that will also be accessible through its Enterprise JavaBeans component model.
However, the effort could prove contentious, according to one analyst.
"JavaSoft is trying to establish a standard API for messaging -- a single API for store and forward, publish and subscribe -- and messaging vendors will have to support it. They're just getting under way, and I expect there's going to be a long, drawn-out battle over the JMS [Java Messaging Service] API," said Anne Thomas, editor in chief of the Patricia Seybold Group's Distributed Computing Monitor, in Boston. "Just look at the Enterprise JavaBeans specification. It took about twice as long as anyone expected, because everyone had an opinion about what it should look like."
Another organization, the Business Quality Messaging special interest group (BQM SIG), headed by IBM, Intel, and Microsoft, has taken a less direct approach to promoting and standardizing message queueing.
Rather than define specific APIs, the group has issued rough functional requirements for systems ranging from e-mail to high-volume message-queueing software.
The BQM SIG's functional requirements, as presented to its parent group, the Enterprise Messaging Association, outline message handling, queueing, transactions, security, and embedding within other applications. To date, the group has been faulted for failing to generate practicable specifications.
The next BQM meeting is slated to take place in March.
~~~~~~~~
By Ted Smalley Bowen
Title: | Component integration. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Focuses on the competing major application models from Microsoft, OMG and Sun Microsystems. Component features added to OMG's Corba 3.0; Difficulty in moving into Sun Microsystems' Enterprise JavaBeans; Licensing deals for Microsoft's COM. |
AN: | 311231 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
Section: Application Development
With every revision, upgrade, iteration, and extension of Web technology, life gets faster and more complicated for corporate developers.
The big question last year was the choice of application model: Microsoft's ActiveX or Sun Microsystems' Java? ActiveX provided a familiar, widely adopted, yet proprietary automation standard. Java, until recently an unproven solution, promised portable applications at the expense of native performance and a new learning curve.
The raging debate turned out to be a colossal waste of time. Neither Java nor ActiveX achieved significant penetration of client-side Web computing. But this year, the application battle will shift to the server, thanks to new component models on tap from the big three standard-bearers: Microsoft, the Object Management Group (OMG), and Sun.
Component Bake-Off
The good news is that interoperability between these competing object standards keeps getting better. The bad news is that corporate architects will still have to make tough technology choices as they design their next-generation applications.
"It used to be you could analyze the requirements, choose a platform and some best-of-breed tools, and you were good to go," says Alexander Pellow, director of Internet technology with Cornerstone Information Services in Austin, Texas. "Now we have to digest a dozen new technologies every week, and test as many as possible, just to keep up. When you think it's safe to settle, something new comes along. It's enough to make you want to go back to client-server."
Among the three major object models--Microsoft's COM, OMG's Corba, and Sun's JavaBeans--slated for dramatic component makeovers this year, Corba is first in line. Version 3.0 promises to upset the component apple cart by making scalable Corba parts available to programmers who have little more than basic scripting skills.
Expected by midyear, Corba 3.0 will include four new component features intended to make the multiplatform model easier to use while retaining compatibility with previous specifications. Standardization on passing of "objects by value," a required component feature, will let systems exchange object data directly, instead of passing mere references or "handles" to objects.
"With pass-by-value, the network could go down or suffer a glitch, but your client workstation would still have the data it needed to operate the software," says J.P. Morgenthal, president of NC.Focus, a distributed-computing consulting firm in Hewlett, N.Y.
Also new will be multiple object interfaces, which will allow components to sport flexible APIs to meet varying requirements, without recoding client applications. Corba components will also use a single event model, and will support introspection (the "interface repository" in OMG vernacular). Introspection lets developers browse and connect to available component services, without requiring source code, which promotes reuse.
Lastly, Corba 3.0 calls for a standardized scripting language that, for the first time, lets developers compose multiplatform solutions on the fly, without knowledge of C++ or other advanced programming skills. In a nutshell, and compared with ActiveX and Java, Corba 3.0 components will have the most open fit for client- and server-side Web development projects.
"It means being able to take Corba components written in any language--Java, C++, Fortran, Cobol, Ada, Smalltalk--and linking them together more easily, not just on the user interface, but also on the server," says Richard Solely, chairman and CEO of OMG in Framingham, Mass. "In a real distributed object system, it's important that server components get reused as heavily as clients across multiple platforms, in a `real' distributed object system."
Baked Beans
At about the same time that OMG delivers Corba 3.0, industry observers expect Sun's Enterprise JavaBeans (EJB) specification to have stabilized, with vendors beginning to deliver beta versions of tools that support the new server-side portable component model.
A preliminary version of the spec was introduced in December at the Internet World trade show in New York.
JavaBeans components, when dispatched to the server under the EJB scheme, automatically gain scalability and enterprise-oriented attributes that client components don't require, such as transaction monitoring and security services. This is a boon for IT shops investing in server-side Java that wish to avoid building their own security infrastructures, or manually fitting homegrown components into established transaction-processing monitors, such as BEA Systems' Enterprise Transaction Framework, IBM's TX Series, NCR's Top End, Sybase's Jaguar Component Transaction Server, and Borland's Midas.
"I'm interested in the turnkey transaction processing and security enhancements," says Charles Nettles, VP of technology at McKesson Corp. in San Francisco, the $18 billion pharmaceutical distributor and large-scale adopter of server-side Java. "We're building our extranet application using server-side Java.
I need robust security, but I hardly feel justified in providing secure ID cards and those kinds of things. That's where EJB gets to be very interesting."
Not Without Pain
Moving to EJB won't be entirely painless since the spec will not provide a clean superset of the JavaBeans desktop-component application programming interfaces. Developers will have to learn some 10 additional methods and radically new visual tools and techniques for encapsulating business rules as objects.
"It's an extension, not a superset," says Sharada Achanta, Sun's product line manager for enterprise Java. "And right now it's just a spec; there are no tools. When the tools arrive, EJB [development] will be very much like rapid application development is today on the client."
Applying RAD to server-side components opens the door for tools, middleware, and application vendors to deliver entire systems as reusable component frameworks. They'll use virtually the same visual development metaphors that dominate client-side GUI building tools. Discrete back-end application services can be browsed, queried, or scripted into working applications, in similar fashion to client-side widgets, with one major difference: It all happens on the server.
Java developers look forward to leveraging RAD technology against the server. "It's rapid development of server applications," says Mark Benerofe, VP of programming and platform development for Sony Online Ventures, a division of Sony Corp. in New York. "EJB does for sever apps what ActiveX and JavaBeans did for clients. You can visually script reusable business objects together into new kinds of systems and applications."
But just as OMG and Sun begin delivering their respective component solutions, Microsoft's COM appears poised to be a spoiler. Once strictly viewed as a proprietary, Windows-only standard, COM is now making serious inroads into OMG's and Sun's once-exclusive multiplatform domains.
Microsoft announced in January a number of cross-platform licensing agreements that will drive COM into the heart of enterprise Unix shops. One of the leading Corba object request broker vendors, Iona Technologies Inc. in Dublin, Ireland, is incorporating native COM into its Orbix ORB for Solaris and Windows NT. Systems vendor Silicon Graphics Inc. in Mountain View, Calif., has agreed to integrate COM into its flagship Irix Unix operating system. Both Iona's and Silicon Graphics' COM implementations are on tap for midyear, and promise seamless interoperability between Windows and Unix application services.
Licensing Deals
All of this comes on the heels of Digital Equipment's agreement to incorporate COM into its OpenVMS and Digital Unix, both of which should be in beta testing. COM has also been licensed by Hewlett-Packard and Siemens Nixdorf Information Systems for use with their respective Unix operating systems.
Microsoft officials say they have no plans to implement Corba or EJB components on Windows platforms, preferring to interoperate through COM instead.
"We're already delivering these capabilities with COM objects under the Microsoft Transaction Server," says Joe Maloney, Microsoft's group manager for objects. "OMG and Sun have only moved from 'slideware' to 'specware.' It's going to be a while before these things come out as code."
Regardless, the ability to hook applications together over multiple operating systems and component standards has some developers salivating, and they are willing to wait for all the pieces to fall into place.
"There is no client or server anymore," says Art Machado, president of the Machado Group LLC, a Web-development consulting firm in Emeryville, Calif. "It's just a lot of distributed components. It now just becomes a deployment issue--where do you want to run them?
COM focus: Microsoft says it has no plans to integrate Corba on Windows.
Enterprise Transaction Framework BEA Systems Inc. Sunnyvale, Calif. 888-232-7878 www.beasys.com Jaguar Component Transaction Server Sybase Emeryville, Calif. 800-879-2273 www.sybase.com Midas Borland International Inc. Scotts Valley, Calif. 800-932-994 www.borland.com Top End NCR Corp. Dayton, Ohio 937-445-5000 www.ncr.com TX Series2 IBM White Plains, N.Y. 800-426-2255 www.software.ibm.com DATA: INFORMATIONWEEK
PHOTO (COLOR): Wealth of choices: Developers see so many Web technologies, it can be hard to choose, says Cornerstone's Pellow.
~~~~~~~~
By Rich Levin
Title: | CORBA vendors mull integration approaches. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Discloses the approaches being considered by object-middleware vendors in the United States on how to interoperate their CORBA-compliant products with the Windows NT-based software. Partnership between Iona Technologies and Microsoft Corp. to let Microsoft's Transaction Server applications interoperate with CORBA-based systems; Addition of Expersoft to the ranks of Visual Edge Software's licensees. |
AN: | 199859 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: NEWS
Transaction servers
As Microsoft's Transaction Server (MTS) begins to gain momentum, object-middleware vendors are debating the best way for their CORBA-compliant products to interoperate with the Windows NT-based software.
One approach, announced last week by Iona Technologies, is to work with Microsoft. The two vendors will join efforts to let MTS applications interoperate with CORBA-based systems that implement CORBA's Object Transaction Service (OTS) by mapping between the semantics of the two transaction systems. Iona has laid the foundation for this work by licensing Microsoft's Component Object Model (COM) technology for its forthcoming OrbixCOMet software, a bridge designed to let messages, but not transactions, pass between the two environments.
"We have a new friend in Microsoft," said Annrai O'Toole, chief technology officer at Iona. "We believe that MTS has improved dramatically since its introduction, and it is now very important that the MTS and CORBA worlds interoperate."
Meanwhile, Visual Edge Software, whose bi-directional COM-to-CORBA Object Bridge is resold by most major CORBA vendors save Iona, this week will announce the addition of Expersoft to the ranks of its licensees.
Unlike Iona's OrbixCOMet bridging technology, which will offer the option of the CORBA Internet Inter-ORB Protocol (IIOP) or Microsoft's Distributed COM (DCOM) as the wire-level protocol, Visual Edge's Object Bridge maps between COM and CORBA at the object level. OrbixCOMet will rely on just-in-time (JIT)-compiled proxies to handle the translation, said Visual Edge president Mike Foody, in Saint Laurent, Quebec.
The latter approach, Foody contends, provides better performance and obviates licensing COM source code from Microsoft, relying instead on publicly available and less transitory specifications.
"You don't need the source code to do this. Iona tried to take DCOM directly off the wire and change it to IIOP, and emulating that externally is not tractable, so [Iona] had to go to license [COM source code]," Foody said. "With JIT compilation, and dealing at the well-specified object level, you just don't need [a source-code license]."
In a similar vein, Foody said Visual Edge's forthcoming work on integrating MTS and OTS will also be feasible without contractual ties to Microsoft.
The adoption of a CORBA component model in the forthcoming CORBA 3.0 architecture update should simplify the integration of MTS and OTS because the latter uses a procedural programming model, according to Mitch Kramer, an analyst at the Patricia Seybold Group, in Boston.
"Should CORBA support that kind of component approach, integration will be easier," Kramer said.
Iona Technologies Inc., in Dublin, Ireland, is at http://www.iona.com/. Microsoft Corp., in Redmond, Wash., is at http://www.microsoft.com/.
~~~~~~~~
By Niall McKay and Ted Smalley Bowen
Title: | Microsoft makes interoperatibility strides. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Describes Microsoft Corp.'s computer products for interoperatibility of computer networks to be released in 1998. Providing of Component Object Model (COM) on Unix systems; Partnership between Microsoft and Iona Technologies to integrate CORBA and COM environments; Contact information. |
AN: | 199885 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: CLIENT/SERVER
Microsoft is ratcheting-up its interoperability offerings with a fresh effort to provide the Component Object Model (COM) on Unix systems, and an unprecedented truce with the CORBA object standard camps, in the form of Iona Technologies' licensing of ActiveX core technologies.
Iona plans next month to deliver OrbixCOMet, a product that will be seen as a bridge between COM and CORBA. The planned initial release, OrbixCOMet Desktop, is an add-on for Windows development tools such as Delphi, Visual Basic, and PowerBuilder, which will allow developers to open Windows applications to integrate with those on Unix, MVS, OS/2, and other platforms, according to Iona officials.
"This marks the beginning of the end of the gap between COM and CORBA," said Bob Muglia, Microsoft's vice president for server applications.
However, despite the apparent collaboration of the two companies, industry watchers warn that there is still a great deal of enmity between them.
As recent as just two weeks ago, Microsoft officials dismissed CORBA as an unsupported, unnecessary technology.
"There is no market in CORBA," said Gary Voth, Microsoft's group manager for platform marketing, "There are only 50,000 or 60,000 deployments of CORBA around the world."
Ironically, Iona has been very critical of Microsoft's component strategy. And Iona officials acknowledge that the driving force behind their decision was Microsoft's Windows dominance, not a warm relationship.
"I think it's fair to say that ourselves and Microsoft will continue to disagree about the importance of CORBA," said Annrai O'Tool, chief technology officer at Iona. "[Microsoft] won't, ain't, and don't support CORBA, but if you happen to be one of the poor unfortunates that is running CORBA, then they will tell you that COMet is the solution." Iona's Orbix is the most common implementation of CORBA.
Joe Maloney, Microsoft's group manager for object marketing, said the company's about-face with regards to linking COM and CORBA was a "real mature move," and a recognition that "there are Unix [systems and] mainframes out there that aren't going to go away."
Microsoft will also announce similar licensing deals with other object request broker vendors in the coming months, Maloney said.
Although Iona and Microsoft are forging better underlying integration between the CORBA and COM environments, developers can expect an even greater variance of the middleware services built on each component model, according to one analyst.
"They may come to some agreement about the lowest level of how components communicate and pass data over a network, but both [camps] are doing asynchronous messaging, security, and transaction services and fleshing out the run-time components for each environment," said Eric Brown, an analyst at Forrester Research in Cambridge, Mass. "This is a continuous process of resolving things that are relatively simple, but [higher-level] things are getting more and more different."
The other half of Microsoft's interoperability story is COM on Unix. Muglia announced last week at the company's Web TechEd conference that later this month Microsoft plans to announce pricing and support for its Unix-COM initiative.
In addition to adding an internal development team, Microsoft will push several of its third-party integrators -- including Vanstar, Andersen Consulting, KPMG, and EDS -- to back the effort.
Silicon Graphics also announced its licensing of COM, and Digital announced a beta release of COM on its OpenVMS operating system, and promised a beta version of the Digital Unix OS to follow.
Microsoft Corp., in Redmond, Wash., can be reached at http://www.microsoft.com/. Iona Technologies Inc., in Dublin, Ireland, can be reached at http://www.iona.com/. Silicon Graphics Inc., in Mountain View, Calif., can be reached at http://www.sgi.com/.
PHOTO (COLOR): ALSO AT WEB TECHED, Microsoft last week rolled-out the beta release of Site Server, Version 3.0.
~~~~~~~~
By Bob Trott and Niall McKay
Ted Smalley Bowen contributed to this article.
Title: | CORBA creeps along. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on the reaction of telecommunications carriers to the Common Object Request Broker Architecture (CORBA) specification. Promotion efforts by a group of vendors; Need for vendors to deploy and implement non-proprietary operating systems; Perception of the immaturity of CORBA. |
AN: | 97677 |
ISSN: | 0040-2656 |
Database: | Academic Search Elite |
Section: Intelligence & Software
Although vendors are lining up behind common object request broker architecture as a key tool for implementing Telecommunications Management Network strategies and providing interoperability between applications, carriers are still leery of the technology.
A core group of vendors, including Iona, Orbix, TSCI, Bull, Nokia and Objective Systems Integrators, has been championing CORBA as a solution for providing flexibility in management and network integration for service providers. Other software vendors, including Hewlett-Packard and Microsoft, have used the technology in other industries where CORBA has become an established architecture for heterogeneous networks, said Jeff Cotrupe, program manager for public network management at Dataquest. "Vendors are moving toward CORBA much more rapidly than their carrier customers. It's very much a vendor-driven technology," he said.
"For carriers, [common management information protocol] has been seen by many as a way to go," said David Friedman, framework product marketing manager for OSI, which unveiled a CORBA component to its NetExpert operations support system (OSS) in December. "The difference is that people who have extensive experience in CMIP are few and far between, while people can become experienced with CORBA in any number of industries. That means that carriers can once again afford to have their own programmers."
To make CORBA work, carriers must have open, non-proprietary operating systems in place. In OSI's case, its new component, CORBA Access, provides a CORBA 2.0-compliant interface for integrating various applications with its NetExpert-based OSSs. It allows users to more easily integrate NetExpert functionality with other OSSs and with applications such as customer service and billing.
The product consists of two parts: an interface definition language (IDL) and a software module called the "caserver," which interacts with object request brokers from the leading CORBA vendors. The caserver interfaces with NetExpert's expert system component and the management information base, which stores states, relationships and objects associated with the network.
"This allows external systems to access, modify, delete or get information from the stored objects," said Friedman. "With that kind of functionality, carriers could use the system to monitor the status of alarms and perform more detailed analyses. Any ideas to make better use of the data in these objects can be put into effect, giving carriers a huge amount of flexibility in the way they do things."
While this flexibility is attractive, CORBA's relative immaturity in the industry is not. Telcos' previous attempts to use the technology have revealed "performance gaps that the carriers couldn't live with," said Cotrupe, although he said the continued evolution of CORBA systems bodes well for the future.
"CORBA's going to go through a period of slow growth," he said, "but eventually these vendors' efforts will yield enough test sites to show the potential. When the market is ready, the vendors will be ready. It'll just take people at the carriers realizing that it doesn't make sense to be disorganized and proprietary anymore."
~~~~~~~~
By Chris Bucholtz, Intelligence & Software Editor
Title: | CORBA standard helps aerospace companies tackle software problems. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on the use of the Common Object Request Broker Architecture (CORBA) standard to bind the different software programming technologies. Use of the standard for aerospace and defense engineering in the United States; Cost and time-saving capabilities of the CORBA standard in terms of systems development; Automation of common network programming tasks. |
AN: | 9711252420 |
ISSN: | 1046-9079 |
Database: | Academic Search Elite |
Section: NEWS
PHOENIX -- The need to cut costs and save time in systems development is leading aerospace and defense engineers to use the Common Object Request Broker Architecture (CORBA) standard to bind different software programming technologies together.
"With the CORBA architecture, we've re-defined the starting point of every new CORBA application we build and we now have the potential to avoid $750,000 in development and implementation costs," says Wayne Haughey, information system group leader at AlliedSignal Engines in Phoenix. "Every CORBA project we start leverages our company investment because our components avoid a combined total of five to six man-years of development and implementation effort."
CORBA is an open distributed object computing infrastructure introduced in 1991 by the Object Management Group in Framingham, Mass. It automates many common network programming tasks such as object registration, location, and activation; request demultiplexing; framing and error-handling; parameter marshaling and demarshaling; and operation dispatching.
Reusable software
The initial launch of the AlliedSignal CORBA project showed engineers in the company's engines division in Phoenix can reduce development costs by $750,000 per new application by using a library of reusable CORBA software components.
Engineers at the Boeing Commercial Aircraft Group in Seattle, meanwhile, are using an object request broker called Orbix from Iona Technologies in Cambridge, Mass., to integrate third-party software applications for a manufacturing re-engineering project.
An object request broker helps software engineers develop CORBA objects, and arranges for objects to access each other at run-time as defined by the CORBA specification.
"Our work in integrating a host of diverse applications into a reliable robust manufacturing infrastructure presented us with a host of challenges," explains Tom Schick, senior vice president at Boeing. "By taking the open standards-based approach offered by Orbix we have been able to develop a full-featured, distributed system which has exceeded our expectations."
CORBA components include: security, persistence, tracing, help, and the ability to send e-mail. Developers can leverage the functionality of each component in application development projects without having to understand the complexity of the component and can focus on providing business solutions.
CORBA has a well-defined abstract interface, a definite interface language, and provides flexibility across applications, says John Siegel, director of domain technology at the Object Management Group. It decouples systems to enable software engineers to modify separate components in isolation, and reduce development costs through shared-application services.
CORBA also defines the interface definition language and the application programming interfaces that enable client/server object interaction within a specific implementation of an object request broker, he says. CORBA 2.0, defines interoperability by specifying how object request brokers from different vendors can interoperate.
Object request broker
Using an object request broker, a client transparently invokes a method on a server object, which can be on the same machine or across a network. It intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results.
The client does not have to know the location of the object, its programming language, its operating system, or any other system aspects that are not part of an object's interface, according to an Object Management Group statement. In so doing, the object request broker provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects different object systems.
The object request brokers also let programmers choose the most appropriate operating system, execution environment, programming language to use for each component of a system under construction, and enable the integration of existing components. CORBA also provides a strong defense against system obsolescence. Software engineers can easily map all common functionality through the object request broker, Siegel says.
An object request broker defines the protocol through the interface definition language -- an implementation language-independent specification.
The interface definition language defines the types of objects by specifying their interfaces. An interface consists of a set of named operations and the parameters to those operations. The language is the means by which a particular object tells its potential clients what operations are available and how they should be revoked. From the interface definition language definitions, it is possible to map CORBA objects into particular programming languages or object systems.
Engineers also can add interfaces to an interface repository service, which represents the components of an interface as objects, permitting runtime access to these components.
The primary components in the CORBA object request broker architecture are: object implementation,; the object request broker, the object request broker interface, the CORBA interface definition language stubs and skeletons, the dynamic revocation interface, the dynamic skeleton interface, and the object adapter.
Another aspect of CORBA is the Internet inter object request broker protocol -- an object request broker transport protocol defined as part of the CORBA 2.0 specification. This protocol enables network objects from several CORBA-compliant object request brokers to interoperate transparently over the Internet.
Different products that have emerged from CORBA object request brokers range from small-footprint "ORBlets" for widely distributed web-based clients, to industrial-strength object request brokers suitable for high-volume mission-critical transactional systems.
Java connection
"Java is the first step toward creating an Object Web, but it is still not enough," say Robert Orfali and Dan Harkey in their book, Client/Server Programming with Java and CORBA. "Java offers tremendous flexibility for distributed application development, but it currently does not support a client/server paradigm. To do this, Java needs to be augmented with a distributed object infrastructure, which is where the Object Management Group's CORBA comes into the picture. CORBA provides the missing link between the Java portable application environment and the world of intergalactic back-end services. The intersection of Java and CORBA object technologies is the natural next step in the evolution of the Object Web."
"The respective object models of Java and CORBA correspond closely to one another-they both support the notion of abstract interfaces distinct from implementations or classes; CORBA interface definition language data types map naturally to Java data types; their interface inheritance mechanisms are nearly identical; CORBA name spaces-modules-map directly onto Java packages;" writes David Curtis, director of platform technology at the Object Management Group. "Java allows you to create portable objects and easily distribute them; CORBA allows you to connect them together and to integrate them with rest of you computing environment-databases, legacy systems, objects or applications written in other languages."
Engineers at the Object Management Group are incorporating support for Java into their architecture, specifying a standard language mapping from interface definition language to Java, and developing specifications for automatically generating interface definition language from Java interfaces, Curtis adds.
"The OMG's membership recognize the importance of Java as a programming platform for distributed object technology, and work proceeds apace to merge the two technologies (Java and CORBA) to produce a combined capability whose whole is more powerful than the sum of its parts."
CORBA's main competition in the middleware solutions market is Distributed Component Object Model from Microsoft Corp. of Redmond, Wash. It is a low-level extension of the Component Object Model, the core object technology within Microsoft's Activex software.
A third distributed object technology, JavaTM RMI (Remote Method Invocation) is part of the Java 1.1 Development Kit, and is a solution for building distributed Java-only applications.
One of the main problems with Distributed Component Object Model is its lack of object-oriented capability, while another strength of CORBA is its security, Siegel says. "One of the goals of our architecture and interface is to distribute object system using well known secure mechanisms such as KERBEROS encryption."
For more information on CORBA contact the Object Management Group by phone at 508-820-4300, by fax at 508-8204303, by mail at Object Management Group, 12 Framingham Corporate Center, 492 Old Connecticut Road, Framingham, Mass., 01701, by e-mail at info@omg. org, or on the World Wide Web at http:// www.omg.org.
~~~~~~~~
By John McHale
Title: | Objects push a paradigm shift in distributed computing. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Focuses on the CORBRA model used for communication programming on the Internet. Information on the applications used in distributed computing; Examination of the Common Object Request Broker Architecture (CORBRA); Information on the software concept based on Remote Procedure Call (RPC). INSETS: Implementing a distributed service with CORBA. |
AN: | 9711170963 |
ISSN: | 0013-4872 |
Database: | Academic Search Elite |
Section: EMBEDDED SYSTEMS
Mating the software and the hardware that power invisible computing
The Common Object Request Broker Architecture Facilitates Work On Applications Without The Worry Of Communication Issues.
The Internet has changed the way the world does business. It also I has given new life to a 20-year old programming methodology---objectoriented programming. The Internet ushered in a world of standardized transport mechanisms, browsers, and distributed applications, then fired our imaginations to figure out how objects could be applied to this global network. Distributed objects became the hottest technology of the year due to three distinct product trends:
• The remarkably rapid acceptance of light objects such as those produced by Sun Microsystems' Java. The objects are simpler to produce than ever, and offer cross-platform capabilities, as well.
• The rise of component-style, object-based architecture in enterprise applications. The basic concept of plugging in additional functionality is being applied to applications ranging from Netscape's Navigator to Oracle's WebServer cartridges to SAP AG's R/3. IT shops are starting to think in similar ways about building functional components for in-house applications.
• The Common Object Request Broker Architecture (CORBA), which is the glue that holds all of these systems together. CORBA allows objects to locate each other and interact on any network, without having to know their implementation. Thus, the vision of truly worldwide interoperable distributed computing can become a reality with objects and CORBA.
The allure of objects is compelling. Distributed objects can unify application architectures in a way that has never been attempted before, providing leaps in improved productivity, as well as cross-platform compatibility. Developers can easily develop, use, or re-use distributed software components that interoperate independently of hardware, network, or software platforms. This feature is particularly important in the embedded systems field where devices may operate without a GUI front end. Objects allow the designer to add incredible functionally such as interactive remote access from a JAVA-based terminal to real-time objects. Objects are also key to the software architecture of today's Internet appliances such as set-top boxes and web phones. However, the challenge of incorporating objects, and more importantly, CORBA is a daunting one.
RPC To Distributed Objects
During the mid-1980s, distributed system architectures were defined by two key software trends: client/server computing based on the concept of Remote Procedure Call (RPC), and object-oriented programming supported by such programming languages as C++. The software became more of a determing factor of the overall system capability than either the hardware or networks. The limitations of the software-constrained architectures often were defined by the implementations of the RPC-based client/server and object-oriented software.
Today, a major architectural shift in the computing industry is taking place again. The distributed characteristics of the client/server computing model are being combined with a systemwide object software perspective, referred to as "distributed-object computing." It is being widely adopted within the embedded systems marketplace for the scalability and functionality offered by distributed objects.
Object-Oriented Programming
Object-oriented programming is a design and program structuring concept. An object is a software component or building block providing some services. The designer only needs to know the interface to the object to access its services. The actual code and data that implement the services within an object are invisible outside of that object. They are encapsulated within the object.
Encapsulating software functions within objects provides a straightforward way of decomposing complex applications and software systems into a set of simpler components implemented as objects, and interacting through their object interfaces. Interface and implementation need not be specified and written at the same time. Different embedded system design and programming teams can separately implement the functions (also called methods) of a set of objects without the need to interact with other teams implementing other objects. A controls expert, for example, can build the control objects, and a less-experienced application engineer can then apply them quickly and correctly. Such an approach is recursive, and objects can be made of other objects of finer grain and so forth.
An important benefit of object-oriented programming is the ability to reuse objects in different contexts. Object software is organized into hierarchical classes and subclasses. Starting from libraries of object classes, engineers can create new classes or extend existing ones by inheriting properties of previously defined classes when new services are needed. Those new classes will then be available for future uses, possibly in different contexts, saving programming, reducing testing, and ensuring consistent operation
Polymorphism is a characteristic that allows object methods to react differently, depending on specific class or subclass membership. For example, this characteristic would allow a pump object to respond differently if it were part of a reactor unit than if it were part of a mixer.
Because the code and data that implement the services of an object are encapsulated within the object, such code and data can evolve over time and be modified without any effect on the use of that object by other objects as long as the object interface does not change. Therefore, software upgrades can be performed transparently on individual parts of the system without impacting others.
In addition, legacy code can be encapsulated into objects by wrapping a software layer that provides the object interface around the old code, allowing current embedded system software to be used as a foundation layer.
Reusability of legacy code, as well as commercial off-the-shelf (COTS) software components enabled by object-oriented programming, allows developers to focus their energy on application-specific objects that implement their own core added-value. This feature makes their products more competitive, and faster to market.
Object-oriented languages have been designed to support that model. Smalltalk was the precursor; C++ was designed as an object-oriented extension of the C language; and Java is the latest born. Eiffel, Ada, and ObjectiveC are other examples of object-oriented programming languages.
Distributed Objects
The client/server model of today's enterprise computing is undergoing a fundamental paradigm shift. The model is moving from the concept of a two-way interaction, supported by the remote procedure call (RPC) paradigm, to the concept of distributed services. In a distributed system, clients request services, and not applications. Clients do not know how and where services are implemented. They only need to know what to ask from a particular service. Services can be programs or data servers, written in any kind of programming language, running on any kind of machine, anywhere on a network. In order to provide a given service, a server can, in turn, ask for other services, and so forth. Complex services can be provided through the cooperation of a multitude of servers.
This very powerful concept is made possible by the introduction of object technology into client/server systems. As seen above, objects provide services through well-defined interfaces. Distributed objects extend access to their services to other objects running on other computers in a network.
Distributed objects don't have to be written in the same programming language or run on the same operating system and computer. Distributed objects are smart pieces of software that can invoke each other's services transparently, anywhere in the network. They can interrogate each other--"tell me what you do." Distributed objects are very dynamic; they come and go, and move around.
Today, the IT industry is building distributed-object applications that span networked desktops and services taking advantage of the increased network bandwidth. Those applications allow geographically separated hardware components to participate in a single computer system, like the Internet does.
The environment that lets objects talk to each other so that developers can share them among different applications, operating systems, and hardware platforms is the Common Architecture Request Broker (CORBA). CORBA is a set of standards developed by the Object Management Group (OMG), which comprises over 700 member companies developing or using distributed-object systems and applications.
CORBA defines a standard language, the interface definition language (IDL), used to express the interfaces to access the services provided by an object. IDL is independent of the programming language used to write the code of client and server objects. Standards for mapping the IDL to common programming languages such as C, C++, or Java have been defined by the OMG.
At runtime, invocation of object services is supported by an object request broker (ORB). The ORB allows objects to interact with each other even when they don't know about each other. It translates service invocation requests and their associated parameters from a client object into the format understandable by the server object. The ORB then transports requests and replies by underlying operating systems and networks (Fig. 1). It acts like a standard software bus that also can interact with proprietary object protocols such as Microsoft's ActiveX (OLE/COM).
A client, in CORBA terminology, is a computational context that makes requests on a CORBA object through one of its references. A CORBA object is an abstract programming entity with an identity, an interface, and an implementation. From a client's perspective, the object's identity is encapsulated within the object's reference.
The interface of a CORBA object is specified in a programming-languageindependent IDL. A client running on the ORB can use anobject reference to make requests in two ways. The most common way is through a compiler-generated stub. Using the stub, a request takes the syntactic form of a native programming-language-obj ect invocation, or function invocation. The advantage of using a stub is that invocations are type checked (dynamic or static check, depending on the programming language used). Moreover, the implementation of stub-based invocation can be highly optimized.
Alternatively, the client can use an object reference together with the dynamic invocation interface (DII). The DII allows a client to make invocations without compile-time knowledge of the object type. Independently of the way the invocation is performed, the ORB directs the request to the server identified by the object reference. A server is a computational context in which the implementation of an object resides. Generally, a server corresponds to a process or task. When a request is received in a server, the server identifies the Object Adapter used by the object implementation. An object adapter is an identifiable entity within the context of a server. A server may support multiple object adapters.
The object adapter is responsible for locating, and possibly creating, a servant incarnating the invoked CORBA object. A servant can be anything executable, for instance a script, but typically it takes the form of a programming language object, such as a C++ object. The object adapter also must locate the skeleton through which the servant can be invoked. Generally, the skeleton can take two forms: static and dynamic. A static, compiler-generated skeleton transforms a request into an appropriate invocation of the servant. A dynamic skeleton uses the dynamic skeleton interface (DSI). When using a dynamic skeleton, the application must provide a generic implementation for all operationsof the CORBA object interface. Finally, the server invokes the servant through the skeleton.
The application code executing in the server must register CORBA objects in an object adapter. This operation is called binding. Also, a binding is an object-adapter-maintained relationship between a CORBA object, and the different elements making up its implementation. Bindings also include skeleton code which allows the object adapter to access the CORBA object incarnated as a programminglanguage-servant object, and code information which allows the ob adapter to locate, and possibly create, a servant object incarnating the voked CORBA object.
Servants are instances tion code while the skeleton is typically provided by the IDL compiler. general, a servant is only associated with the CORBA object during an invocation. A CORBA object need not be incarnated by the same servant each time it is invoked. The mapping of CORBA objects to servants is the sole responsibility of the object adapter (see "Implementing A Distributed Service With CORBA," p. 128).
The ORB
The role of the ORB is to send requests and receive replies, using the services of an underlying transport network (e.g., TCP/IP). However, many embedded-system applications need some control over the execution resources, not only for the application's own use of these resources, but also for the ORB's. Platform-independent abstractions of such resources are provided by a new generation of ORBs targeting real-time embedded systems.
For example, the CORBA ORB standard implemented by Chorus Systems' CHORUS/COOL provides flexible bindings to optimize object invocations depending on an object's location, operating system capabilities, and network protocols. In addition, it's componentized structure allows the optimization of the memory footprint and run-time performance by installing only those ORB services required by the application and the supporting configuration. This design allows minimal ORB profiles well adapted to various embedded system constraints.
Real-Time Is On The Mark
Many of today's embedded systems interact with a physical environment requiring real-time systems in which timing constraints must be met for the application to be correct. The environment produces stimuli, which must be accepted by the system within time constraints. Time-constrained behavior can obviously be critical to not just mission success, but to the safety of property and human life in the case of transportation systems or air-trafficcontrol software.
In addition, most embedded systems need to operate continuously, 24 hours a day, seven days a week, with a behavior that remains acceptable, even in the case of faults. Moreover, distributed embedded systems also need to be integrated with other distributed embedded systems as well as distributed enterprise systems, in multitier architectures. Such multitier architecture includes the control or operational layer, consisting of a network of control computers, connected on an industrial bus in process control systems, or on a signaling network in telecommunications systems.
Many companies building these types of critical systems are looking for the combination of a real-time embedded ORB with a real-time operating system platform that is fully configurable and componentized. For example, the CHORUS/ClassiX communication-oriented RTOS platform can accommodate application-defined policies, taking into account various real-time constraints as well as other embedded systems requirements such as memory footprint. Additionally, there's fine grain management of resources such as thread scheduling, memory management, synchronization, interrupt management, timers, and interprocess communication. It can support simultaneously different system and Application Programming Interfaces (APIs), in particular, for the migration of legacy applications, and conformance with recognized API standards such as RT-POSIX. Finally, it provides non-stop operation features, such as fault confinement, onthe-fly dynamic software reconfiguration, and hot-restart of system and applications.
Before There Were ORBs
Before ORBs came into fashion, the main support for message passing within a system was the RPC. However, RPCs do not offer the simple elegance offered by today's ORBs. RPCs allow communication between network addresses, while ORBs establish communications between objects (Fig. 2).
An RPC is a simple extension of the traditional procedure call programming facility, which refers to a procedure of a program running on a remote computer. This concept was introduced in the mid-70's in a famous research paper by Greg Nelson from DEC Research Center, Palo Alto, Calif. A client thread calls (with some parameters) a remote server procedure which processes the call and provides a reply to the client thread. The client thread remains blocked until the reply comes back from the server. A RPC facility assumes a homogeneous environment between client/server programming languages and execution environments. However, it can be complemented by standard data representation protocol. For example, the External Data Representation (XDR) standard, in order to accommodate different data representations between clients and servers. RPC is a low-level communication mechanism between procedures, within the context of a given programming language, or a given operating system environment. An example is DCE's RPC.
An ORB is a high-level communication mechanism allowing objects to invoke each others services. The main function of an ORB is to accommodate the differences between the client and server object programming language and execution environments, therefore making heterogeneity transparent. In that respect, ORBs encapsulate the RPC mechanism. A given ORB implementation can take advantage of an underlying RPC mechanism (e.g. DCE). If the communication transport layer used by the ORB does not provide an RPC facility, the ORB will need to implement it by itself, as part of its functions.
For a programmer, an ORB is much simpler to use because the ORB will automatically take care of the adjustment of the client's request to the server execution environment. The only thing that the client needs to know is the high-level definition of the server's interface described in IDL. With RPCs only the communication environment is made transparent.
Bottom line, the ORB communication model is much richer, offering naming (instead of network addresses), security, dynamic adaptation, and other powerful features, while providing a very clear and strict framework.
From Islands To Unification
The move toward a distributed object architecture benefits engineers and companies. By removing concerns about architectural constraints, management can focus on process improvements. Future advanced system software architectures for embedded systems will behave like unified automation architectures rather than isolated islands that need to be integrated together.
The technology can be extended out onto the World Wide Web to allow access to complex software applications via browsers, to assist with such critical business operations as inventory, customer orders, and shipping and delivery.
Distributed objects offer an infrastructure that makes it easy to provide a functional analysis of an embedded system without having to worry about the physical construction of the system. This advantage will reduce configuration costs, enable faster start-ups, and increase the capacity to have more secure and reusable code. Object-oriented embedded systems can extend object technology right down to the instrument level. As suppliers shift their focus from dealing with architecture issues to developing distributed-object application components, they can improve the performance of their customer's installations.
DIAGRAM: 1. In the CORBA model objects communicate over a software bus by references. Any object requesting service is a client, and the object supplying the service is the server. Objects communicating on the same machine would not use the transport network. The network is transparent to objects that use it to communicate between separate computers.
DIAGRAM: 2. The remote procedure call (RPC) differs from the ORB model in that the calling process assumes that the server is identical, in terms of protocols, programming language, and operating system environment. RPCs communicate in terms of network addresses, while ORBs communicate by object reference.
~~~~~~~~
By MICHEL GIEN, Chorus Systems, 1999 S. Bascorn Ave., Suite 400, Campbell, CA 95008; (408) 879-4116.
Michel Gien is co-founder and chief technology officer at Chorus Systems. He joined the Cyclades computer network research team at INRIA (French National Institute for Research in Information Sciences) in 1971. In 1979, still at INRIA, he led a project that introduced Unix in France.
IMPLEMENTING A DISTRIBUTED SERVICE WITH CORBA
Title: | SAP pushes ERP technology. |
Subject(s): | |
Source: | |
Abstract: | Presents an interview with SAP USA president Paul Wahl about the company's Internet strategy and alliances. Elements of SAP's Internet business; Use of push products from other vendors; Plans for the future version of R/3; Status of its relationship with Microsoft; Stand on the CORBA/Distributed Component Object Model debate. |
AN: | 9710306817 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: CLIENT/SERVER
Paul Wahl steers SAP toward the Internet
SAP has emerged as the dominant supplier of enterprise resource planning (ERP) software that touches every aspect of enterprise computing. Paul Wahl, president of SAP USA, talked with InfoWorld Editor in Chief Sandy Reed, Executive News Editor Michael Vizard, and Editor at Large Katherine Bull about the company's Internet strategy and alliances.
Where will SAP show up on the Internet?
We've said that there are three elements. One of them is consumer-to-business. We think we've figured out a nice way to get together a very efficient process to take orders over the Internet, ship the product, [and] collect the money. Business-to-business is the other space we are interested in. We said last year that business-to-business is a domain that we were late [in entering]. The third one is the intranet. We need to make sure that our information is being shared with many users in an enterprise or even beyond the enterprise.
I think that on the Internet we can show that with push technology you can get information from this computer to the right people at the right time in the right place. Those are the three cores, and in each of them we are in full deployment and ongoing development.
So the push technology is internally developed? Or are you working with one of the major push vendors?
We're sitting on top of it. We do not have our own push technology.
Will there be a future version of R/3 that will be optimized with push features?
Yes. We already have business workflow integrated in our system. The next step is pushing our processes over mail systems so everything that sits on top of MAPI [Messaging API] or our mail interconnect is a logical extension. In regards to systems integration, I think we will have a business-to-business solution developed as a logical extension of our EDI [electronic data interchange] concept to make sure that it runs on top of a number of zze-business' [electronic-business] infrastructures, whether that's Microsoft, Netscape, or IBM.
How big a threat is Oracle as a competitor in the ERP space, and what is SAP's relationship with Oracle?
It's getting stronger and stronger all of the time. They recognize how important we are for them. SAP has about 30 percent of the business; Oracle [has] about 10 percent. In the license business, SAP is eight to 10 times larger.
Must SAP enter the database business?
No. Databases will become a commodity; they'll eventually become a feature of the operating system.
What's the status of the SAP-Microsoft relationship?
We're neutral on platforms; we don't have a preference. Customers can choose whatever works best for them. As memory becomes cheaper, we'll probably rely on Windows NT even more. About 45 percent of our new shipments are on NT now.
Where does SAP stand on the CORBA/DCOM debate?
We started our development with Microsoft and OLE years ago. Today, we exploit more of DCOM [Distributed Component Object Model] than CORBA because they have more components. The opportunity for us is to source components that we can make cooperate and be part of our environment without development. And wherever we get more of them faster is where we'll go.
PHOTO (COLOR): PAUL WAHL: Oracle recognizes how important we are . . . databases will eventually become a feature of the OS.
~~~~~~~~
By Sandy Reed, Michael Vizard, and Katherine Bull
Title: | SAP and Microsoft differ regarding middleware. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Focuses on the conflict between SAP and Microsoft regarding the control of enterprise-software standards. Consideration of SAP's R/3 as an element within a software infrastructure linked by Microsoft's Common Object Model; SAP's commitment to the Object Management Group's CORBA standard; Challenge facing SAP in limiting Microsoft's object model stronghold. |
AN: | 9710306815 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: CLIENT/SERVER
The smooth business and technology relationship between SAP and Microsoft may hit some bumps in the future as both companies struggle for control of enterprise-software standards.
The two companies are doing great business together: Nearly 45 percent of SAP's R/3 sales are on Windows NT, as are almost 28 percent of all existing R/3 sites.
However, earlier this month at SAP's Technology Days developer conference, in Karlsruhe, Germany, Microsoft Chairman Bill Gates positioned client/server applications such as SAP's R/3 as just one element within a software infrastructure linked by Microsoft's Common Object Model (COM). Gates' presentation clearly raised hackles with some SAP executives present.
Speaking after Gates, Karl-Heinz Hess, SAP executive vice president of system technology development, took pains to stress SAP's commitment to the Object Management Group's CORBA standard, the rival object technology which promises similar software integration but without a Windows-centric view of the world.
Hess was quite clear on where SAP and Microsoft part company.
"Microsoft wants to get into the infrastructure business; [SAP] does not want to be locked into somebody's strategy," Hess said. "We want the possibility of working with other partners and other platforms. I'm not sure that COM should be the only technology we should use. For 25 years, we have done most of the middleware ourselves. I'm not sure we should lose this."
There is a certain irony in SAP crying foul at Microsoft's attempt to control software fundamentals. The company has established dominance in it own market space -- much as Microsoft has with Windows -- and now has a vehicle to extend that dominance outward to other software developers through its Business APIs (BAPIs).
These interfaces that let developers hook their applications into R/3 specify both business and technology processes, and could provide SAP with formidable power in the market for business applications.
The challenge facing SAP in limiting Microsoft's object model stronghold is that the competing CORBA standard has not generated enough momentum to produce a single, dominant object request broker (ORB) that could go head-to-head with Microsoft.
SAP is pinning its hopes on IBM to save the industry from a world in which only Microsoft can provide a coherent object model.
"I guess that IBM will galvanize the CORBA guys into providing value," Hess said.
For at least one analyst, SAP's position on CORBA is full of contradictions.
"SAP has come out with varying statements," said Helmuth Gumbel, managing partner of Strategy Partners International, a consultancy in Scuol, Switzerland. "First it was, we'll support DCOM and CORBA on an equal basis, but it was lip service. As long as Microsoft didn't blunder, they couldn't avoid DCOM. Now they say they'll concentrate on DCOM and support CORBA with Visual Edge."
In August, the company announced that it would work with Visual Edge, a Canadian software vendor with technology that will provide a common interface to different ORBs.
"What the ERP [enterprise resource planning] vendors are going through is kind of a microcosm for how developers must approach this [object model] choice," said John R. Rymer, director of Upstream Consulting, in Emeryville, Calif.
SAP AG, in Walldorf, Germany, can be reached at http://www.sap.com.
DIAGRAM: SAP's Business Application Programming Interfaces (BAPIs)
~~~~~~~~
By Michael Parsons
Stannie Holt contributed to this article.
Title: | Working on the object bus. |
Subject(s): | |
Source: | |
Abstract: | Evaluates the Object Management Group's (OMG) middleware CORBA 2.1 and Microsoft Corp.'s Distributed Component Object Model. Interoperability; Language support; Reliability; Platform support; Developer productivity; Architectures; Capabilities; Object services. |
AN: | 9710306862 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: TEST CENTER ANALYSIS
Distributed onject infrastructure
The Object Management Group and Microsoft are trying to elbow CORBA and DCOM past each another, but neither packs the one-two punch of a complete specification, implemented completely.
As a pioneer of part standardization, Samuel Colt might have appreciated the idea of component software. But however visionary Colt may have been, it is doubtful he ever imagined a lock in Chicago, connected to a stock in Los Angeles, firing a bullet down a barrel in Denver.
For some, distributing and interoperating standardized software components across a network may be a solution looking for a problem (see Enterprise Computing, page 113), but as we move toward increasing componentization and "assembly-line" creation of applications, the logical direction for enterprise computing is toward a standard communication interface for disparate object types on a heterogeneous mix of platforms.
A COMMON LANGUAGE. The challenge of object-based distributed computing lies in building a system that lets software objects transparently communicate and use each other's services, whether the objects are located in the same address space, in different address spaces, or on entirely different machines. Without a way for objects to call one another across a network -- an object bus -- applications are bound to the desktop.
At the crux of discussions concerning object-based distributed computing are two object-bus technologies -- the Object Management Group's (OMG's) CORBA and Microsoft's Distributed Component Object Model (DCOM). The question, of course, is which technology offers a more strategic object platform.
Until fairly recently, you could rely on conventional CORBA-vs.-DCOM wisdom to help you choose what to use and when. CORBA had very little existing desktop presence, so rolling CORBA out to a large user base promised to be an expensive, time-consuming proposition. DCOM, on the other hand, was to be (and is) included in Windows NT 4.0 and is downloadable as an addition for Windows 95. On the server side of things, however, DCOM was available only on NT, and so there was no easy way to put Unix objects on the bus. In contrast, a CORBA object request broker (ORB) was available for almost every important server, and client, platform in existence.
THAT WAS THEN. Things are a little different these days. In the middle of last year, Netscape Communications and Visigenic Software announced a licensing agreement for Netscape to include Visigenic's Java-based VisiBroker ORB in Communicator and SuiteSpot, giving CORBA (or at least Visigenic's version of it) a relatively instantaneous, large user base. Moreover, VisiBroker complies with the CORBA Internet Inter-ORB Protocol (IIOP), which gives it the capability to interoperate with other vendors' IIOP-compliant ORBs.
Microsoft, in turn, has shored up DCOM's platform support by licensing the technology to Software AG, Digital Equipment, and Hewlett-Packard. Software AG has begun shipping EntireX, a DCOM port for Sun's Solaris 2.5 operating system. It is also shipping beta versions of DCOM for Linux 2.0 and Digital Unix 4.0, and the company is planning to release versions for HP's HP-UX, IBM's OS/390, AIX, and OS/400, SCO's UnixWare, Digital's OpenVMS, and Siemens-Nixdorf's SINIX. Digital plans to include DCOM in Digital Unix and OpenVMS, and HP is porting it to HP-UX.
For the truly ambivalent, or for those whose IT strategies necessarily include both CORBA and DCOM, several vendors, including Iona, HP, Digital, and Sun, have developed CORBA-to-DCOM bridges. Finally, the OMG expects to have its COM-CORBA interworking specification adopted soon.
CORBA: DESIGNED FOR THE ENTERPRISE. The CORBA 2.1 specification is a product of the OMG, a consortium comprising more than 760 organizations. CORBA's strength lies in its cross-platform and cross-language capabilities. ORB products support the majority of platforms available on the market, and most commercial ORBs support multiple programming languages, including Ada, C, C++, Cobol, Java, and Smalltalk.
Because the OMG provides vendors with specifications rather than implementation details, all ORBs are not created equal. Some ORB vendors include proprietary extensions to their products, and to take full advantage of those extensions, developers may have to sacrifice cross-ORB interoperability and portability.
CORBA gives a multitier environment an object-oriented programming paradigm. Every application under CORBA, whether running on the client side or server side, is treated as an object. Because server objects can call client objects and vice versa, the traditional distinctions between client and server become blurred.
The central element of the CORBA architecture is the ORB, which passes client requests to, and returns results from, server components locally or remotely located. To a client object, the location of a server object should be transparent. As with DCOM clients, CORBA clients communicate with server components through interfaces that store server components' invocation methods and available functions. These interfaces are defined in the interface definition language (IDL).
To ensure interoperability across languages, operating systems, networks, and ORBs, the OMG provides standard IDL language mappings, such as data-type mapping and exception-handling mapping to increase code reusability. CORBA also supports implementation inheritance, which allows one interface to be derived from another interface and inherit the interface's implementations.
CORBA allows a client component to statically or dynamically invoke a server component. Using static invocation, a client has to specify which server component it would like to invoke and which functions under the server it would like to call. Using dynamic invocation, instead of knowing the server component interfaces in advance, a client discovers a server object at run time through CORBA's Naming Service or Trader Service. Then, it dynamically invokes the server's methods. Compared to static invocation, dynamic invocation offers more flexibility because ORBs can offer new services and interfaces whenever they become available. On the other hand, dynamic invocation is more complex to program and its performance is slower.
To solve CORBA 1.0's interoperability problems, CORBA 2.0 provided a solution: Every CORBA 2.0-compliant ORB either supports IIOP or provides a bridge that translates from one ORB to another. Furthermore, ORBs create a unique reference (called an Interoperable Object Reference, or IOR) for each object. Based on IORs, CORBA applications can find objects located anywhere across the network.
Although not uniformly or particularly well implemented among all ORB vendors, CORBA's security specification provides a more complete security model than that of DCOM. CORBA's security service provides authentication, authorization, encryption, security domains, and even audit services to track the security activities on the network. There also are security interfaces that allow the manipulation of security options from within a client application, and administrative interfaces that allow manipulation of ORB's access-control policies.
In a Distributed Component Environment (DCE), a client may call another object, which may in turn call other objects. CORBA allows administrators to set up an access decision for each calling point that limits this delegation. CORBA's security service allows administrators to choose to audit events by object, object type, operation, and time.
Besides the mechanisms that let objects request each other's services, the OMG also provides specifications under CORBAservices and CORBAfacilities for managing and manipulating objects in the CORBA environment. However, since CORBAservices and CORBAfacilities are not required for CORBA compliance, different vendors may implement different services and facilities. For the most part, the ORBs we tested functioned purely as object brokers, passing requests and returning results. As such, they provided minimal performance monitoring, load-balancing, or fault-tolerance.
TESTING CORBA. Learning the IDL is not difficult, but getting familiar with a command set provided by an ORB vendor can take some time. Working with multiple ORBs compounds the problem, because different ORB vendors may implement different sets of commands. Unlike what Microsoft does for DCOM, most ORB vendors do not provide productivity tools for creating CORBA components except the IDL compiler. The compiler comes with an ORB and generates the client stub and server skeleton based on your IDL code. For client and server component development, generally you will use third-party development tools that compile the same language the ORB uses.
We found that two ORBs from the same vendor running on different platforms communicated well with each other, and we had no trouble calling objects between them. On the other hand, to get a client application on one vendor's ORB to call an object on another vendor's ORB was a little tricky, and we needed to program differently. Specifically, we had to obtain the IOR from the called object's ORB first, use the vendor-provided Naming Service to register the object, then use the same Naming Service to call the object. We thought this would begin to get tedious with a large number of objects.
DCOM: STRONG TOOL SUPPORT. DCOM, Microsoft's distributed-computing strategy, was developed based on the Open Software Foundation's DCE Remote Procedure Call (RPC) protocol. DCOM is an extended version of Microsoft's Component Object Model (COM), which is the foundation technology for ActiveX. The main difference between COM and DCOM is that COM components run on a single machine, whereas DCOM components can be distributed across a network. Despite DCOM's availability on non-Windows platforms, limitations on these platforms make it more useful for Windows environments.
One of the advantages of DCOM is the quality and variety of tools available for creating COM and DCOM components -- C++ tools such as Microsoft Visual C++ and RAID tools such as Microsoft Visual Basic, Delphi, and PowerBuilder. Furthermore, there are a large number of prebuilt, off-the-shelf ActiveX components commercially available.
Like CORBA, DCOM takes an object-oriented approach, with all applications referred to as objects. Under the DCOM environment, client applications communicate with COM objects only through interfaces that contain an array of pointers to available functions under an object.
In COM and in DCOM, interfaces are the key. Components are just the implementations of interfaces. A component can be transparently removed and replaced with another component if the new component supports the same interface. DCOM supports interface inheritance, which means that an interface can be derived from another interface, but the derived interface cannot inherit the components available under the original interface. DCOM does let you reuse existing components by passing another object's interface pointer to clients.
Every object must be registered on the local machine for the client to find the object through its Globally Unique Identifier in the registry. Like CORBA, DCOM supports both dynamic and static object invocation, but the implementations are a little different. Under CORBA, the interface implementation is the same, regardless of the invocation method. DCOM, on the other hand, supports dual interfaces for objects; the different invocation methods need different interface implementations.
To use static invocation, we defined an interface and its components and let Visual C++'s Microsoft Interface Definition Language (MIDL) compiler automatically generate the proxy and stub code that connects to the components. DCOM supports dynamic invocation through the type library, which includes files that describe a component. Client applications obtain interfaces at run time through a COM interface, called IDispatch. The advantage here was that, instead of defining an interface manually and using MIDL to generate proxy and stub code, we were able to use the default IDispatch proxy-stub code.
Both CORBA and DCOM support multithreaded servers. In CORBA, initiation is not necessary before creating a thread; everything is handled by the ORB through an object adapter. DCOM, on the other hand, requires you to initiate COM libraries that are used by threads.
Like CORBA, DCOM also allows existing client and server applications to be distributed across a network by registering and configuring them on the host. To do this, you can use a DCOM configuration tool included with Windows NT, or OLEView, supplied with Microsoft Visual C++ and the Win32 Software Development Kit.
DCOM uses Windows NT's security framework rather than providing its own. For non-NT Windows platforms, DCOM will use the security mechanism available on those platforms and provide a Windows NT-compatible security provider. DCOM provides Access Control Lists, which store users' and groups' access rights for particular components. These lists can be configured using a DCOM configuration tool or by calling the Windows NT registry and Win32 security functions from within a program. DCOM also provides APIs and interfaces that components may use to perform their own security checking. The default security checking will be used if neither client nor server component implements any security checking.
There is no automatic fault tolerance or load-balancing under DCOM. To address these two critical enterprise issues, the Microsoft Transaction Server (MTS) sounds like the most attractive solution compared to the other options suggested by Microsoft because MTS provides transaction rollback and load-balancing features.
If you want to make a go of it without MTS, Microsoft provides a pinging protocol that lets a client detect if a connection to a server still exists or not. If a dead server or broken link is detected, an intelligently designed client can reconnect to the server and deal with lost or inconsistent data, if necessary. But in practice it can take a long time to retrace a program and manually recover data, and a large number of objects pinging each other across the network could introduce significant overhead.
A second possible solution is to install your server components on two different machines and have your clients connect and issue requests to both.
LEARNING GROUND. DCOM is not particularly easy to learn, especially for developers without any OLE background. Even with OLE experience, it may take a while to fully understand exactly how DCOM works. Fortunately, Microsoft provides a great tool, Active Template Library (ATL) for creating DCOM and COM objects.
Through the ATL COM AppWizard, Visual C++ generates most of the behind-the-scenes processes, such as proxy and stub code, and creates necessary COM classes. Through the ATL ObjectWizard, you can select the type of COM objects to insert and configure the object's attributes, such as thread model, interface type, and component aggregation. The wizard then generates more C++ code based on your configuration.
We found that using the wizards let us focus our efforts on implementing component details based on business problems, which shortened the development time. The wizards were also a learning tool; studying the generated code help us learn how COM and DCOM works.
Results at a glance
The Internet-intranet boom has brought distributed object computing back into focus for a lot of people, and riding especially high on this renewed wave of interest are vendors of CORBA- and Distributed Component Object Model (DCOM)-based products. The choice of which to standardize on is not obvious for any except shops that are all Windows 95, Windows NT, or Unix. To further complicate issues, third parties are now porting COM to non-Windows platforms, and strategic licensing agreements are landing CORBA on many more desktops than has previously been the case.
Hoping for a little clarity, we used Microsoft's Visual C++ 5.0 and Windows NT 4.0, Iona's Orbix 2.0 on NT and Sun Solaris, Visigenic's VisiBroker for C++ on NT and Solaris, and IBM's System Object Model 3.0 on NT to poke under the hoods of DCOM and CORBA. We did not set out to conduct a comprehensive evaluation of DCOM and CORBA products, but we got a good sense of the state of the art of the technologies from these established products.
We found that CORBA is a powerful technology for application integration. But if it is to maintain its temporal, if not technological, lead against DCOM, CORBA vendors need to implement the standards faster than they have been. If not, CORBA will be a great technology that no one wants to use.
As for DCOM, Microsoft's allegiance to developers promises to maintain the primacy of COM-based technologies in a great many installations. But without seeing DCOM fully supported across a large number of platforms and provide a better environment for mission-critical applications, we don't believe it is the best choice for enterprise computing yet.
CORBA
Core technology
CORBA leaves little to ask for, and the Object Management Group is rapidly incorporating the missing elements. Language bindings are all but complete, integration with other object buses are around the corner, and development of application frameworks is under way.
Quality of products
Most ORB vendors have done a good job of implementing basic CORBA functions, and the overall platform support can't be beat. But service implementation is still a mixed bag. Most development tools we have seen don't compare well to their Windows counterparts.
(1) Broad platform support -- ORBs implemented on a large number of operating systems
(2) Strong programming language support -- ORBs span all the main languages
(3) Local/remote transparency -- objects can invoke services without needing location details
(4) Static or dynamic method invocation -- ORBs support both
(5) Implementation inheritance -- one interface can inherit another's components
(6) Strong security -- Authentication, authorization, encryption, security domains, and audit services
(7) Reliable cross-ORB behavior -- ORBs interoperated well on different platforms
(8) Multithreaded server support
(9) No initiation necessary for multithreading
(10) Strong fault-tolerance and load-balancing specification
(1) Proprietary extensions to CORBA -- vendors may add nonstandard features that may sacrifice interoperability and portability
(2) Lack of full specification support -- products could go further to supply CORBA-specified services
(3) Large command sets -- learning an ORB vendor's particular commands can be a significant time investment
(4) Nonstandard command sets -- ORB vendors may implement different commands, which compounds the learning headaches in a multi-ORB environment
(5) Lack of development tools -- many ORB vendors don't provide productivity tools for building components
(6) Less-than-straightforward ORB-to-ORB interoperation -- getting a client application on one ORB to call an object on another ORB took more work than we liked
DCOM
Core technology
COM is a solid desktop technology, and its popularity is understandable. But distributing COM objects raises complications that are not well addressed, including the reliance on the operating system for authorization.
Quality of products
The fact that major tool vendors have focused so much attention on making their development frameworks attractive and easy to use is a boon for DCOM developers. Wizards make the jump from COM to DCOM development a lot less painful.
(1) High-quality development tools -- many Windows developers will feel right at home
(2) Handy Microsoft wizards -- they make it easy to generate proxy and stub code and to add COM objects
(3) Large selection of commercially available ActiveX components -- the prevalence of Windows on the desktop has insured that independent software-component developers will think twice before deciding against developing for this platform
(4) Static or dynamic interface support -- developers can take their pick depending on an application's performance and flexibility requirements
(5) Local/remote transparency -- clients can remain blissfully ignorant of server locations
(6) Includes multithreaded server support
(1) Limited operating system availability -- currently, only Windows NT 4.0, Windows 95, and Sun Solaris 2.5 are supported
(2) Interface inheritance only -- an interface can derive from another interface, but the derived interface does not inherit the components available under the original
(3) Different interfaces required for static and dynamic invocation
(4) Initiation of COM libraries required for multithreading
(5) Lack of robust fault-tolerance and load-balancing features --Microsoft offers work-arounds, but the Microsoft Transaction Service is what's needed
(6) Steeper-than-expected learning curve -- good tools notwithstanding, DCOM takes some getting used to, and OLE newbies will find it a challenge
Analysis contents
92 Creating CORBA interfaces
92 CORBA architecture
94 Overview of COM/DCOM
94 Requesting CORBA object services: Interface definition language and bus architecture assure location transparency.
96 Software AG's DCOM porting schedule
96 Developing DCOM interfaces: Wizards and other polished features ease DCOM development.
96 ORB vendors and products
96 Requesting DCOM object services
Exclusively on InfoWorld Electric: Go to http://www.infoworld.com/printlinks/
Creating CORBA interfaces
CORBA development reflects architecture
The method for building a complete CORBA application that uses static invocation reflects the fact that the client needs prior knowledge of the object services it needs to use. So, the client-side and server-side code are compiled and linked to the client stub and server skeleton code in one step.
CORBA architecture
CORBA defines multiple interface types for flexibility
One of the main objectives of the CORBA specification is to provide integration among multiple flavors of client and object implementation. As such, the Object Management Group has placed a heavy emphasis on the standardization of static and dynamic interfaces rather than on specifics of the implementation of the object request broker (ORB) itself.
Overview of COM/DCOM
DCOM provides local/remote transparency for remote servers
Using Component Object Model (COM), clients can access either in-process or local cross-process server objects transparently. Distributed COM (DCOM) adds the capability of calling server objects on remote systems through a remote object proxy and Microsoft's Object Remote Procedure Call (ORPC). Local cross-process calls are made through an operating system-dependent interprocess communication. Like CORBA, DCOM supports both static and dynamic method invocation.
Requesting CORBA object services
Invoking methods using CORBA's static invocation interface
Interface defination language (IDL) stubs and skeletons define CORBA's static mode of invoking objects and accessing their services. Unlike the dynamic invocation interface, which lets clients specify services at run time, static interfaces are defined at compile time. But because it is easier to understand and a more natural invocation procedure, many developers may choose static invocation over the potentially more flexible dynamic method. The diagrams below illustrate static invocation on a single object request broker (ORB) and from one ORB to another. It is important to note that, as with Distributed Component Object Model, the system maintains object location transparency.
Requesting DCOM object services
Invoking methods using Distributed COM
Instantiating a class (also called creating an object) is required before invoking its methods, and to do this, the Component Object Model (COM) library needs to be located on the client. The COM library does not ship with Windows 95, but it can be downloaded from Microsoft's Web site. It is included with Windows NT 4.0.
Developing DCOM interfaces
Visual C++ wizards simplify interface creation
Two of Microsoft's development wizards make building Component Object Model (COM) objects an easy task. The ApplWizard generates a basic skeleton and lets you add your own interface definition language (IDL) code as needed. The ObjectWizard helps you assemble COM object members before final compilation.
Software AG's DCOM porting schedule
Microsoft, the Open Group pave way for DCOM on Unix
With the Open Group now controlling the Distributed Component Object Model (DCOM) specification, a number of Unix vendors, most notably Software AG, are taking the opportunity to widen DCOM's platform presence.
Legend for Chart: A - Platforms B - Expected general availability A B Software AG Americas Sun Solaris Now http://www.sagus.com Digital Unix End of October (703) 860-5050 OS/390 End of November AIX, HP-UX, Linux End of December OpenVMS, OS/400, 1998 SINIX, UnixWare
ORB vendors and products
Purveyors of CORBA-compliant ORBs multiply
Membership in the Object Management Group has increased by about 50 percent during the past two years, the CORBA specification keeps evolving, and object request broker (ORB) vendors are hustling to keep their offerings current.
Legend for Chart: A - Vendor B - Product name C - URL D - Phone A B C D Bea Systems ObjectBroker 3.0[1] http://www.beasys.com (408) 743-4000 Expersoft CORBAplus line http://www.expersoft.com (619) 824-4100 Hewlett-Packard ORB Plus 2.0 http://www.hp.com (650) 968-5600 IBM System Object Model 3.0 Component Broker[2] http://www.ibm.com (520) 574-4600 ICL Dais 3.2 http://www.icl.com (703) 648-3300 Iona Technologies Orbix line http://www.iona.com (800) 672-4948 Sun Microsystems Neo and Joe http://www.sun.com (650) 960-1300 Visigenic Software VisiBroker line http://www.visigenic.com (650) 286-1900
1. Recently acquired from Digital.
2. Currently in beta testing.
PHOTO (COLOR): 94 Requesting CORBA object services: Interface definition language and bus architecture assure location transparency.
DIAGRAM: Development process for static invocation
DIAGRAM: Structure of an ORB
DIAGRAM: Single-ORB request
DIAGRAM: Cross-ORB request
DIAGRAM: COM object development
DIAGRAM: Creating an object
Title: | Managing objects. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Compares Microsoft's middleware Distributed Component Object Model (DCOM) with the CORBA standard. Prematurity of both middleware in handling mission-critical applications; Advantage of CORBA's enterprise services; Interoperability of the two products. INSETS: No big bang; Javabeans and Corba: An odd couple? |
AN: | 9710306863 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: ENTERPRISE COMPUTING
The complex but idealistic goal of distributed objects -- where a single object model lets you rebuild corporate applications by assembling and buying interoperable objects -- has been blown off course.
That's the good news.
What's happened instead is that pragmatic choices over middleware --Microsoft's Distributed Component Object Model (DCOM) vs. a marriage of Java and the CORBA standard -- have overtaken academic discussions of pure object orientation. And simplified objects, or components in the form of JavaBeans and Microsoft's COM, are rapidly taking over as the software building blocks of choice on the Web.
Although simple components are quickly showing up in tools, surveys of corporate end-users show that large-scale distributed object projects are really not common yet. But users are laying the groundwork to build distributed applications with object middleware.
The problem, analysts and users say, is that DCOM, and to a lesser degree CORBA, are not quite mature enough for mission-critical applications because vendors are just beginning to deliver some key services, such as transactions, application and system management, fail-over, and availability.
Because components are taking over as the programming model of choice and object middleware is where all IT organizations are going, what should an IT architect do today?
The answer, says Roy Schulte, vice president and research director in charge of middleware at Stamford, Conn.-based Gartner Group, is to trust today's middleware and design for the future.
"If you design software for components but use the middleware that is mature today -- such as CICS, Tuxedo or even stored procedures -- then you'll be able to come back and wrapper that code and be able to use that code as components for several more years," Schulte says.
With that philosophy in mind, leading-edge companies such as Boeing and Union Bank of Switzerland, are buying into CORBA in a big way. The users that fall into this camp are typically cutting-edge companies that have a lot of resources to devote to CORBA projects, which may not be wide-scale for several years. Union Bank of Switzerland, for instance, is structuring its software infrastructure around business objects that are tied together by CORBA and message-oriented middleware. But this is beginning a pilot phase that should last six to 12 months.
ASSIDUOUS ATTENTION. For now, users and analysts generally accept that the CORBA camp, lead by the Object Management Group (OMG) consortium, has a head start in object middleware, but Microsoft is coming on fast. Its assiduous attention to developers and its ability to ease programming is paying off. The company's rival component object model, COM, and transport protocol, DCOM, are hard wired into its OSes. Rather than presenting an object request broker (ORB) with a C++ or Java toolkit, Microsoft tries to shield developers from the object infrastructure with tools, such as Microsoft Transaction Server and Microsoft Message Queue Server, aimed at Visual Basic programmers.
Additionally, some analysts and users argue that Microsoft has more deliverables in object services than many of the ORB vendors.
"It's not like Microsoft invented the concept of component architectures or the concept of an n-tier architecture," says Dan Greenberg, CEO and chief technology officer at Visteon, a health care ISV in Maitland, Fla. "The net bottom line is Microsoft is doing better job of managing the rollout of this environment. It's a more consistent vision."
Comments like these, lauding Microsoft's thrust into the distributed systems realm, have had a unifying effect on the company's enemies. In the past year, a long list of software vendors from Oracle to Netscape, have licensed third-party ORBs, usually Visigenic's VisiBroker, and pledged support to the Internet Inter-ORB Protocol (IIOP).
This convergence on CORBA and IIOP is not purely political: Vendors are moving their products to an object-based infrastructure, and CORBA middleware, spawned largely from the Unix camp, can boast enterprisewide scalability, an installed base, and a standards-based approach. Once vendors complete the transformation of packaged application to components, corporate developers can write to these interfaces to more easily modify vendors' wares.
Because vendors are taking sides on whether they will implement DCOM or CORBA to break their software into components, it's clear that both models will exist for at least the next five years. The upshot of these competing object models is that users need to plan for both.
"We see the COM/CORBA interface as a requirement. We need to have an interface between purchase systems, and we're not in control of all the elements of the system," says Tom Hein, manager of technology integration at Deere, in Moline, Ill. "Clearly, Microsoft also has a presence in the products we buy. CORBA provides enterprise services that aren't there yet in COM, so our basic strategy is to make appropriate use of both."
LOW-LEVEL INTEROPERABILITY. The vendors are working on improving interoperability, but the results are likely to only address low-level interactions between objects. Vendors recently standardized a DCOM/CORBA bridge, but the results will likely not appear in products until next year. Also, analysts note that protocol-level interoperability does not solve the problem of choosing one object standard over another.
"Interoperability will be at the lowest level," says Ted Schadler, an analyst at Forrester Research, in Cambridge, Mass. "We're not talking about object bridges, we're talking about service bridges. Do the CORBA transaction service and Microsoft transactions work together? No, maybe someday, but it will be lowest common denominator."
Some CORBA critics note that interoperability between competing ORBs --the main purpose of IIOP -- is hardly seamless. For this very reason, the OMG says it will initiate branding services in the form of a test suite set for December release and administered by the Open Group.
Meanwhile, Microsoft has its own plan to provide cross-platform interoperability by porting DCOM to non-Microsoft platforms. Microsoft partner Software AG recently released DCOM on Sun Solaris and will ship DCOM on OS/390 in December, but users note that several tools and services are lacking cross-platform DCOM.
Microsoft Chairman Bill Gates acknowledged that Microsoft's perceived lack of commitment to cross-platform DCOM is a "big issue" and said that the company will support DCOM on Unix and MVS.
Although infrastructure questions such as interoperability are critical to object-middleware adoption, what's holding users back is server services and better development tools.
"One of the biggest decisions to be made is not the ORB itself but the CORBA services it has," says Joe Carroll, assistant director of systems architecture at UBS, in London, who says that security, transactions, naming, and events top his wish list. "Also we need to know the details of the implementation in terms of queuing and events architecture."
Carroll notes his CORBA choices are growing. UBS does not need to buy into an ORB vendor, such as Visigenic or Iona, to build a CORBA system because many middleware vendors are entering the ORB fray. For example, BEA Systems Tuxedo and Tibco's message-queuing software are being modified so that services are exposed with CORBA, JavaBeans, or COM interfaces, paving the way for end-users to introduce more object programming in-house.
MERGING MIDDLEWARE. But even as middleware vendors break into the ORB market and Microsoft rolls out its own wares, the merging of multiple middleware functions is still a work in progress.
"All of these tools, like IBM's Component Broker or the TP [transaction-processing] monitors with ORBs -- none of it is all delivered. Nobody has all the pieces yet, and CORBA doesn't have it all. So it leaves people in a valley," says Sally Cusack, market analyst at Software Productivity group, based in Natick, Mass.
Some users are taking a "wait til objects are ready" view. Retailer and manufacturer The Timberland, in Stratham, N.H., has already bought into IBM's MQSeries. The company plans to integrate distributed object technology as its manufacturing application and message-queuing software make the shift.
"I think [object analysis and design] is great, but it's a big, big mind shift when you have a traditional, non-object-oriented environment," says Dan Grosz, director of business system planning at The Timberland. "The whole life cycle product development changes, not just coding."
But what's really holding up wide-scale adoption of objects is the availability of business objects that are specialized to a specific industry, Grosz says.
"We need objects that we can readily use," Grosz says. "I don't think a company like Timberland will be in pioneering position with almost unlimited resources. If we can buy and sell them, then it makes business sense."
Progress in building business-specific objects is under way.
While the OMG is moving ahead in defining more technical services and promoting ease of use in the CORBA 3.0 specification, the consortium has been signing on end-user groups to help define industry-specific objects. And as Microsoft's COM dominates desktop and packaged applications, these vertical industry groups are also working with Microsoft.
"We're working with both the OMG and Microsoft," says Kevin Schipani, group manager of research and development at the Agency Company Organization for Research and Development, an insurance industry group in Pearl River, N.Y. "We want to broker between them to implement universal standards for the insurance industry. We're extending COM with custom interfaces for insurance with our object model in UML [Unified Modeling Language], so we'll can generate IDL [Interface Definition Language] as well."
These efforts promise a big payback by letting corporations share data with partners over the Net and by promoting a third-party industry of off-the-shelf business objects.
But that's a long-term view. Analysts say that simplified components, slung together with high-level tools, is where the action is at in the near term.
"Any time you see a Web-enabled application, there's very likely a distributed object running somewhere on a server," Forrester's Schadler says. "It's component platforms. The technology formerly known as distributed objects hasn't gone away, it's just changed its spots."
And for deciding which object model is strategic, Gartner's Schulte says a user's operating environment determines a lot.
"There are huge debates about which object model is better, but in the end it's not going to matter ... The Microsoft world is integrated from top to bottom for better or for worse, but if you're looking to talk to Unix servers and mainframes, there will be a variety of tools from CORBA vendors," Schulte says. "Pick an OS, and I'll tell you what object model to choose."
What kinds of middleware are you deploying?
Legend for Chart: A - Now B - In two years A B Remote Procedure Call 42% 28% Transaction-processing monitor 42% 52% Messaging 60% 70% Distributed objects 26% 74%
Results of 50 Fortune 1000 companies interviewed.
SOURCE: FORRESTER RESEARCH
~~~~~~~~
By Martin LaMonica
Ted Smalley Bowen contributed to this article.
Title: | OMG expands CORBA, pledges neutrality. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on the Object Management Group's progress toward expanding its core Common Object Request Broker Architecture (CORBA) technologies. Background information on CORBA; Advancing of the group's business objects frameworks initiative; Contact information. |
AN: | 9710193800 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: CLIENT/SERVER
At its recent member meeting in Dublin, Ireland, The Object Management Group (OMG) made progress toward expanding its core CORBA technologies, advancing its business object frameworks initiative, and shoring-up CORBA interoperability with Microsoft's competing Common Object Model (COM). (See "OMG to address modeling, DCOM bridge," Sept. 15, page 3.)
Also at the OMG meeting, the groups newly appointed Chairman and CEO, Richard Soley, emphasized the need to maintain CORBA's language and platform independence, even while working to support key technologies such as Java.
While underscoring the group's strong commitment to supporting Java, Soley stressed that the CORBA platform and services would remain open.
OMG members reacted negatively to a recent suggestion to replace CORBA Interface Definition Language (IDL) with Java, Soley noted. CORBA IDL links client and server applications to CORBA ORBs, and includes mappings to a number of languages.
"I don't want CORBA Javaized, because Java is not universal. There are other languages with other models," Soley said. "[But] CORBA should be at least as friendly to Java as it is to other languages. We want the mapping to Java to be as natural as possible."
A Java-to-IDL mapping that allows Java programmers to automatically generate IDL, rather than having to wrestle with the complexities of IDL programming, is on tap for later this year, according to Soley.
At the meeting, the group began final balloting on the adoption of the Unified Modeling Language (UML) and a corresponding Meta Object Facility (MOF) -- an extension of its COM-to-CORBA bridge specification, Part B -- and revisions of its original COM-to-CORBA bridge specification, Part A.
All are expected to be adopted by the end of the polling process, which usually lasts 10 weeks or more, according to OMG company officials.
The UML standard promises to simplify the object analysis and design process by providing a lingua franca for the many analysis and design tools on the market, Soley explained. The MOF provides a means of defining and manipulating application meta models.
Part B of the COM-to-CORBA Interworking specification is an extension of the existing COM-to-CORBA bridge that bolsters performance by leveraging Distributed COM, Soley said. The bridge specification includes a mapping, or translation from CORBA IDL to the COM interface definition language, Microsoft's IDL Compiler, and a protocol to handle communications between the components.
"You can use any protocol you want for connecting CORBA and COM components. You can use IIOP [Internet Inter-ORB Protocol], Distributed COM, or a piece of string with two tin cans, but you have to support IIOP to start with [in order to be OMGapproved]," Soley said.
The OMG cannot contractually obligate vendors implementing the COM-to-CORBA bridge to support IIOP, but could refuse to endorse products that don't, or deny any eventual OMG branding, according to Soley.
Responses to the OMG's requests for proposals of CORBA component model and scripting specifications are due in October, according to Soley. The so-called CORBA beans and CORBAscript specifications, along with objects-by-value support in IIOP, a CORBA messaging service, and multiple interface support constitute much of the CORBA 3.0 update due early next year.
The Object Management Group, in Framingham, Mass., can be reached at (508) 820-4300.
• The OMG meeting, held in Dublin, Ireland, the week of Sept. 22, drew roughly 450 members and guests.
~~~~~~~~
By Ted Smalley Bowen
Title: | The Corba alternative. |
Subject(s): | |
Source: | |
Abstract: | Discusses the Common Object Request Broker Architecture (CORBA) open system of designing software and hardware architecture developed by the Object Management Group. Features of the system; Establishment of a client-server relationship between objects. |
AN: | 9711094916 |
ISSN: | 0011-9350 |
Database: | Academic Search Elite |
THE CORBA ALTERNATIVE
Historically, `open systems' have meant that the specification and design of a software or hardware architecture is not controlled by a single vendor. In that respect, since Microsoft is solely responsible for developing Windows NT, COM/OLE is not open. CORBA, (the Common Object Request Broker Architecture), on the other hand, is. This standard is being developed by the Object Management Group (OMG), a consortium of software vendors and end users. Many OMG member companies are developing commercial products that support these standards and/or are developing software that uses it.
CORBA provides the mechanisms by which objects transparently make requests and receive responses, as defined by OMG's Object Request Broker (ORB). The CORBA ORB is an application framework that provides interoperability between objects, built in (possibly) different languages, running on (possibly) different machines in heterogeneous distributed environments.
CORBA is the OMG's answer to the need for interoperability among the rapidly proliferating number of hardware and software products currently available today. Simply stated, CORBA allows applications to communicate with one another no matter where they are located or who has designed them.
CORBA 1.1 was introduced in 1991 and defined the Interface Definition Language (IDL) and the Application Programming Interfaces (API) that enable client/server object interaction within a specific implementation of an ORB. CORBA 2.0, adopted in December of 1994, defines true interoperability by specifying how ORBs from different vendors can interoperate.
ORB is the middleware that establishes the client-server relationships between objects. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The client does not have to be aware of where the object is located, its programming language, its operating system, or any other system aspects that are not part of an object's interface.
In so doing, the ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems.
Fielding typical client/server applications, developers use their own design or a recognised standard to define the protocol to be used between the devices. Protocol definition depends on the implementation language, network transport and a dozen other factors. ORBs simplify this process. With an ORB, the protocol is defined through the application interfaces via a single implementation language-independent specification, the IDL. ORBs also let programmers choose the most appropriate operating system, execution environment and even programming language to use for each component of a system under construction. More importantly, they allow the integration of existing components. In an ORB-based solution, developers simply model the legacy component using the same IDL they use for creating new objects, then write `wrapper' code that translates between the standardised bus and the legacy interfaces.
With CORBA, users gain access to information transparently,
without having to know what software or hardware platform it resides on or where
it is located on a network.
Object Management Group
Tel: US +1 508 820 4300
Enter 477
Title: | Corba provides designer commonality. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on Common Object Request Broker Architecture (Corba) designed by Object Management Group (OMG) to solve interoperability problem applications. Number of companies that participate in the OMG; One of the best-known Component Object Model (COM) application; Reasons why Corba features are important to the tool user. |
AN: | 9710240471 |
ISSN: | 0192-1541 |
Database: | Academic Search Elite |
Section: Embedded Systems
Developers today need to be able to set up their own project-specific tool box from the best task-focused tools on the market, using standard communication mechanisms for plug-and-play interoperability. Middleware technologies have been developed for the very purpose of solving the problem of enabling tools from different vendors to interoperate.
The goal is to provide a "middle layer" of task-specific communication between low-level services (such as operating system, socket or remote procedure calls that are too low level for task-specific integration) and high-level tool functionality (that is, typically dependent on the tool). This communication must be task-centric and therefore independent of OS and hardware platform; location (whether the tools run on the same or different workstations, or what network); programming language; and vendor of origin.
The Common Object Request Broker Architecture (Corba) was designed by the world's leading experts on distributed object-oriented computing, who formed the Object Management Group (OMG) to solve the interoperability problem of independently developed applications in a heterogeneous, distributed computing environment. Some 700 companies currently participate in the OMG, making this nonprofit industry consortium the world's largest for software development. Virtually all vendors involved with software development are OMG members, including Integrated Systems Inc.
Two standards
Today, developers must decide between Corba and the other de facto standard: Microsoft's Component Object Model, or COM. After many iterations, COM has become Microsoft's solution to the component-integration problem on the desktop. Like Corba, COM enables independently developed components to collaborate, and it covers the entire spectrum of components from fine-grained objects to coarse-grained existing applications. One of the best-known COM applications is the integration of Microsoft Word and Microsoft Excel within Microsoft Office.
DCOM is a recent extension to COM that3 enables applications on a network to also access COM, and thus replicates many of Corba's benefits. The primary drawback at this point is that COM is essentially fully supported only on Microsoft Windows desktop platforms. Other platforms--Unix, for example--are only partially supported, if at all. Unlike Corba, there are very few non-Windows applications that use COM.
Outside the desktop, and in particular in the embedded market, the consensus so far rests with Corba. For example, various vendors have announced Corba implementations on the target. On the host, embedded-systems developers typically work in a heterogeneous environment that has to be cross-platform and must talk to the target; the types of tool interoperability required for embedded-systems development tools are far less desktop-centric than they might be, for example, when integrating a word processor and a spreadsheet. And so Corba comes out ahead.
Applications that wish to participate in a Corba-enabled development-tool environment expose a set of objects (in the object-oriented sense) on the Corba object bus. The objects are described in terms of interfaces, making them independent of their implementation (such as programming language or physical location).
For example, if a Corba-enabled debugger wants to give other tools access to the information in the file it is currently displaying, it would expose a Corba object to the bus that provides high-level polymorphic operations that other tools can apply on that file. For a file, these operations might include "print" or "get current selection" or, in case of a debugger, "get list of currently active breakpoints in that file."
Independent interface
The interface of that file object seen by other tools is typically independent of the particularities of the tool that exposes the object: for example, knowledge of a particular command language or output syntax provided by the debugger is not required to be able to obtain the list of breakpoints. As long as tools agree on what a breakpoint and a file is (many debuggers do), an application that accesses a debugger-exposed file object does not need to know or care what debugger product from what vendor it is talking to. This independence of the implementation details of the participating tools makes Corba a very powerful integration solution for development tools in general and embedded development tools in particular.
Corba features are important to the tool user because they enable a paradigm shift in the way embedded development tools are developed, packaged and deployed. What we had in the past were monolithic, single-vendor packages that were jacks of all trade, masters of none. What middleware, and in particular Corba, makes possible is to assemble embedded-systems development environments from a set of component tools independently developed by different vendors, in a project- and user-specific fashion.
An example illustrates this point: the communication of host tools to the target. In the past, every host tool had to know the particularities of the communication channel between the host and the target. Changing or augmenting the protocol on this channel was essentially impossible without compromising on the host tools, because these tools depended on the specific version of this low-level protocol.
Corba provides a middleware layer that enables any host tool to talk to any target using any communication mechanism between host and target; Corba encapsulates the particularities and shields clients from having to know them. Also, a communications server can be replaced by another that uses a different underlying protocol; as long as the new server offers the same set of interface definitions as the old, the client will not notice the change.
Core competency
This, of course, enables a tool vendor to focus on its core competency--building advanced embedded-system development tools. Gone is the need to mess around with low-level proprietary protocols whose support is typically expensive while adding no value to the tool offering and distracting from support of the end user.
From a tool user's perspective, this will mean better tools with more capabilities. It also means being able to select the best tools for a given job, because multiple tools are able to alternate on the same place within a Corba environment--tools that truly interoperate because the tool vendors don't have to rewrite point-to-point interfaces and thus can write off tool integration work over multiple tool integrations.
Corba embeds objects
~~~~~~~~
By Johannes Ernst, Staff Engineer Integrated Systems Inc. Sunnyvale, Calif.
Title: | OMG will adopt COM/CORBA bridges. |
Subject(s): | |
Source: | |
Abstract: | Reports that the Object Management Group began final balloting on the adoption of the Unified Modeling Language and a corresponding Meta Object Facility, and is also voting on an extension of its COM/CORbA bridge specification. |
AN: | 9710066908 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: NEWS; NEWS BRIEFS
The Object Management Group (OMG) last week in Dublin, Ireland, began final
balloting on the adoption of the Unified Modeling Language and a corresponding
Meta Object Facility. The OMG is also voting on an extension of its COM/CORBA
bridge specification, Part B, as well as revisions to its original COM/CORBA
bridge specification, Part A. All are expected to be adopted by the end of the
polling process, which usually takes about 10 or more weeks, according to OMG
officials.
Title: | OMG to address modeling, DCOM bridge. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on the Object Management Group's (OMG) agenda for advancing its CORBA (Common Object Request Broker Architecture) initiative at a meeting in Dublin, Ireland in September 1997. Adoption of a key object-modeling language called Unified Modeling Language; Evaluation of bridging specification between CORBA and Microsoft's Distributed Component Object Model (DCOM). |
AN: | 9709235514 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: NEWS
CORBA initiative
The Object Management Group (OMG) next week in Dublin, Ireland, will advance its CORBA initiative with the expected adoption of a key object-modeling language, and the group will assess the latest proposal for the strategically important -- yet politically sensitive -- bridging specification between CORBA and Microsoft's Distributed Component Object Model (DCOM).
At the OMG Technology Committee Meeting, the OMG's 24-member board of directors will vote on ratification of the Unified Modeling Language as a standard modeling language for components. Rational Software, which took the lead on the initiative, last week submitted the latest UML proposal to the OMG Object Analysis and Design task force.
The OMG will also address its recently launched Component Initiative, which intends to yield a component model and standard scripting language for working with CORBA components as part of CORBA 3.0, due in early 1998.
The JavaBeans component model is expected to be the basis of the CORBA component model, and scripting languages ranging from JavaScript, VBScript, and Perl to Tool Command Language and ObjectRexx are expected to be proposed, said Richard Soley, OMG's chief technical officer and acting chairman and CEO.
Also up for vote by the Technical Committee is the much-anticipated Component Object Model (COM)/CORBA Interworking Part B specification, which allows the existing COM-to-CORBA bridge specification to better handle DCOM.
"Part B extends Part A to get better performance, when you have a [CORBA component communicating with a] COM component across DCOM, as an option to IIOP [Internet Inter-ORB Protocol]," Soley said.
The proposal eliminates the restriction of handling DCOM/IIOP translation only on the COM client.
The proposal reflects changes to Hewlett-Packard's original, which stemmed from input by object request broker and platform vendors, including BEA Systems, Expersoft, Iona Technologies, Visigenic Software, and Visual Edge Software.
The latest proposal steers clear of endorsing DCOM, members said.
A draft proposal for adding asynchronous messaging capabilities to the CORBA services was also to be on the docket for the Dublin meeting. That proposal will instead be presented at the OMG meeting in December, Soley said. The COM/CORBA extension and messaging are slated for CORBA 2.2
"Messaging is probably my biggest concern," said Stephen Uczekaj, senior principal engineer at Boeing, in Seattle. "CORBA needs a data-flow-type architecture, which is critical for the development of embedded applications."
The group will also take up the issue of its leadership, after the departure this summer of President Chris Stone. Soley and Acting President and Chief Operating Officer Bill Hoffman are expected to retain their respective posts on a permanent basis, pending board review.
The Object Management Group, in Framingham, Mass., can be reached at (508) 820-4300.
~~~~~~~~
By Ted Smalley Bowen
Title: | Boeing takes off with objects. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Details on the revamping of outmoded business processes of Boeing Commercial Airplane Group with the help of Orbix products from Iona Technologies. Interoperability between application provided by ORB architecture Corba on Boeing; Services offered by Orbix to Boeing. INSETS: Ins and outs of Orbix; The OMG makes NOIS. |
AN: | 9710056826 |
ISSN: | 0897-8085 |
Database: | Academic Search Elite |
Section: MIDDLEWARE
Facing stiff competition, the airplane manufacturer revamped its outmoded business processes with the help of Iona's Orbix
It might have been Iridium, Motorola's out-of-this-world effort to surround the earth with telecommunications satellites, that put Iona Technologies on the map. But it was another high-flyer, Boeing's Commercial Airplane Group, that locked Dublin-based Iona into a steadier orbit. While applications such as Hong Kong Telecom's video-on-demand system have been providing flashy publicity for the object request broker vendor, Boeing has had its nose to the grindstone redesigning much of what it does here on the ground using Iona's Orbix product. The project, which the airplane manufacturer calls DCAC/MRM (Define and Control Airplane Configuration/Manufacturing Resource Management), entails a wholesale overhaul of its business processes, from design and production to sales and support.
Back in 1994, Boeing began to assess its outmoded practices in light of future competition. As a 75-year-old company that has had to support millions of parts for the duration of their life cycles, Boeing required a continually maintained database of engineering documents covering every part, model, and design. In the past, such complex data was stored in the form of physical part drawings--not the most easily manipulated or integrated data type. Moreover, every customer demands a plane somewhat different from the other guy's, and revising a basic design in one area often necessitates revisions in other areas. The solution to slow, tangled redesigns seemed to lie in the creation of a computerized database of parts, rather than planes, so Boeing created the Single Source of Product Data (SSPD).
The IT team realized that such a change, while meant to facilitate the design process, would simultaneously benefit sales, engineering, and support staffs, who require easy access to airplane configuration details. Thus began what Iona not so humbly calls "the single largest business process redesign project in the world. "
The plane part, after all, is but one of numerous business concepts that have significance across all of Boeing's departments. Like many such business concepts, it lends itself to an object-oriented approach to programming. This approach, if carried through all relevant applications, can facilitate integration throughout the company, as well as between Boeing and its customers and suppliers. In its search for a long-term, object oriented solution, Boeing decided to go with the industry-standard ORB architecture--Corba--to provide interoperability between applications.
Although Corba was still rather young, Boeing threw in its lot with the Object Management Group (OMG), the ORB industry consortium that created the spec. When Boeing's developers found commercial software packages that they thought were best-suited to each process, they asked the vendors to make their products Corba-compliant. These packages include SDRC's Metaphase for product data management, Baan's Enterprise Resource Planner, and CimLinc's Linkage Computer Aided Process-Planning. As a proof-of-concept step, Boeing's development team tried integrating the off-the-shelf products as single objects by writing definitions in Corba IDL encapsulating large chunks of application functionality. When that worked, they began the long and ongoing process of breaking the applications down into smaller business objects that can be shared across applications.
Because a standards-based ORB struck Boeing as key to future stability, the company chose Iona's Orbix. At that time, "Iona was by far the most Corba-compliant," says Van Cleland, Boeing's application integration product manager. Since buying into Corba, the airplane manufacturer has continued to work through the OMG to push for the added capabilities it sees as vital to ORBs--services such as store-and-forward communications and systems management features. One capability that has been in the works this year is a messaging service, which Boeing strongly desires. Standard ORBs, including Orbix, build in IIOP (Internet Inter-ORB Protocol) communications capabilities, but these are based on TCP/IP's point-to-point style of communicating and are therefore limited to synchronous exchanges. Recognizing this limitation, Orbix provides two further options: OrbixTalk, a value-added implementation of the Corba Event Service, which facilitates decoupled messaging between distributed objects; and bridges to IBM's MQSeries message-oriented middleware (MOM) as well as to PeerLogic's Pipes.
Boeing has embraced both of these add-one, using OrbixTalk as a store-and-forward mechanism for asynchronous messaging, and the MQ link for yoking-in legacy systems. "We have quite a few computing systems in place that will be in use for quite some time during the transition," says Cleland. "In fact, some will never go away. And we need to interface with those systems."
At the time Boeing began its project, there was no MVS product from Iona to support legacy links without additional MOM. But that's about to change. Iona has built gateways that allow Orbix to take programs that look like objects on the network, convert them into Cobol code, and send them over to Cobol applications. In a further foray into the mainframe world, Iona is currently beta-testing Orbix bridges to IMS and CICS transaction processing monitors. "We see that as a huge market," says Iona CTO Annrai O'Toole. "The mainframe is here for good. Corporations understand the value of making those systems into peer entities in their networks so that Java applets can call them. Our high-end customers want the mainframe as a client of Unix."
In addition to its array of messaging options, Orbix offers Boeing a multitasking capability, which enables the company to do what Cleland calls "dispersing--where we send to, dial up, and utilize multiple servers at once rather than a single server. " But despite Orbix's plethora of useful features, Cleland claims that his team chose the ORB primarily because it was a "lean implementation.
"They don't build in a whole bunch of extra features you have to take along, with a lot of overhead," he says. "You can use them if you like, but you can also use the ORB just as an ORB."
Still, there are features that ORB makers will all need to develop, Cleland remarks. Like other ORB vendors, "Iona is realizing that the ORB isn't a toy anymore; people are using it as a production product, and it has to be supported as a production product. Things like system management capabilities, security--those capabilities are required in the real world." If ORBs are going to play leading roles in distributed computing systems, they will have to behave more like robust, sturdy, ever-dependable transaction processing monitors, notes Cleland.
If you ask O'Toole, Iona is ahead of the pack on that front. He maintains that his firm understands that the IT world has moved to a network-centric infrastructure. All of this means that companies have to rely on middleware to manage a great deal of communication, and the people in charge of building these infrastructures "need to support lots of different types of transportation as well as transactional semantics--they want all their databases updated or none of them, and they need to do it in a manner that guarantees the security of the operation," he says.
With such complex demands, the average IT department may need a good deal of help implementing a thorough and appropriate middleware strategy. Analysts seem to agree that this is one area where Iona has fallen short. As O'Toole himself admits, the company has primarily worked with a volume sales model-"stick it in the box, and ship it out the door." Donald DePalma, senior analyst at Forrester Research, calls this a "shotgun approach." Iona, he says, will have to "get a little more focused" as the industry matures, working with vertical channel players and tools vendors.
Boeing, however, has not found Iona to be the detached supplier it's painted to be. "We have five Iona consultants on board," says Cleland. "We have found our onsite people very valuable, especially in the early days of distributed computing, when they had the knowledge of how we could implement ORB technology."
Object request brokers mediate between clients and implementations of application objects, using a standard interface. When an object-oriented program calls a remote object, the ORB runs off and retrieves it from wherever it resides, then pulls it into the running program without letting on that it's smuggling in a foreign operator.
As the maker of Orbix, Ione's claim to fame is absolute compliance with the Object Management Group's Corba. Indeed, notes Yefim Natis, research director at the Gartner Group, lone will push proposed additions through the OMG before it puts them in its own product. Orbix implements the Corba capabilities as a pair of runtime libraries--one for client applications and one for servers--and the Orbix activation daemon.
Orbix is available on more than 20 operating systems, including a dozen versions of Unix, Windows for Workgroups 3.11, Windows 95, Windows NT, OS/2, VMS, MVS, pSOS, QNX, VxWorks, and Macintosh.
If you've bought into the object oriented vision and you need your objects distributed across a network, your options have been boiled down to two: Corba, the OMG's set of standards, and DCOM, Microsoft's Distributed Component Object Model, which comes embedded in the Microsoft package that includes Microsoft Transaction Server and Microsoft Message Queue Server.
"Today, if you're a Microsoft shop, there's a predilection to go with what you know, with Visual Basic and PowerBuilder leveraging OLE and ActiveX," says Donald DePalma, senior analyst at Forrester Research. According to DePalma, "DCOM is a natural default" in that arena, whereas the Internet Inter-ORB Protocol (IIOP) used by the Corba crowd would be more of a leap. On the other hand, Microsoft did not invent computing, and most companies require cross-platform communication. For the majority of IS shops, "[IIOP] solves a lot of problems on the back end," says DePalma.
Yefim Natis, research director at the Gartner Group, agrees: "Microsoft does not intend to extend the life of other systems or make it in any way beneficial for users to build systems on other platforms." So while competing with Microsoft on NT poses a significant challenge, most expect the Corba crew to provide a viable alternative to DCOM. "Corba is real, and it works," says lone CTO Anorai O'Toole. "People depend every day on Corba's being around. It's more mature [than DCOM], and it's had the kinks rolled out of it."
"As usual, Microsoft has come up with a technology that solves 40% to 50% of the problem," says DePalma. For many users, that will be enough.
In an effort to step up the kind of cooperation taking place in the OMG, four major industry players have formed what Natis refers to as a "back-room consortium." Called variously NOIS by Natis and "the IIOP gang of four" by DePalma, the group includes Netscape, Oracle, IBM, and Sun. The participants are negotiating over naming, components, scripting, and other features they believe are required for their Corba-based products to succeed.
THE ORBIX 2.1 ARCHITECTURE
SINGLE SOURCE OF PRODUCT DATA (SSPD) FROM BOEING.
~~~~~~~~
By Debra O'Donnell
Title: | Drug firms back move to link databases. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | States that a group of pharmaceutical companies support the development of common standards for the interface of biological databases. The life science database standards to be set by the software consortium Object Management Group; The use of Common Object Request Broker Architecture (CORBA) to permit database communication despite different formats. |
AN: | 9708282530 |
ISSN: | 0036-8075 |
Database: | Academic Search Elite |
Section: RESEARCH NEWS
GENOMICS
Because the world's major biological databases are constructed differently, it is virtually impossible to devise search programs to tap into them all effectively. A user has to hop from one to the other using each database's search engine to retrieve information that comes in a variety of different formats. That may soon change, however. A group of leading pharmaceutical companies last week put their considerable weight behind the development of common standards for the interface between biological databases, based on an approach popular in the computer industry. But bioinformatics specialists who run some key databases used by academic researchers say they are not enamored of the interface standards chosen, although they may now be forced to adopt them.
The strategy was agreed to at a meeting in Philadelphia, attended by representatives of pharmaceutical giants such as Smith Kline Beecham, Glaxo Wellcome, and Zeneca, together with a number of software companies and representatives of databases, including the European Bioinformatics Institute (EBI) in Cambridge, U.K., and the Genome Data Base at Johns Hopkins University. The participants unanimously agreed on a fast-track plan to bring life sciences databases under standards drawn up by the world's largest software consortium, the Object Management Group (OMG). "The pharmaceutical industry is fed up by the lack of standards between biological databases," says the EBI's head of services, Graham Cameron.
The OMG was set up 8 years ago to tackle the problem of incompatible databases. The OMG's approach, dubbed the Common Object Request Broker Architecture (CORBA), does not impose an external set of rules for the contents of databases to which everyone must adhere. Instead, CORBA defines interfaces that allow different databases to communicate with each other no matter what their format. Software companies then use these interfaces to devise programs that allow researchers to access data in otherwise incompatible locations. "The idea behind CORBA is that database managers will never entirely agree on common formats for data entry in databases," says Eric Neumann of the biological software company NetGenics.
The EBI has already championed the CORBA approach, winning funds from the European Union to study its application to biological databases in collaboration with other European partners. The Philadelphia meeting, chaired by Cameron, agreed to work toward getting the OMG to establish a life sciences "task force" by the end of the year to hammer out the details of applying CORBA to life sciences databases. Seven task forces in various business areas already exist.
Cameron is concerned, however, that biologists may not back a move to CORBA in the belief that other standards may ultimately be more useful for life scientists. "The plan is by no means a done deal," he says. Researchers at the National Center for Biotechnology Information (NCBI) in Bethesda, Maryland, for example, are not convinced that CORBA will provide the best solution for biologists. "CORBA is one among many technologies," says head of applications development, Jim Ostell. "There's no real reason why a number of other standards couldn't be applied, but given the critical mass of interest in CORBA it's a reasonable choice," he adds. NCBI will be looking at CORBA alongside other potential technologies for linking databases.
Supporters of CORBA will ultimately have to convince skeptics to use the standards, but they are optimistic. "The best outcome would be standards to which software developers and database managers adhere. It could do us all a great deal of good," says Cameron.
~~~~~~~~
By Nigel Williams
Title: | The OMG's ambitious plans. |
Subject(s): | |
Source: | |
Abstract: | Focuses on the Object Management Group's (OMG) aim to ratify as many as 13 new technologies for its forthcoming CORBA 2.3 and 3.0 specifications during its meeting in September 1997 in Dublin, Ireland. Expansion into vertical domain interfaces that will govern industry-specific implementation of object request brokers; Vendors' submission of proposals for review at the meeting. |
AN: | 9708145926 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: NEWS
At its meeting next month in Dublin, Ireland, the Object Management Group (OMG) hopes to ratify as many as 13 new technologies for its forthcoming CORBA 2.3 and 3.0 specifications.
Also, the industry standards body will aim to expand into vertical domain interfaces that will govern industry-specific implementation of object request brokers, such as those embedded in telecommunications, health care, finance, manufacturing, and business applications, said CEO Chris Stone.
Vendors currently are submitting proposals governing areas such as components, scripting, objects by value, notification, audio/visual interface, the COM-to-CORBA bridge Part B, and asynchronous messaging for review at the meeting.
One user welcomed the CORBA 2.3 and 3.0 standards, but also warned that the OMG still has a great deal of work to do before it dispenses too much energy on the vertical domain-specific interfaces.
"The OMG really needs to address some of the interoperability issues surrounding CORBA," said James Smith, planning and project manager for Southwestern Bell, in St. Louis.
Also expected at the Dublin meeting is the standardization of the Unified
Modeling Language, according to Stone.
Title: | AAVS and LYSIS to partner CORBA. |
Subject(s): | |
Source: | |
Abstract: | Reports on the firms AAVS and LYSIS's plans to use Common Object Request Broker Architecture-based communications software to link their broadcast and multichannel technologies. |
AN: | 9709071801 |
ISSN: | 1461-4197 |
Database: | MasterFILE Premier |
AAVS AND LYSIS TO PARTNER CORBA
AAVS and LYSIS have announced plans to use CORBA-2 (Common
Object Request Broker Architecture} based communications software to link their
broadcast and multichannel technologies. CORBA is a standard
devised by the Object Management Group and both companies plan to use the
technology to provide their customers with traffic, scheduling and automation
within a single package. This represents one of the first times that CORBA,
a growing force in the computer industry, will be used in this way.
Title: | Iona tool will manage CORBA environments. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on Iona Technologies Ltd.'s launching of OrbixManager 1.0, a software designed to enable the management of CORBA computer program language. Features; Capabilities; System requirements. |
AN: | 9708171648 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: NEWS
Object management
Iona last week launched OrbixManager 1.0, a tool designed to enable the management of CORBA environments.
The tool aims to provide administrators with a way to manage software objects on a network. Iona unveiled OrbixManager during last weeks Object World West show in San Francisco. (See related article, page 43.)
Also, officials said the company is currently beta testing Java-based services -- include Java Naming, Java Directory, and Java Transaction services -- for its OrbixWeb object request broker (ORB) for Java. The new services will let developers build applications in Java that were previously only available to users of CORBA.
OrbixManager is designed to work with Iona's Orbix and with the company's messaging product, OrbixTalk, but ORBs from competing vendors such as Visigenic will not work with the tool.
"We will add support for Java later this year," said an Iona representative. "But we don't foresee the necessity of adding support for any competing object request brokers."
OrbixManager will let network managers monitor networks for the number of objects found on a network and configure the CORBA environment itself, officials said, and it will work with other network-management tools via an SNMP gateway.
Iona Technologies Inc., in Cambridge, Mass., is at http://www.iona.com/.
DIAGRAM: ORB management emerges
~~~~~~~~
By Niall McKay
Niall McKay is a San Francisco correspondent for the IDG News Service, an
InfoWorld affiliate.
Title: | CORBA connection. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on an agreement between OpenCon Systems Inc. and Expersoft Corp. to incorporate common object request broker architecture technology into a Telecommunications Management Network-based solution. Facets of telecommunications targeted by the gateway development; Diagram illustrating the integration. |
AN: | 9708075005 |
ISSN: | 0040-2656 |
Database: | Academic Search Elite |
Section: A.M. Report
A Partnership between two software companies to incorporate common object request broker architecture technology into a Telecommunications Management Network-based solution could yield a more elegant way to integrate carriers' legacy networks and provide a workable approach to interconnection.
The partnership between OpenCon Systems Inc. and Expersoft Corp. is aimed at creating a new gateway that will give carriers an open, protocol-independent method of accessing legacy systems. OpenCon will integrate Expersoft's CORBAplus technology into its TMN Gateway product, which it hopes to roll out within three months.
"The problem that many carriers face is that there has never been a single standard set for network management," said Wind Chen, vice president of product planning and sales engineering for the Piscataway, N.J.-based OpenCon Systems. "The three most common protocols are TL-1, [simple network management protocol] and [common management information protocol], and these all may exist within the same carrier's operations."
To secure the investments already made in software and equipment, the gateway will target these three protocols and provide what Chendescribed as a "staging facility" to support the translation of CORBA IDL to TL1, SNMP and CMIP protocols at the open systems interconnection seven-layer level.
CORBA provides the gateway with an efficient, object-based method of translating between protocols, supporting applications written in C++, Java and Visual Basic languages.
The gateway development will target three facets of telecommunications, said Steve Sybert, vice president of worldwide telecommunications for the San Diego-based Expersoft. "The object-oriented nature of CORBA will help developers create new applications faster by providing reusable software elements," he said. "While that's important, the other two areas we're focusing on are even more pressing issues for the telecommunications industry -- providing a view of network and customer information to the external world, and refining the interaction between legacy systems internally."
"There are 6000 carriers out there, and for each carrier to negotiate an individual agreement based on proprietary network systems with every other carrier is impossible," he said. "CORBA can serve as a Rosetta Stone between these systems, and we think this fits into the bigger business picture."
CORBA is a key method for simplifying network management and interconnection issues, although its impact on the telecommunications industry will depend on carriers' eagerness to solve problems, analysts said.
DIAGRAM: CORBA-ENABLED TMN GATEWAY
~~~~~~~~
By CHRIS BUCHOLTZ
Intelligence & Software Editor
Title: | OMG pushes to become standards body, touts CORBA. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Provides information on Common Object Request Broker Architecture (CORBA), an international standard developed by Sun Microsystems Incorporated's Object Management Group (OMG). How the OMG had requested to become a submitter of Publicly Available Specification (PAS); Why the application of Sun for PAS has been an obstacle; Parts of CORBA that OMG should pass. |
AN: | 9708303365 |
ISSN: | 0893-8377 |
Database: | MasterFILE Premier |
Section: NEWS
Following Sun Microsystems Inc.'s lead with Java, the Object Management Group is trying to make CORBA, the Common Object Request Broker Architecture, an international standard.
Like Sun, the Object Management Group (OMG) has requested to become a submitter of Publicly Available Specifications (PAS), or a standards body in its own right. Becoming a PAS also would allow the OMG to submit specifications through the International Standards Organization's fast-track process.
Votes on the OMG's move are due to the JTC 1 TAG--a U.S. technical advisory group--on Oct. 10. If the United States approves the OMG's request, it goes to an international vote.
Sun's application to become a PAS has hit a snag largely because it is a for-profit company. JavaSoft Vice President Jim Mitchell said that most of the international votes have come back with comments, which Sun will spend the next 60 days addressing.
But the OMG is a nonprofit consortium of companies and expects to be approved in about six months.
In fact, the International Standards Organization (ISO) and the OMG already work together, and ISO is expected to approve the OMG's Interface Definition Language (IDL) as a standard this month, said Jon Siegel, OMG director of domain technology.
IDL defines interfaces to objects and maps to all the major languages, including C&PLUS;&PLUS;, Java and Visual Basic, although the Visual Basic bindings are not yet an OMG standard, Siegel said. Programmers then can write objects in different languages that have the ability to interact.
"IDL is the key to accessing CORBA interoperability and all the other CORBA features. That's why it makes sense for it to be the first part of CORBA to be standardized," Siegel said.
The OMG also will submit other parts of CORBA, including the Internet InterOrb Protocol (IIOP), Siegel said.
CORBA and IIOP are now backed by Netscape Communications Corp., Oracle Corp., IBM Corp. and Sun, which refer to themselves as the Gang of Four. JavaSoft this month was persuaded to back IIOP along with its own Java-to-Java protocol.
However, not everyone who works with CORBA is positive.
"Someone will evolve a lightweight object protocol--something beyond RMI-where we will have anchored objects and only pass requests for objects and replies from objects. But there's so much inertia behind CORBA and IIOP that the OMG is blind to this possibility," said a Sun reseller who asked not to be named.
"We don't want to split the market three ways--Java, CORBA and DCOM [Microsoft Corp.'s Distributed Component Object Model]--because that just feeds Microsoft," said an OMG official who requested anonymity.
Microsoft senior officials maintained that Microsoft has no plans to work more closely with the OMG. Microsoft is currently an OMG member.
ISO certification is a requirement for purchasing technology in some foreign countries, and that could be beneficial for CORBA.
It is nonprofit consortium.
The International Standards Organizations is Expected to approve the OMG's Interface Definition Language as a standard this month.
OMG also will submit other parts of COBRA.
~~~~~~~~
BY DEBORAH GAGE, Framingham, Mass.
Title: | OMG to ease CORBA development. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on the Object Management Group's efforts to lower the technical barriers to developing CORBA applications. Issuance of requests for Proposals (RFPs) for a unifying scripting language and component model; Integration of its Internet Inter-ORB Protocol transport with the Java Remote Method Invocation interface for distributed object communication. |
AN: | 9707151490 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: SERVER
Seeking to promote widespread use of its CORBA technology and services, the Object Management Group (OMG) is pursuing an ambitious agenda to lower the technical barriers to developing CORBA applications.
Working toward CORBA 3.0, the OMG is reading requests for proposals (RFPs) for a unifying scripting language and component model, according to President Chris Stone.
The initiatives follow the specification of myriad current and pending CORBA Interface Definition Language (IDL) mappings, which allow developers writing in Cobol, Java, or fourth-generation languages, such as Sybase division Powersoft's PowerBuilder, to access and generate CORBA objects without wrestling with the abstruse IDL.
The organization, which includes IBM, Sun, Oracle, and Netscape among its members, last month issued the component RFP and will shortly issue one for scripting, according to Stone.
"The biggest barrier to the adoption of our 15 different object services is the lack of a component model to share those services and a single scripting language for all CORBA services," Stone said.
A CORBA component model would allow developers to create components visually on a project palette and access methods and properties more easily than the coding-intensive approach required by IDL, Stone said.
The component model will be based largely on JavaBeans. Java-Script will be among the scripting languages considered, Stone said.
IDL has restricted CORBA's growth, according to one analyst.
"We predicted a while back that CORBA would disappear as a programming model," said John Rymer, an analyst with market research company Giga Information Group, in Cambridge, Mass.
"[The language mappings to IDL] make IDL a glue language, and all the CORBA language bindings are irrelevant," Rymer said.
According to Rymer, the OMG's ultimate role with CORBA will be to provide an integration substrate for multiple object models rather than to furnish a full-blown development architecture.
More important than the pending CORBA object model and scripting proposals, the OMG's recent decision to integrate its Internet Inter-ORB Protocol transport with the Java Remote Method Invocation (RMI) interface for distributed object communication indicates the future position of CORBA in the development technology food chain, according to Rymer. (See "JavaSoft to fix RMI compatibility," page 14, June 30.)
In pursuing tighter integration with Java and providing mappings to common programming languages, the "OMG is not shooting its own foot," Rymer said.
"It doesn't have any choice. The group is returning to its roots. The genesis of CORBA was as interoperable middleware for object systems," Rymer said.
Separately, the OMG is readying for September release the first of its vertical industry, end-user object specifications for telecommunication finance and manufacturing, according to Stone. The group has also issued an RFP for workflow management.
The Object Management Group, in Framingham, Mass., can be reached at (508) 820-4300.
• Java-CORBA Interface Definition Language (IDL) mapping: adopted as standard in June and expected to be in Java Development Kit 1.2
• Asynchronous messaging API: scheduled vote in September in Dublin, Ireland
• Internet Facility requests for proposals (RFPs): CORBA IDL to connect to TCP/IP, FTP elnet, SMTP, and others; submissions expected by early 1998
• CORBA scripting language: RFPs due later this year
• CORBA component model: RFPs due later this year
• Adoption of Universal Modeling Language: expected in September
SOURCE: OBJECT MANAGEMENT GROUP.
~~~~~~~~
By Ted Smalley Bowen
Title: | CORBA or bust for NT-imperfect world. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Comments on the need for Microsoft to put aside politics to reach some sort of compromise with the backers of CORBA. Author's view that Microsoft's strategy of making CORBA irrelevant through the huge sales of NT as unforeseeable; Need for Microsoft to embrace CORBA before the market can fully embrace NT. |
AN: | 9707151424 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: NEWS
FROM THE NEWS DESK
The time has come for Microsoft to prove how big it really is by putting aside politics to reach some sort of practical working relationship with the backers of CORBA. As noted in Niall McKay's Page One article this week, the Object Management Group (OMG),which spearheads CORBA, now intends to extend I hat architecture to include a component model that will be compatible with JavaBeans.
Although it remains to be seen whether the vendors that make up the OMG can deliver on this promise, the mere fact that there appears to be some real consensus building around distributed objects means that Microsoft can no longer play politics as usual.
From Microsoft's point of view,force of arms provided by the increased sales of Windows NT loaded with the rival Distributed Component Object Model (DCOM) specification should make CORBA irrelevant. That position might actually be credible if we thought NT would be as scalable as Unix any time soon, but it simply won't happen before the end of the century.
This means customers are going to be living with a mixture of NT and Unix systems for a long time to come, and we're going to need a unified distributed object architecture today to foster application development across the enterprise. We simply can't wait for NT to eventually win out over Unix.
Microsoft may want to hold on to DCOM for business reasons as the glue that binds together the pieces of Windows. Windows' many flavors are starting to resemble the multiple implementations of Unix that have long plagued the industry a situation Netscape's Marc Andreessen likes to refer to as the "Unixification" of Windows.
But the rest of us need something that works today. That means Microsoft needs to actively support CORBA before we can fully embrace NT.
So are customers going to hold off on fully adopting NT until this issue gets resolved, or are we going to contribute to our own demise by wistfully hoping for some technical miracle that makes all these headaches magically disappear? Write to me at michael(underbar)vizard@ infoworld.com.
~~~~~~~~
By MICHAEL VIZARD
Title: | Three's a crowd with object lessons. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Opinion. Argues that users should not be tempted to purchase Java Beans for Enterprise (JBE) from JavaSoft because there are already two competing distributed component models on the market. Comparison of JBE to the other two models, Common Object Request Broker Architecture (CORBA) and Microsoft's Distributed Component Object Model (DCOM). |
AN: | 9707152769 |
ISSN: | 1046-4468 |
Database: | Academic Search Elite |
Section: In The Middle
Don't get me wrong. I'm a huge Java fan--Java, the language that is. Unfortunately, the incredible hype surrounding Java has emboldened JavaSoft to attempt the displacement of the Object Management Group's (OMG's) Common Object Request Broker Architecture (CORBA) with Java Beans for the Enterprise (JBE), to vie with Microsoft's Distributed Component Object Model (DCOM) as the distributed component architecture for Web applications. I'm all in favor of using Java as the language for implementing a distributed component architecture, but we don't need another component standard. Accordingly, users should ignore the hype and consider only CORBA and DCOM as standards.
Java will play an important role in enterprise applications, but it will not revolutionize every aspect of application architecture-contrary to JavaSoft's claims. At the JavaOne conference in April, JavaSoft outlined JBE, a server-side component model. Previously, JBE had been positioned as a client-side GUI-component standard. Some of JavaSoft's statements regarding JBE position it as a distributed component model that will compete with both DCOM and CORBA for the hearts and minds of developers. At other times, JBE is merely positioned as a Java-specific instance of these other models. Two competing distributed component models is bad enough. Users must resist any attempts by JavaSoft to establish JBE as an alternative to DCOM and CORBA. Otherwise, the CORBA camp, which is just beginning to consolidate, could be torn apart by a standards war that would leave Microsoft's DCOM the winner. The upside is that we would have a single standard; the downside is that the winner would be Windows-centric (leaving Unix and other platforms with second-rate support or none at all).
CORBA Gets Its Act Together Microsoft and the CORBA vendors have moved rapidly to deploy their competing component models. Microsoft has begun shipping its Transaction Server (formerly Viper)-the foundation of its DCOM-based Active Server technology. In the CORBA world, major players-BEA Systems, IBM, Oracle, Sun and Sybase-are backing the CORBA standard and moving quickly to improve interoperability and portability among different vendors' object request brokers (ORBs). More important, IBM, Oracle, Sun and Netscape have formed a "grand alliance" to ensure that their implementations interoperate and that they fill in the gaps in the CORBA standard in a consistent way.
This momentum behind CORBA is essential to attracting the support of ISVs, systems integrators and corporate developers. Corporate developers are ready to pick a strategic distributed component standard next year. Unfortunately, JBE is diluting the CORBA consolidation message. Although the developers at SunSoft are fully behind CORBA, the developers at JavaSoft have delusions of grandeur for JBE. At various times, JavaSoft has touted a Java alternative to a CORBA standard. Although JavaSoft pays lip service to CORBA by offering a Java-to-CORBA mapping known as JavaIDL, its public statements have positioned CORBA as merely a legacy application wrappering technology, while JBE has been positioned as the distributed component model for new application development.
Put Java Beans in Its Place JavaSoft must get on the CORBA bandwagon and turn JBE into nothing more than a Java instantiation of CORBA and CORBA Object Services Specifications (COSS) on the server side. On the client side, JBE can fill a gap in CORBA that was originally meant to be filled by OpenDoc-a model for GUI components. CORBA's main focus has always been on the server side. CORBA has never had a model specification to compete with desktop Object Linking and Embedding (OLE) components because ORB vendors were betting on OpenDoc on the client side. With the demise of OpenDoc, JBE GUI components can offer a standard for heterogeneous client GUIs.
Users are ready to choose a distributed component strategy this year, and must choose wisely. Ignore the hype and put Java Beans back in its place-on the desktop.
PHOTO (COLOR): Nick Gall
~~~~~~~~
By Nick Gall
Nick Gall is a program director with the META Group's Open Computing &
Server Strategies service. He can be reached at nick.gall@metagroup.com.
Title: | Computing's middle ground. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Provides information on the competition between the three middleware platforms for control of distributed computing applications. Background information on Distributed Computing Environment (DCE); Common Object Request Broker Architecture (CORBA); Distributed Component Object Model (DCOM); Major hindrance for the widespread adoption of DCE; Drawbacks of CORBA and DCOM. INSETS: Middle management pros and cons; DCE: Poor choice or top bet? |
AN: | 9709110165 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
Section: DISTRIBUTED COMPUTING
Organizations are building complex distributed computing environments and are relying on these systems to help them remain competitive. CIOs who want to link their distributed environments now face a difficult question: Which of three major middleware platforms--Distributed Computing Environment (DCE), Common Object Request Broker Architecture (Corba), or Distributed Component Object Model (DCOM)--is best?
For years, DCE was the only choice. It was introduced 10 years ago as the first attempt to standardize the basic infrastructure for distributed applications, and over the years it has gained a foothold in many organizations.
But analysts say the highly complex DCE is losing ground as the two newer solutions gain support from vendors. Corba, an open standard overseen by the Object Management Group, in Framingham, Mass., and DCOM from Microsoft show promise as middleware platforms of the future.
The stakes are high in this battle for control of distributed computing environments. These middleware technologies promise to meld diverse networks, allowing mainframes, workstations, and all forms of client-server systems to work together easily. They work by providing a common interface language that serves as a universal translator of sorts between any two applications.
"The idea is to tie together all the different systems that have been developed over 20 years," says Bob Anderson, managing analyst for application component services at Datapro Information Services Group in Delran, N.J.
The need for dependable distributed computing middleware environments is greater than ever as complex three-tier networks--which include database or transaction servers combined with traditional client-server networks--become more commonplace. Also, companies are under increasing pressure to harness their computing resources and deliver data to partners, vendors, and suppliers.
DCE, a standard managed by the Open Group in Boston, is the middleware of choice at many organizations (see story, p. 100). The Open Group says DCE is provided by more vendors and has been ported to more platforms than any other middleware technology, and predicts strong growth for DCE through 1999.
Despite DCE's maturity and support by major vendors, some observers say it's a fading star as the early technology used to create it falls out of favor.
"For whatever reason, DCE missed the boat. Perhaps it was too far ahead of its time," says Nick Gall, a senior research analyst at Meta Group Inc. in Waltham, Mass.
DCE's complexity and a lack of expertise on the technology has been a major hindrance to its widespread adoption.
DuPont & Co. in Wilmington, Del., wants to give its network users broader access to data and is testing DCE to see if the technology can deliver. But Rob Harris, a senior IS specialist at DuPont, says efforts have been slowed by DCE's long learning curve. "Our problem is a lack of trained resources," Harris says.
Though DCE has been around for years, there aren't a lot of people who understand it. An InformationWeek survey of 100 IS managers shows that lack of expertise was the top reason given for not moving to DCE, followed by a lack of DCE-based products, high costs, and security concerns.
Observers say the newer, object-based technologies seem to hold the most potential for creating seamless distributed computing environments, despite the fact that Corba is struggling to establish its standards and DCOM has yet to prove it can operate as a cross-platform solution.
"The hope is that as Corba and DCOM evolve, you'll find that object request brokers are the way to go," Anderson says. "They just need to evolve to encompass security, directory, and other critical services."
Object request brokers serve as control centers of sorts for translating Information between disparate applications. They work in conjunction with an interface definition language (IDL), which provides the "wrapper" for object-oriented middleware that lets various programs talk to one another.
A Boost For Corba
Corba got a major lift last month, when IBM introduced a Corba-based suite of middleware products, including Component Broker Connector and Component Broker Toolkit. Karen Boucher, an analyst with the Standish Group in Dennis, Mass., says the suite was a big boost for Corba. Until then, organizations interested in using Corba had to search far and wide to assemble the tools they needed to build a Corba environment.
Boucher expects IBM to offer its Corba development suite for free with many of its products, just as Microsoft provides DCOM for free with its Windows NT systems.
Some organizations getting an early taste of Corba are finding that dealing with its object-oriented approach is within their capabilities. Cable News Network's CNN Interactive division in Atlanta has been piloting a program since December that uses Corba to distribute part of its news content to 100 different Internet publishing partners. Before that, CNN had to screen-scrape its Web site for news stories, deconstruct them from HTML, then send them out. Now, a Corba application goes out on the network, finds any new content, and automatically notifies users, says Al Issa, a software-development architect with CNN Interactive.
Corba also makes the content appear local to programmers so that they don't have to worry about details such as IP addresses. "It actually made life a lot simpler," Issa says. Implementation of the middleware has gone so well that Issa plans to use Corba to distribute the rest of CNN's news content by the end of the summer.
But Corba isn't without its dark side. The technology still lacks a security standard, though that is promised for the coming year. There's also some question of how much support the technology will receive from vendors. Although companies such as Netscape, Oracle, and Sun Microsystems have agreed to support emerging standards, they could decide not to create many Corba products if another technology comes along.
Risk Vs. Rewards
Still, Corba boosters say the rewards more than outweigh the risks. Wayne Haughey, a group leader at the engines information systems division of AlliedSignal Inc., a maker of airline engine parts in Phoenix, says his company selected Corba because the object-oriented programming environment lets his staff reuse and quickly modify program designs.
Also, since programmers don't have to start from scratch each time they build an application, it's easier to refine an existing program or customize a standard design. And since Corba is cross-platform, code created for a program on one platform can be easily transferred to another. Haughey says AlliedSignal is so confident in Corba that it's committed to using it in a two-year project to develop a Web-equipped network.
Others are going with DCOM. "If you're Microsoft-centric right now, DCOM is a very elegant way to go," Anderson says. The only drawback is that DCOM is far from being a cross-platform solution. It's not yet operable on many systems outside of Windows NT--no small issue when considering an environment for multiplatform networks.
"You want the highest degree of flexibility when setting up one of these middleware environments, and you can't get that with DCOM because it's created by one vendor," Boucher adds.
DCOM support is coming. Software AG of North America in Reston, Va., this month will release a number of porting solutions for DCOM to Unix, including one for Linux, Digital Unix, and Sun's Solaris. It's also working on porting for IBM's MVS.
A spokesman for Microsoft says the company is recruiting partners to port DCOM to other platforms, but he wouldn't provide details.
The porting solutions for DCOM might prove effective. Joe Persichetti, a senior software designer for Dow Jones & Co. in Princeton, N.J., wanted to access data on a Solaris machine to meet a special request by customers to view some of Dow Jones' financial data via Excel spreadsheets. Persichetti says he wanted to port DCOM rather than work with Corba because most of his experience is with Windows. "It wasn't such a reach for me to use DCOM," he says. He used an unpublished beta version of Software AG's DCOM for the Enterprise product and experienced no problems,although he had to write additional code to compensate for DCOM's asynchronous protocols.
Regardless of which middleware platform an organization selects, the key for IS managers is to commit to a particular approach and stick with it, says Marvin Allen Wolfthal, technology director of consulting firm Fusion Systems Group Inc. in New York. "Frequent changes in a network environment will be too disruptive to provide any benefit," he says.
But companies "need to start at least experimenting with this technology because in the future, it will be absolutely critical to get all systems working together," Anderson says. "If you don't do it, you'll be out of business."
While some observers believe the Distributed Computing Environment (DCE) is fading, others say it's the only middleware environment that's dependable enough for critical applications.
"DCE is still the most production-oriented schemeout there," says Bob Anderson, managing analyst for application component services at Datapro Information Services Group in Delran, N.J.
Phyllis Byrne, the Austin, Texas-based VP of distributed systems services for IBM, says DCE, as it originally conceived a decade ago was, very complex. But IBM and other vendors are providing starter kits and other support that make the technology easier to work with.
Some IS chiefs says DCE is their best bet for pulling together disparate elements of their computer systems, especially those networks where object-oriented programming isn't an option.
Bill Won, VP of enterprise and software security technologies at Chase Manhattan Bank in New York, began exploring the technology in 1993 by testing an IBM beta version of DCE for the OS/2 platform. He says Chase has several projects in development, including using DCE to download mainframe files to a database server. DCE isn't always easy to work with, Won admits, but it's the only viable option he has found to securely connect diverse platforms. "If someone is looking for a silver bullet, it doesn't exists," Won says.
Network managers such as Roger Lawson associate director of computing and IT at the University of Vermont in Burlington, are finding the best approach to DCE is to use only what you need. Lawson tapped DCE to create a single system image for his servers, which allowed him to modify IBM RS/ 6000s to meet the exploding computing demands of the 15,000-account university system.
With the DCE single-system image in place, the network treats the group of servers as one, which lets Lawson work on one or more servers without bringing the system down.
Lawson started the project in late 1995, and since the university was one of
the earliest adopters of the DCE feature from IBM, it ran into several
reliability problems, such as coding glitches and memory leaks. But with daily
support from IBM and long hours by his staff over the course of three months,
Lawson finally got the technology working. Now, he says, it performs dependably.
--Charle Waltner
Distributed Computing Environment Pros: More mature, not object, reliant, excellent security Cons: Older, more complex technology; fading from popularity Common Object Request Broker Architecture Pros: Object-oriented, relatively simple to set up, resurable coding Cons: Immature, lacks standards, lacks support for critical network features Distributed COM Pros: Objected-oriented broad support, well-developed for NT platfrom Cons: Controlled by one vendor, not cross-platform oriented DATA: INFORMATIONWEEK
PHOTO (COLOR): CNN Interctive's Issa says Corba has simplified his life, and plans to use it to distribute CNN's news by the end of summer.
~~~~~~~~
By Charles Waltner
Title: | Gang of Four plan to extend CORBA to support JavaBeans. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports that International Business Machines (IBM), Netscape, Oracle and Sun Microsystems have jointly published a position paper that will bring JavaBeans closer with the CORBA specification. Move as a unified attempt to fight off Microsoft; Agreement between the four companies on Object Management Group (OMG) projects. |
AN: | 9706265933 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: NEWS
Three months into their touted object alliance, the companies that comprise "The Gang of Four" have agreed on basic methods to bring JavaBeans closer in line with the CORBA specification in their unified attempt to fight off Microsoft.
The Gang of Four -- IBM, Netscape, Oracle, and Sun -- last week jointly published a position paper that details specific enhancements to the CORBA specification in an attempt to foster integration with other component models, most notably JavaBeans.
The four companies have jointly generated Request for Proposals (RFPs) to the Object Management Group (OMG), which are expected to be voted on in a meeting in Montreal later this month. The RFPs are for a component model; scripting, which will be based on JavaScript; and an Internet naming service.
The four have also agreed to combine forces on two existing OMG projects. The first is Objects By Past Value, an essential Java capability that will now become a CORBA feature, and the second involves multiple-interface support, another basic Java capability.
"What you are basically seeing here is the continued intertwining of Java and CORBA," said Chris Stone, chief executive officer of the OMG, in Framingham, Mass.
Some of the proposed enhancements will enable visual development tools to automatically generate JavaBean interfaces for CORBA-compliant components, a step most observers see as essential.
"Developing for CORBA right now is very difficult. It is a little like brain surgery. What you want is to have something like a JavaBeans component framework available to jump-start your enterprise development. This is a step that lets those users do that" said Melinda Ballou, a senior research analyst at the Meta Group, in Waltham, Mass.
Separately, JavaSoft officials more aggressively endorsed CORBA for large corporate accounts doing sophisticated development in heterogeneous environments, noting that Java Remote Method Invocation (RMI) should be restricted to small Java-to-Java applications.
But one official argued that the RMI protocol has inherent advantages.
"Interoperability is the primary value of Internet Inter-ORB Protocol [IIOP]. RMI gives you the ability to download code dynamically with safety. RMI is more about ease-of-use and flexibility if you're programming both sides of a distributed application in Java," said Jim Mitchell, JavaSoft vice president of technology, in Cupertino, Calif. He added that combining RMI and IIOP would not be feasible.
~~~~~~~~
By Ed Scannell and Ted Smalley Bowen
Title: | Microsoft may not have enough muscle to claim well-established territory. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Comments on Microsoft Corp.'s claim that it has taken hold of the distributed computing market in the United States. Porting of COM to platforms other than Windows 95 as Microsoft's proof of this claim; Indication that CORBA may win out in the end. |
AN: | 9705213764 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: THE END
DOWN TO THE WIRE
To know what the computer industry is really like, watch a gangster movie. Gangsters take territory based on nothing more than the fact that they want it. The mob pretends to offer the current residents protection for a piece of the action, but everybody knows it's a question of how much the mob will let them keep.
That's how Microsoft claimed the territory of distributed computing last week. Microsoft's distributed computing strategy centers on its Component Object Model (COM). COM is an object request broker (ORB), which is a technology used to allow client and server components to communicate with other client and server components. The components can be composed of anything from raw C++ to Activex and JavaBeans.
One argument Microsoft makes for COM is that it is finally being ported to platforms other than Windows 95 and Windows NT. As evidence of this new multiplatform strategy, Microsoft got Digital to agree to port COM to OpenVMS by the end of this year, and Hewlet-Packard is shooting to deliver COM on HP-UX within a year. And Software AG is tackling putting COM on Sun Solaris and MVS.
Ready on the set
In this movie, the camera sweeps slowly across the dimly lit room. It rests on the Digital and HP representatives, who are sobbing and kissing the hand of the Godfather.
"Don Gateleone, we need your help. The trades don't write about us. Our stock is unstable. And we have boo-boos on our knees," they moan.
"You pathetic babies. I should throw you out. But because you helped my son, NT, when he was in need, I will make the trade pubs an offer they can't refuse. When they wake up, they'll find a stack of partnership press releases in their beds," the Don offers.
"However, I require something in return. My enemies in the CORBA family, Lou Gerstaglia, Scott McNealioni, and Jim Barksdaliani ... even now they plot my demise. For this favor, you must port COM to your other operating system platforms."
But life does not always imitate art. Microsoft's claim to victory hangs on the hypnotic quality of Bill's billions and the promise of products based on technology that's unproven in the large enterprise. In other words, it's too little too late, especially where it really counts. This battle will not be decided on the desktop. The coveted territory is the server. And the CORBA families have already taken over that space.
Ironically, Digital, Microsoft's most heralded supporter of COM, provides the most dramatic proof. Digital's CORBA-based Object-Broker is shipping today running on OS/2, AIX, OS/400, MVS, MacOS, Digital Unix, OpenVMS, HP-UX, and all versions of Windows. Iona Technology's Orbix supports Sun Solaris, HP-UX, AIX, MVS, Irix, Digital Unix, Windows 95, and Windows NT. Visigenic Software's VisiBroker is available for Novell IntranetWare, and Visigenic has aversion of its ORB that is written entirely in Java.
Then there's IBM's System Object Model (SOM) and Distributed SOM and Expersoft's PowerBroker. And while we're still waiting for Mama Celeste to cook up some COM on Unix, some of these CORBA products have been simmering in the pot since 1993.
Some envision a future in which COM dominates the desktop and CORBA the server. Maybe. But remember three things: First, network computers aren't Windows-based, so Microsoft has no leverage there. Second, Netscape is making the Internet Inter-ORB Protocol nearly ubiquitous by including it in Navigator. Third, you take a performance hit when you mix COM desktop components with CORBA server components. I predict the industry will want to standardize on one or the other sooner or later. And because CORBA already owns the server space -- where the big money will be made -- it is the obvious choice.
The magnificent seven
Seven is the biblical number of completeness, so it is somewhat prophetic that after seven years I am leaving my full-time position at Info World to become editor in chief of a new IDG Web publication dedicated to network computing, NC World (http://www.ncworldmag.com). I am happy to say that I'll continue to write Down to the Wire and host my forum on Info World Electric. So consider me absent in body but present in spirit.
Make an offer I can't refuse and send it to nicholas(underbar)petreley@infoworld.com or visit my forum on InfoWorld Electric at http://www.infoworld.com.
PHOTO (BLACK & WHITE): NICHOLAS PETRELEY
~~~~~~~~
By NICHOLAS PETRELEY
Title: | CORBA may become industry's elixir. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Focuses on Cabletron Systems Inc.'s Web-based strategy on managing customer networks. Provision of greater flexibility and cost-effectiveness which is precisely what the use of the World Wide Web; Integration of the computer program language CORBA into the spectrum management platform; Offering of enhancements to other management vendors in the interest of interoperability across multiple platforms. |
AN: | 9707062692 |
ISSN: | 0040-2656 |
Database: | Academic Search Elite |
Section: Intelligence & Software
Common Object Request Broker Architecture technology will play a key role in a new Web-based strategy from Cabletron Systems for the management of customer networks. By 1998, CORBA will be partly used for pure Java device management in solutions from Rochester, N.H.-based Cabletron.
"We're setting 1998 as the time frame for modifying our platforms to fit a [Telecommunications Management Network]based world," said Joe Massey, Cabletron's director of platform development.
The strategy's goal is to provide customers with greater flexibility and cost-effectiveness, which is precisely what the use of the World Wide Web, CORBA and Java will allow, Massey said.
By integrating CORBA into the Spectrum management platform, "the number of applications available to our customers will dramatically rise," Massey said. "And by using Java and its write-once, deploy everywhere capabilities, customers can change versions of their software without having to shut down their systems."
CORBA will allow software developers writing applications for Spectrum and other Cabletron management software to write applications in Java, C++ or C. During 1998, CORBA will enhance Spectrum application programming interfaces (APIs), improve the platform's scab ability, and open up new opportunities for custom applications, Massey said.
Cabletron will offer these enhancements to other management vendors in the interest of interoperability across multiple platforms. The new APIs will not require CORBA expertise and will allow application integration to be done within the Java, C++ and C language skill sets for enterprise and desktop environments.
Additional development of Spectrum APIs will be aimed at making implementation easier for software developers, much in the way predefined menus are provided for developing graphics-oriented applications for Windows. Cabletron will provide a set of reusable objects for software developers targeted at specific management functions such as distributing software or viewing topology "Our goal is to give our customers the widest possible choice of applications," said Massey.
Cabletron is targeting the improved platform at the carrier, Internet service provider and enterprise markets. Service providers would offer these network management tools to their customers as a value-added service, said Massey. "Cabletron is really the first major player to spell out the details for us," said Rick Villars, director of network architecture and management research at International Data Corp.
"Virtually every vendor has committed to CORBA as the foundation of Java object management," said Villars. "It makes sense to support it, but part of committing to the technology as a standard is to move toward it, which is what Cabletron's announcement signifies."
Within the carrier community, however, CORBA faces the same challenge that other technologies have faced: overcoming an installed base of technology that performs the same task, Villars said.
"The problem is that real users have invested time and money in the systems they have in place, and they don't want to throw them out, especially when they're doing their job," he said. "It's very likely that the first round of CORBA-based systems won't be able to match the functionality of the existing systems for a year to 18 months. The vast majority of those in the carrier world want to see CORBA, but they can't afford to see any performance problems. You're likely to see a gradual phase-in rather than a big rush to CORBA."
DIAGRAM: Cabletron's Java Strategy
~~~~~~~~
By CHRIS BUCHOLTZ, Intelligence & Software Editor
Title: | Messaging and objects pair off. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on the Object Management Group's evaluation of proposals to extend the Common Object Request Broker Architecture (CORBA) standard to include links to messaging systems. Possible integration of object request brokers and message-oriented middleware; Popularity of object-oriented technology for building applications; Use of message-oriented middleware as a means of linking applications running on heterogeneous systems. |
AN: | 9707023170 |
ISSN: | 1059-3470 |
Database: | Academic Search Elite |
Section: Soundbites: Middleware
A move to unite two key middleware technologies--object request brokers and message-oriented middle-ware (MOM)--could make life easier for IT managers who want to leverage the benefits of both.
The Object Management Group (OMG) is reviewing proposals for extending the Common Object Request Broker Architecture (CORBA) standard, which specifies how objects communicate in distributed environments, to include links to messaging systems such as IBM Corp.'s MQSeries and PeerLogic Inc.'s Pipes Platform. The OMG has received seven proposals for the CORBA extension, known as the messaging service specification, and is expected to certify a standard by mid-year.
While object-to-messaging links might sound like a topic for late-night debates among Jolt cola-addicted programmers, the lack of such a standard is proving to be a big headache for IT managers, according to Gerald Henson, a senior technologist with Southwestern Bell. Henson says object-oriented technology is most popular for building applications because it's good for modeling business processes. But MOM is winning favor as a means of linking applications running on heterogeneous systems because of its scalability and multi-platform, asynchronous architecture.
The problem is that there is no standard way to link the two technologies, which effectively forces IT managers to choose one or the other. "Messaging would be a very nice set of services to complement CORBA," Henson says.
~~~~~~~~
By Rick Whiting
Title: | COBRA gets broad vendor support. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Discusses how vendors have taken a step toward letting companies connect to different transaction-based electronic commerce. Object Management Group's (OMG) key standard in achieving the goal; Companies that will work jointly on compatibility issues; Basic specification of the Common Object Request Broker Architecture (COBRA); How the vendors' agreement promises to facilitate interoperatibility. |
AN: | 9704183350 |
ISSN: | 0746-8121 |
Database: | Academic Search Elite |
Section: Network Applications
OBJECT SOFTWARE
Although four leading vendors have taken a step toward letting organizations connect different companies' object-oriented applications, it could still be some time before the move facilitates transaction-based electronic commerce.
It already has been more than a year since the Object Management Group (OMG) released a key standard toward achieving that goal: the Internet InterORB Protocol. But IIOP is a baseline specification that does not address higher-level hierarchies of how different vendors' objects connect to one another.
Looking to break that roadblock, IBM, Netscape Communications. Oracle and Sun Microsystems earlier this month said they will work jointly on that surround the IIOP standard and on proposals of new Common Object Request Broker Architecture (CORBA) service implementations to the OMG. These implementations operate at a level above the basic CORBA Services 1.0 specifications.
By extending CORBA, a single distributed application might call upon objects located in five or six different companies' object request brokers (ORBs) involved in a sales transaction across the Internet. The vending company may need to link to an object at the buying company to update its inventory level directly and at the same time call upon a third-party financial organization to receive electronic payment for the order. For both of these tasks, the naming mechanism of the vending company must be able to interoperate with the naming services used on the ORBs of the two other parties. In addition, all three parties must be using the same implementation of CORBA's Object Transaction Service so that the deal can be rolled back, or undone, should one part of the application fail or be rejected.
Basic specifications for CORBA Services have been on the OMG's books since December 1995, but the implementations of such services, including the important object naming service, have lacked a higher level of unity. All four companies have a vested interest in achieving a higher level of Web- and enterprise-based object interaction, and all four feel Microsoft's competing Distributed COM and ActiveX-based efforts are a major threat.
The vendors' recent agreement promises to facilitate interoperability, but it could be some time before key compatibility issues are resolved, said Anne Thomas, senior analyst for distributed objects at the Patricia Seybold Group, Boston.
"We still need a way to transparently locate a specific object to allow multiple users to share objects," she said. That includes letting users update objects and ensuring that the objects are stored permanently, she added. The vendors also need to address authenticating users and objects, and to develop a common model to certify that a user or object has in fact performed a given transaction.
Some progress had been made last September when IBM and Sun took the first step by starting on a common naming service syntax, an effort that has only just reached the alpha stage. Last month, ORB-maker Visigenic Software, San Mateo, Calif., joined in that effort. Oracle's Jerry Held, senior vice president of server products, said that Cambridge, Mass.-based Iona Technologies had also committed to support the CORBA Naming Service. At the recent Object World East show, the first implementations of CORBA's Object Transaction Service were demonstrated in beta form (CommWeek, March 3).
The executives from IBM, Netscape, Oracle and Sun (Steve Mills, general manager, IBM Software Solutions Division; Steve MacKay, senior vice president, Sun Solaris products; Jerry Held, senior vice president, Oracle server products; and Rich Schell, senior vice president, client division, Netscape), gave few specific timetables for their submissions of CORBA Services implementations.
"The Naming Service implementation should be presented to OMG some time in the first half of this year," said Held.
CORBA naming services were selected as the first joint service implementation because the ability to locate and call objects held on remote ORBs is fundamental. The other CORBA Services that the companies expect to be working on this year include implementations of Object Transaction Services and CORBA Security Services.
"On the transaction services, we need to map to a common set of semantics. align our message queuing services, extend our language mappings to cover Smalltalk and Java as well as the current C+ + and come up with common business objects facilities," IBM's Mills said.
IMPLEMENTING OBJECTS
Four major vendor's applications platforms will be easier to link within enterprises and beyond with extensions to COBRA. Here's how each will benefit:
Oracle The company's Network Computing Architecture depends on different vendors' objects to connect; without it, NCA will be a piecemeal solution at best Sun Enterprise scalability of Java applications will depend on the extent to which COBRA services can be deployed for naming, transactions and security IBM IBM's System Object Model (SOM) is the basis of COBRA; interoperable implementations will be facilitated by Java and NCA compatibility Netscape COBRA is key to the company's roadmap for Web commerce and extranets Source: CommunicationsWeek Chart by David R. Bautista
~~~~~~~~
By MARTIN MARSHALL
Title: | DCOM foes form Corba pact. |
Subject(s): | |
Source: | |
Abstract: | Reports that International Business Machines, Oracle and Netscape Communications have agreed to work together to ensure their products can interoperate, using Object Management Group standards. Acknowledgements made by individuals who established goals for this project. |
AN: | 9703282864 |
ISSN: | 1054-0784 |
Database: | MasterFILE Premier |
Section: UPDATE
IBM, Sun Microsystems, Oracle, and Netscape Communications have agreed to work together to ensure their products can interoperate using the object standards defined by the Object Management Group (OMG). Those standards are the Common Object Request Broker Architecture (Corba) and the Internet Inter-ORB Protocol (IIOP). When setting the goal of achieving this interoperability by year end, the four vendors acknowledged a key motivation for their pact is to derail enterprise support for Microsoft's competing standard, the Distributed Component Object Model (DCOM).
Our take: The real news in this announcement -- all but ignored in the first
reports of the mid-March deal -- is the tacit acknowledgment that the OMG's
specs require vendors to perform a Cot of extra work to ensure their "Corba-compliant"
apps actually interoperate. All four members of the new coalition were already Corba
and IIOP backers. If the specs lived up to the OMG's claims, there would be no
need for this mobilization effort. As such, we don't see the pact as good news
for the OMG. :Instead, it suggests -- as Microsoft Loves to claim -- that the
group's specs are in disarray and require lots of fine-tuning to actually work
as billed.
Title: | Corba connection. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | States that Object Request Broker (ORB) has supported Internet Inter-ORB Protocol (IIOP) which addresses that Corba applications can communicate in a distributed environment. Seven products of ORB; Test results on the laboratory evaluations of seven ORB products; Steps used in testing the cross-products and platform inter-operability of ORB products; Main objective in evaluating the ORB products; Wider specifications of Corba. INSETS: Corba's protocol for ORBs. |
AN: | 9704075931 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
Section: Application Development
The Corba specifications set by the Object Management Group have the express purpose of allowing distributed object computing to take. place transparently in a multivendor, multiplatform network environment. Yet until recently, the. multivendor part of the equation was missing.
At the heart of multivendor inter-operability is the Internet Inter-ORB Protocol (IIOP), introduced with the Corba 2.0 version of the OMG's object request broker (ORB) specifications more than a year ago. IIOP addresses how Corba applications communicate in a distributed environment. IIOP is the version of the General Inter-ORB protocol that runs over a TCP/IP network. There are other GIOPs under development for other network transports such as Novell's IPX and IBM's SNA protocols. Object tool vendors are finally making IIOP and distributed objects a reality. This means customers no longer must depend on one vendor to meet their distributed-computing needs.
Now that multiple ORB vendors support IIOP, companies can mix and match best-of-breed ORBs. One vendor might offer the fastest ORB on the market. Another might have the smallest embedded ORB. With IIOP, all these different object components can interoperate within and between systems.
A company might use this technology in migrating an OLTP (online transaction processing) order-entry system from a mainframe to a browser-based application. An ORB that runs on MVS from Iona Technologies could be placed on the mainframe to allow wrapping of the jobs that will remain on the host Another ORB that supports Corba's Object Transaction Service could be used on a Unix server to migrate some of the jobs off the mainframe. A third ORB--say the Java ORB from Visigenic Software--could be used to write Java client applets for the browser interfaces. All ORBs can invoke methods upon one another. Each ORB is selected because of its ability to perform its specific function.
IIOP also lets an IS department use a consolidated approach to system development. Large organizations typically have multiple, concurrent development projects-- each selecting the technologies that best meet their particular needs. IIOP provides interoperability among these previously independent systems and simplifies systems integration--at least from a communications standpoint.
Test Results
Our lab evaluations of seven ORB products show that impressive progress is being made (see chart, p. 4A). We selected the products from Iona Technologies, Sun Microsystems, and Visigenic Software as a representative sample of ORB products available in the market. Iona, whose world headquarters are in Dublin, Ireland, has long been synonymous with Corba, having marketed one of the first Corba ORB products. Sun has distinguished itself with the phenomenal early success of the Java language, and the company is integrating Java with Corba into its Joe and NEO products. Visigenic acquired its ORB technology (ORBeline and Black Widow) from Post Modern Computing. Netscape recently licensed Visigenic's technology for inclusion in its Web browser and server products.
We selected a few enterprise business classes from our business Object library for evaluation. Test interfaces corresponding to the business objects were specified using Corba's Interface Definition Language (IDL), which lets developers define each object's interface The IDL interfaces were then compiled using each vendor's particular IDL compiler.
IDL compilers are used to generate server skeletons; these provide the starting point for implementation of server objects. IDL compilers also generate client stubs, which allow for remote method invocation on server objects by client applications. Each of the ORB products we evaluated provided sample documentation and examples that made it easy to create server skeletons and client stubs.
The next step involved the creation of an Interoperable Object Reference (IOR) for each of the server objects. An IOR is a string of characters which can be used by client applications to reference a server object across ORBs that support IIOP. Most important, an IOR is not vendor-specific. A VisiBroker client, for instance, should be able to access an Iona Orbix or Sun NEO server object if it has a valid IOR for that server object.
We created IORs using whatever approach we deemed most appropriate for that particular vendor. In the case of the NEO server objects, we wrote a simple client application that used NEO's proprietary method for first creating a reference to a server object, followed by converting that reference to a string using a stringify method on the object reference. The NEO stringify method is a proprietary wrapper around the object(underbar)to(underbar)string method. The Corba 2.0 stringify method converts an internal Corba object reference to an ASCII string.
In the case of the Orbix and Visigenic ORBs, we placed source code in the server object's implementation, which converted the server object's reference to an IOR the first time the server object was instantiated. IORs were placed in files so they could be accessed by C++ clients. In the case of Java applets, the IORs were passed as parameters to the applets.
Finally, we created client applications and applets to access the
Interoperability: A sample application tests client-server communications among various IIOP implementations. server objects using the IORs. After ensuring that each product's client. worked with its corresponding. server implementation, we then explored its cross-product and cross-platform interoperability. Each client was tested for:
correctly instantiating a server object using an IOR;
correctly causing the implementation to be started if it wasn't already running;
correctly invoking the object method;
correctly managing a diverse range of IDL data types, including strings, integers, foating-point numbers and sequences;
correctly receiving and handling any exceptions that we generated.
Our evaluation demonstrated that that IIOP does work (see chart, p. 6A).
Our main objective in evaluating the ORBs was to demonstrate functional interoperability. While some data regarding relative performance was also collected, we believe that comparisons of remote-method-invocation speeds is of secondary importance. We've found that the true issues of application performance using Corba ORBs are based much more dramatically on system architecture issues--such as the allocation of logic, persistence mechanisms, implementation object model, server implementation, and threading--than on the speed of the request over the network.
Java ORBs
One of the most pleasant surprises during the evaluation was the strength of the Java-based ORBs.
A though these products have been on the market only a short time, it's obvious that they were designed with a strong emphasis on IIOP support--which is not surprising given that Java is a likely choice for developers when creating distributed client applications.
Each of the three Java-based ORBs interoperated correctly with all of the server objects. The Java client applets were tested on a wide range of platforms, using both Netscape Navigator 3.01 and Microsoft Internet Explorer 3.0 browsers.
Although the ORB vendors still . have some work to do with regard to apples security, the ORBs we tested provide a reliable means for accessing distributed objects from Java applets.
At the time this article was written, there was still no OMG-adopted specification for mapping Corba IDL to the Java language. This spec is expected to be complete this spring, with compliant vendor releases to follow shortly thereafter. Until then, source code written for one Java ORB might not directly port to another vendor's Java ORB; however, the ORBs should be able to interoperate via IIOP.
Visigenic offers one of the most robust and easy-to-use Java ORBs (as well as a solid C++ ORB). Visigenic uses IIOP as its only communications mechanism, so there is no mapping to a proprietary internal protocol. It makes sense that Visigenic's implementation of IIOP was the most robust of those we tested.
The ease-of-use aspects of Visigenic's products include the generation of an intuitive C++ server skeleton, elegant IDL-to-Java bindings, and development-environment support for creating clients and servers. Ease of use is certainly relative. None of the products tested could be called an Integrated Development Environment (IDE) and none matched the ease of use of products like Microsoft's Visual Basic and Visual C++ or Symantec's Cafe. But then, ORB products must be supported on multiple platforms in order to really meet the goal of interoperability, and many of these platforms would not support a visual IDE (such as mainframe environments like MVS).
Distributed Capabilities
Iona leads the Corba ORB marketplace in both market share and mindshare. To strengthen its base product, Iona has successfully established key partnerships with companies such as Transarc Corp. and Isis Distributed Systems, which has resulted in the addition of object transaction services and fault tolerance.
Having long provided a C++ ORB and having ported this ORB to an extraordinarily wide number of platforms, Iona recently introduced its Java ORB product, OrbixWeb. We were surprised to encounter a number of problems in getting Iona's C++ ORB to work with other vendors' ORBs.
Our greatest concern was that the Orbix 2.1 C++ client was unable to interoperate with NEO and VisiBroker server objects, even though it was able to interoperate with Orbix server objects using IIOP. Of less concern was NEO's inability to interoperate with an Orbix server object, since the NEO product we evaluated was a beta release.
Iona was generally helpful in working with us to solve these problems. But we were surprised that we had to call on support so often to do something that should have been simple and relatively transparent.
Sun had the most comprehensive offering of those we tested. Sun promises to provide a number of services in addition to the base ORB, including Naming Service, Property Service, Lifecycle Service, Event Channels, and Relationship Service. While we verified that these services were in the beta, we did not test them extensively.
In addition to the ORB and the services, Sun's offering also provides a fair amount of support for a truly scalable development environment, addressing issues such as separation of development and production environments, migration of implementations from development to production, as well as deployment and administration support.
This is primarily due to the fact that Sun's C++ ORB is supported only on the Solaris platform, which makes it easier to support a more complete development and production environment.
Sun's ORB and IIOP implementations functioned as well as the other vendors', although there were some shortfalls in what we have come to expect from a Corba ORB (such as a lack of support for(underbar)var and (underbar)ptr mappings, which meant we could not perform some space-or time-sensitive memory management). Sun claims these issues will be addressed in the production release, which should be available this month. Though we tend to take vendor promises with a grain of salt, we are excited about the potential of the eventual Sun product.
Wider Specifications
OMG's Corba specifications cover both the ORB and a number of additional services. Version 1.0 of the Corba specifications failed to adequately cover the issue of ORB interoperability. While the advent of Corba 2.0 ORB specifications came a long way toward pinning down the holes that were in the version 1.0 specification, there are still a number of areas left either unaddressed or loosely addressed. This allows a fair amount of variability in vendor implementations.
Corba 2.0 compliance has not yet completely solved the interoperability problem, in part because a standardized and accepted compliance test suite is still being worked out. Despite the issues of compliance, our evaluation indicates that ORB vendors are racing toward plug-and-play interoperability.
Which product is right for you? That depends on your environment. Visigenic's IIOP, Iona's support for Object Transaction Services and fault tolerance, Sun's consideration of large-scale development issues--what is most important? The most exciting aspect of IIOP is that you can mix and match vendor ORBs in your enterprise to meet a variety of distributed computing challenges. Each of these subset solutions will work together and provide a common foundation for object-oriented code development and component reuse. We've never been closer to realizing the promise of distributed objects.
~~~~~~~~
By Michael McCown and Jason Pritchard
Michael McCown is VP of business systems and Jason Pritchard is a senior software engineer with PSW Technologies Inc., an Austin, Texas, systems integrator specializing in object-oriented application development and distributed systems. They can be reached at mccown@pswtech.com and jason@ pswtech.com, respectively.
Stubs/Skeletons GIOP IIOP TCP/IP Building block: IIOP is the TCP/IP version of the General Inter-ORB Protocol. DATA: OBJECT MANAGEMENT GROUP
Vendor Product Platform Iona Technologies Orbix 2.1 Sparc/Solaris 2.5 Cambridge, Mass. 800-672-4948 OrbixWeb 2.0 Sparc/Solaris 2.5 www.iona.com Sun Microsystems NEO 2.0 Sparc/Solaris 2.5 Mountain View, Calif. 415-968-6292 Joe 2.0 (beta) Sparc.Solaris 2.5 www.sun/com Visigenic Software VisiBroker for Windows NT 4.0 San Mateo, Calif. C++ 1.51 415-286-1900 VisiBroker for Sparc/Solaris 2.5 www.visigenic.com C++ 1.51 VisiBroker for Sparc/Solaris 2.5 Java 1.2.4 Vendor Language Iona Technologies C++ Cambridge, Mass. 800-672-4948 Java www.iona.com Sun Microsystems C++ Mountain View, Calif 415-968-6292 Java www.sun/com Visigenic Software Visual C++ San Mateo, Calif. 415-286-1900 C++ www.visigenic.com Java DATA: INFORMATIONWEEK
Legend for table: A - VisiBroker Server NT 4.0 C++ B - VisiBroker Server Solaris C++ C - VisiJava Server Java D - Orbix Server C++ E - NEO Server C++ A B C D E VisiBroker NT 4.0 X X X X X Visual C++ client VisiBroker C++ X X X X X TTY client VisiBroker Java X X X X X applet Orbix C++ TTY -- -- -- X -- client OrbixWeb Java X X X X X applet NEO C++ TTY X X X -- X client Joe Java applet X X X X X DATA: INFORMATIONWEEK
Title: | Alliance to tackle CORBA drawbacks. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on the collaboration between IBM Corp., Oracle Corp., Sun Microsystems Inc. and Netscape Communications Corp. to enhance the Object Management Group's standards. Efforts to make it easier to build Common Object Request Broker Architecture (CORBA)-based applications. |
AN: | 9703262671 |
ISSN: | 0893-8377 |
Database: | MasterFILE Premier |
Section: NEWS
Four industry powerhouses are banding together to accelerate object standards on the Web in direct opposition to MicrosoftCorp.'s object standard efforts.
The goal of the alliance between IBM Corp., Oracle Corp., Sun Microsystems Inc. and Netscape Communications Corp. is to enhance and fill holes in the Object Management Group's (OMG) standards,including the Common Object Request Broker Architecture (CORBA), so the standards can work well with the new breed of Internet applications. There is no timetable set up for the rollout of the plan.
The move makes it easier for VARs to build CORBA-based applications, but they increasingly will have to choose between CORBA and Microsoft's object standard,said vendors and analysts.
"What we want to do is accelerate to Web speed these standards," said Jerry Held, senior vice president for server technologies at Oracle. "We want to provide a clear alternative to those proprietary standards such as ActiveX from Microsoft."
Specifically, the group is trying to coalesce around Netscape's Internet inter-orb protocol (IIOP) standard and the various IIOP interfaces.
But the alliance also is developing standards such as security services, naming services, transactional services, directory services and other items, which are not yet part of CORBA or are deemed inadequately defined by the four companies.
The four companies have pledged to first come up with their own standards in these areas, then to make their own particular development environments adhere to the standards. They then will submit these standards to the OMG for approval.
Executives from the four companies did not say what technologies would be priorities or give a timetable of when the enhancements would be submitted to the OMG.
"We are focused on 1997; although there are a number of areas that will take us beyond 1997, there are some specifications that we are working on right now," said Steve Mills, general manager of IBM's Software Solutions Division.
Microsoft, which seems to be the main target of the alliance, was quick to respond tO the initiative. "Somebody had to do something about CORBA because there is no interoperability and it doesn't add much value to customers," said Cornelius Willis, Microsoft director of platforms marketing.
Karen Boucher, director of research at the Standish Group, Dennis, Mass., said CORBA does have some problems. But she said those problems can be solved. "This stuff does work--it is difficult sometimes, but it does work."
The alliance's work would make it easier for developers to build CORBA applications that interoperate, she said.
"Individually, it's hard for these companies to go against Microsoft, but together they have a good story," she added.
"If you are an Oracle developer, it will now be easier [also] to become a Netscape developer," said David Pann, group product manager at Netscape.
It is unclear how the rest of the OMG, which has 700 members, will fit into the plan. But Boucher implied that whatever the four companies decided would be accepted by the OMG.
"By us [four] endorsing it, we think it will be the de facto standard," said Pann. Industry observers, however, said the OMG processes would not be circumvented.
FAST FACTS
VARS WILL HAVE TO CHOOSE BETWEEN CORBA, MICROSOFT.
OBJECT MANAGEMENT GROUP TO APPROVE ALLIANCE'S NEW STANDARDS.
~~~~~~~~
By SHAWN WILLETT, San Mateo, Calif.
Title: | Vendors to push component wares at Object World. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on the introduction of products based on the Object Management Group's (OMG) CORBA at the Object World exposition in Boston, Massachusetts. CORBA market's competition with Microsoft's Distributed Component Object Model technologies; OMG's development of a Portable Object Adapter for the portability of object request brokers; Platinum Technology's Paradigm Plus Learning Edition and Professional Edition. |
AN: | 9704113629 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: COBRA technology
THIS WEEK'S Object World exposition in Boston will demonstrate the increasing proliferation of products based on the Object Management Groups (OMG's) CORBA.
Many CORBA developers will unveil products that implement the latest OMG specifications, including security and transactions, while crucial additions to the architecture -- such as messaging and standards for analysis and design -continue to be honed.
Despite its recent momentum, the CORBA market faces the imminent challenge of Microsoft's Distributed Component Object Model (DCOM) technologies, which spearhead the Redmond, Wash., software giant's enterprise software push.
"The lack of [Transaction Server] DCOM and Falcon [message-oriented middleware] from Microsoft gives CORBA vendors an important window of opportunity over the next 18 to 24 months, but Microsoft will get there with the DCOM infrastructure, transactions, and messaging," said Melinda Ballou, senior analyst with the Meta Group, in Stamford, Conn.
In addition to hammering out the integration of messaging support within the CORBA architecture and bridging DCOM and CORBA, the OMG is working on a Portable Object Adapter for the portability of object request brokers (ORBs).
Among those vendors looking to push objects toward the mainstream is Platinum Technology, which this week will unveil entry-level and departmental versions of its Paradigm Plus analysis and design package.
The company's Paradigm Plus Learning Edition and Professional Edition are single-user versions of the enterprise-level tool that sport limited versions of its modeling and round-trip engineering capabilities. The Learning Edition will be distributed for free; the Professional Edition will cost $1,495 for a single-user license.
ICL Inc. will update its DAIS ORB with security services that conform to the OMG's security specifications, including user authentication, access control, security associations, message protection, auditing, and administration.
Expersoft will unveil an upgrade of its CORBA-plus C++ ORB that boasts a 40 percent performance boost and support of CORBA events and relationships services.
Irish middleware developer Iona Technologies, which last week issued an initial public offering, will debut an implementation of the CORBA Trader technology that applies fuzzy-logic search capabilities to object browsing.
~~~~~~~~
By Ted Smalley Bowen
Title: | Object-oriented world speeds up application development. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Features Concorde Solutions' implementation of CORBA-based object-oriented technology to speed up application development to solve changing business conditions. Company background; Examples of object-oriented technology implemented by the company; Benefits of the technology. INSETS: Year 2000: Gone already? |
AN: | 9704113732 |
ISSN: | 0199-6649 |
Database: | Academic Search Elite |
Section: ENTERPRISE COMPUTING: MANAGEMENT
IN TODAY'S highly competitive business climate, it's just as important for a bank to get its products and services to market as it is for manufacturers, says Isaac Applbaum, president and CEO of Concorde Solutions, in San Francisco, a recently formed subsidiary of financial giant Bank of America.
"Our mission is to empower the bank's executives to get at their information through the A4 paradigm: anywhere, anyplace, anyhow, anyway," Applbaum says.
That information exists within a horizontal framework in many disparate legacy systems in the bank's enterprise. Until a few months ago, Bank of America's business managers did not have an easy time collating all the vital financial data about a corporate customer on their desktop PCs.
One of the applications Concorde developed was a corporate-customer, relationship-management system called Vista. It allows you to take accounts and drill down and extract customer information from many varied systems. The tools that built this application were based on CORBA-compliant object-oriented technology.
THE OBJECT-ORIENTED SCOOP. Bank of America did not reach into a magician's hat and decide on a whim that object-oriented technology was the solution to a complex business process. The bank's flirtation with object-oriented technology began in 1991. It had just rolled out a client/server re-engineering product that it hoped would solve the problems it was having with specific mainframe applications that resided in the telecommunications area.
"The applications weren't scalable," says Narinder Bajwa, the systems architect who piloted the bank's first use of object-oriented technology. "They were difficult to maintain and even more difficult to evolve and adapt to meet our rapidly changing business conditions."
But the bank soon discovered that the client/server concept coughed up a variety of interoperability and administrative issues IT wasn't prepared to handle. Bajwa and his team decided that object technology might provide the right solution.
With the assistance of outside consultants and mentoring assistance from IBM, Bajwa had a working prototype of his Network Management and Configuration application ready in six months. It took another year to pilot test and deploy the application. Although its roll-out in early 1993 was hugely successful and won the bank some industry awards in 1994, no one was jumping on the object-oriented technology bandwagon --yet.
Bajwa and his associates were aware that before more object applications were designed, several key functions had to be put in place. These he characterized as an infrastructure of object-based components that communicate across the enterprise and as a development process for the program modeling.
"The application has to be able to speak the user's language," Bajwa says.
To create this synthesis, it is necessary for developers to work closely with users during the program modeling so that the application responds intuitively to the way users need access to data. Dumping an application on a user's desk is not the answer, Bajwa adds.
Somewhere down the road the business process will change, and developers have to respond by making those changes quickly.
"If you involve users in the development process to the point where they understand how objects work, their input on future revisions will be most helpful," says Paul Westover, vice president of global payment operations, who has worked closely with the banks object-development teams.
THE HIRED GUNS. Bank of america created Concorde in 1995 to build object functionality into the bank's existing mainframe systems and to create a library of business objects that could be used and reused throughout the bank.
"We're domain experts," Applbaum says. "We understand what to build and how to build it, and we bring in partners to help us build specific applications."
So even before the Corporate Customer Relationship Management System was coded, Concorde built the Data Object Module (DOM).
Applbaum characterizes this as Concorde's most critical contribution to the bank's enterprise. It's the transport broker that sniffs out and collects the legacy data across many varied systems, from mainframes to servers such as IBM RS6000s, Sun Sparcservers, and Hewlett-Packard HP9000s.
DOM was designed as a series of business objects that can talk to all the different middleware, whether it's MVS or CICS. And because DOM was built around the CORBA architecture, its components can be plugged in to any application.
"Many companies fail with objects," Applbaum says, "because they try to build applications before they have their architecture and infrastructure in place."
Applbaum says that the Corporate Customer Relationship Management System took 15 months to develop using Microsoft C++ and IBM's System Object Model toolkits. He says that Concorde is investing extra time and money to make certain that object modules have as much reusability as possible.
"Building a one-off application would be a lot faster," Applbaum says, but that's not building for the future.
By creating reuse the first time, developers can reduce the amount of time it takes to write future applications.
Applbaum says that there have been significant reductions in development time on the second application that is scheduled for rollout later this year in the bank's consumer retail-banking division because many common business objects can just be plugged in.
Called the Credit Card OnLine System, it will allow customers to access information about their credit-card history via the Internet. The bank side of the application contains customer-service functionality, customer-credit information, cycle-state information, account history, and transaction history.
Because Concorde isn't married to any one set of CORBA-compliant object tools, it is following a path of using the best solution available for a specific application. For example, Hitachi's transaction-processing monitor and Visigenix's object request brokers (ORBs) provide the core tools for the credit-card application.
Now that ORBs containing vertical-market solutions for the financial industry are arriving, Applbaum's subsidiary is evaluating them for future object-application development.
"That makes a great deal of sense," says Karen Boucher, senior analyst with The Standish Group, in Dennis, Mass. "Why reinvent the wheel when you can buy a packaged ORB that gives you up to 85 percent of the functionality that you need to build your application." The savings can be enormous, she adds.
Bank of America is determined to be a leader in object development for the financial services and banking industry, Applbaum says, and Concorde will be given the go-ahead to license and sell its core business objects to other financial institutions.
PHOTO (COLOR): USING NEW APPLICATION TOOLS, Bank of America's Narinder Bajwa and Isaac Applbaum have reduced development time.
Problem: How to speed up application development to solve changing business conditions.
Solution: Use CORBA-based object-oriented technology.
Benefit: Can reuse existing business objects to build foundations for new applications, thereby saving development time and money.
~~~~~~~~
By Peter Ruber
Peter Ruber is an Oakdale, N.Y.-based freelance writer.
Title: | Corba snakes into embedded net. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Focuses on the common object request broker architecture (CORBA) computer architecture. CORBA's features; Corba's acceptance in embedded systems. |
AN: | 9702042066 |
ISSN: | 0192-1541 |
Database: | Academic Search Elite |
Section: BEST 1996 TECHNOLOGIES
One of the major technology trends in embedded systems in 1996 has been the move by software developers and systems designers to incorporate the common object request broker architecture (Corba) into their products. Already accepted in the desktop, workstation and server markets, Corba offers cross-plat-form portability and the availability of development tools from more than 500 vendors.
However, embedded developers face drawbacks: memory requirements beyond the limits of many designs, slower performance due to additional overhead required by the object layers, and the need to learn a new language and set of interfaces.
Nevertheless, Corba is gaining in embedded systems. The most recent sign was this year's introduction of Integrated Systems Inc.'s (Sunnyvale, Calif.) Prism+ embedded-development-tools suite built around an object bus that conforms to the Corba 2 standard, a middleware specification created and controlled by the Object Management Group standards body. Supported by more than 700 companies, the Corba object bus provides a unified system architecture and capability to support components that run in the same process, as well as components that run across a distributed system.
It also provides an extensive set of bus-related services for creating and deleting objects, accessing them by name, keeping them in persistent store, externalizing their states and defining ad hoc relationships. The object request broker (ORB) is the middleware that establishes client-server relationships between objects. An ORB allows a client to transparently invoke a method on a server object on the same machine or across a network. It intercepts a client call and is responsible for finding a server object that can execute the request, passes the parameters, invokes its method and returns the results.
This is all accomplished without the client having to know where the object is located, its programming language, its operating system, or any other system aspects that are not part of an object's interface. The Corba ORB provides complete interoperability between applications on different machines in heterogeneous distributed environments, seamlessly interconnecting multiple systems within a work group, an enterprise, a LAN, or a WAN.
In the ISI implementation, the Corba bus is used to link development tools, all of which are accessible via the Prism+ Manager graphical user interface; a set of dedicated servers that provide support to all client software tools; and a set of support services. The tools linked together fall into three categories: project management tools; development tools for coding, debugging, and integration; and analysis and visualization tools. All are provided a common set of services via four types of server programs: the repository and symbol server, the debug server, the communication server, and the Prism+. In addition to the Corba bus, what makes the new tool suite unique, said John Hogan, director of product marketing at ISI, is the linkage to all of the Corba services provided by the more than 500 software vendors in the Object Management Group (OMG).
The introduction by ISI is the most recent move by embedded tool vendors to accommodate the Corba 2 specification, a process that started late last year with many of the RTOS vendors working out cross-licenses and technology agreements and integrating a number of Corba-based tools into their development environments.
Telecom imperative
Initially, the key reason for the move was the increasing importance of Corba to the telecom market and the providers of the switch-based public telephone and telecommunications, such as AT&T, MCI and U S West.
Stephen Li, vice president of telecom products at WindRiver Systems Inc. (Alameda, Calif.), said the telecommunications companies have long been users of embedded processors and OSes, but until the last few years, on the software side at least, telecom vendors have stuck to an inhouse strategy. But with the opening up of the telecommunications market to a wider range of companies, telecom providers are outsourcing many components of their hardware and software, going to the embedded market for off-the-shelf designs. "They are also the biggest backers of standards and have played a key role in promoting and sup, porting the Corba specification," Li says. "So any hardware or software vendor who wants to play in that market had better be aware of that."
This has led many of the leading RTOS and development-tool vendors, including ISI, Microtec and WindRiver, to link tools from a variety of Corba-based providers into their environments. Some of the most important Corba vendors are Iona Technologies Inc., an ORB development-tool vendor; ObjecTime Ltd., a real-time object-oriented tool provider; and Visigenic Systems Inc., a Corba tools and services vendor. "As reliability and correct code become more of an issue, especially in markets like telecommunications, such tools remove another portion of the software with which the engineers have to concern themselves," said Jim Ready, chief technical officer at Microtec (Santa Clara, Calif.). "This approach also reduces the relearning time to become competent in the intricacies of Corba compliance and decreases the time it will take to get to market."
A second reason for the increased attention to Corba has been the emergence of embedded-systems and RTOS opportunities in set-top boxes, Web TVs, network computers and information and Internet appliances. "A key aspect of all of these devices is the idea of thin clients, which contain a minimum of applications software and just enough of a kernel to run the graphical user interface," said Dan Hildebrand, senior software designer at QNX Systems Software Ltd. (Kanata, Canada).
"The servers take over the vast majority of the computing operations," he said, "with only the results displayed on the connected thin client."
Getting the paradigm to work requires not only a distributed-objects environment, but one in which the objects can function on any platform, independent of the underlying OS or hardware. That requires adherence to a common standard such as Cor-ba to achieve such platform independence and interoperability, Hildebrand said.
Beyond such emerging markets, said Ready, a wider role for Corba in the embedded market is not likely soon. "A common characteristic of these new markets is that while the memory requirements are smaller than those required for the desktop, typically from 1 to 4 Mbytes vs. 8 to 16 Mbytes, the extra memory space to allow for the extra layers of software that the protocols would require would fall very easily within this range." But for traditional embedded applications, even those that require some form of distributed control, that's far from the case.
Li said work is under way within the OMG to come up with a subset of Corba that is more appropriate to the embedded market. "There is a lot of overhead in the existing specification, which was designed mainly for desktop systems, that is simply unnecessary in the embedded environment.
"The trick will be to come up with a set of features and capabilities appropriate to the embedded market, without violating the spirit of the full specification. That ... will not occur very soon."
DIAGRAM: Cobra is object of ISI bus
SOURCE: ISI
~~~~~~~~
By Bernard Cole
Title: | Corba provides transparent data access. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Discusses the use of the common object request broker architecture (Corba) in the design of embedded computer systems. Benefits of Corba as an inter-application communications standard; Bridge between Corba and Microsoft's object linking and embedding (OLE) system; Design initiatives on the part of the Corba Object Management Group. |
AN: | 9702042022 |
ISSN: | 0192-1541 |
Database: | Academic Search Elite |
Section: Embedded Systems
Developers' demands for applications and tools that interoperate within an open framework have resulted in the development of the common object request broker architecture, or Corba, an inter-application communications standard that was introduced in 1991 by the Object Management Group (OMG). OMG is a non-profit industry consortium dedicated to promoting the theory and practice of object technology for the development of distributed computing systems.
Corba's platform-independent nature provides a seamless communication mechanism that enables developers to access information transparently--that is, without having to know which software or hardware platform that information resides on or where it is located on a network. Corba 2.0, introduced in 1994, defined true interoperability by specifying how object requestbrokers (ORBs) from different vendors can operate together.
The ORB is the middleware that establishes client/server relationships between objects. The Corba ORB provides complete interoperability between applications on different machines in heterogeneous-distributed environments, seamlessly interconnecting multiple systems within a work group, an enterprise, a LAN or a WAN.
Integrated Systems Inc. (ISI) adopted Corba as its open tools framework for the company's Prism+ embedded development tools and for interprocess communications in ISI's pSOS realtime operating system. Other highly influential industry players, such as Netscape Communications Corp., Oracle Corp. and Informix Software Inc., have also announced Corba initiatives.
As a software backplane for an embedded-software tool-development environment, Corba's Internet InterORB protocol (IIOP) lets objects use queues and interprocess communications to speed up message delivery and reduce overhead. IIOP transport services are provided for interoperability between heterogeneous ORBs,and IIOP allows objects developed using different Corba ORBs to interoperate transparently.
Abridge between Corba and Microsoft Corp.'s object linking and embedding (OLE) even allows Corba-compliant applications to communicate with commercial OLE-compliant analysis software.
ISI's embedded development tool, Prism+, was created around two key technical concepts: Prism+ servers, and an open, distributed, Corba-based communication framework. The implementation of these concepts allows Prism+ tools to be tightly and efficiently integrated with other tools-of-choice from other vendors. Both Prism+ tools and servers interface with the Corba bus via a common API known as interface-definition language (IDL). Components written to the Corba IDL are portable, and can be bound to various programming languages such as C/C++, Java and SmallTalk, and can be used across heterogeneous networks.
New initiatives on the part of the Corba Object Management Group, in relation to the Internet, bring an additional set of possibilities to a design environment built around the specification. In particular, OMG has started a new initiative to demonstrate Corba interoperability via the World Wide Web. Called Corbanet, its focus will be to provide Corba-based product vendors with a vehicle to demonstrate interoperability, and their Corba2.0 conformance, to a worldwide audience through the Web.
In addition, Netscape Communications Corp. is strongly promoting the Corba IIOP as a new Web protocol, and is planning to integrate Corba into its products. Netscape's latest offering, the Netscape ONE development environment, will include support for a distributed-object model based on the IIOP standard. Netscape ONE is an open network environment, based on publicly defined standards, which lets developers and enterprises quickly and easily create robust, dynamic, cross-platform Internet/intranet applications.
Netscape ONE's IIOP-compliant infrastructure transparently supports distributed method innovation for Java classes. This infrastructure includes IIOP-compliant Netscape Internet foundation classes, making it easy for developers to build Web-based distributed applications. In addition, client/server systems that are Corba-compliant can be interfaced to Netscape ONE applications via the IIOP protocol. Netscape also plans to include a fully IIOP-compliant ORB into Galileo and Orion.
Other companies also have announced their intentions to employ Corba.
DIAGRAM: Corba means interoperability. SOURCE: ISI
~~~~~~~~
By Nick Epperson, Director of Tools Integrated Systems, Inc. Sunnyvale,
Calif.
Title: | Corba for credit-card account info. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on Bank of America's plans to launch an object-based customer service. Features of the Concorde CreditCard OnLine; Use of the Corba standard for the deployment of distributed objects. |
AN: | 9701145127 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
Section: Top Of The Week
Bank of America's Concorde Solutions Inc. software subsidiary announced last week plans to build an object-based customer service system that will let credit-card holders access account information over the Internet. The system, due next spring, will be based on Corba, a network-independent standard for deploying distributed objects. The project marks Bank of America's second major deployment of Corba. The company is already using an object-based customer relations management system called Vista.
The forthcoming system, Concorde CreditCard OnLine, will give the bank's credit-card customers access to their accounts over the Internet and let them perform the functions normally available via a customer service line, such as checking balance and payments, says Isaac Applbaum, president of Concorde Solutions in Concord, Calif.
Concorde chose Corba because the company felt no other architecture delivers the kind of scalability necessary for handling a large volume of users and data. "We like Java, but we don't think it will be ready when we're going to be ready," says Applbaum. "With Corba, we know it works. [Vista] is in production, and it works."
CreditCard OnLine will be built on Hitachi Ltd.'s TP-Broker object transaction manager, a combination of Hitachi's OpenTP online transaction processor and Visigenic Software Corp.'s VisiBroker Object Request Broker. CreditCard OnLine is set for deployment to Bank of America employees in March, with full consumer availability coming in June, says Applbaum.
"What they are doing is absolutely incredible," says Karen Boucher, an analyst with the Standish Group, a consultancy in Dennis, Mass. "Concorde has pushed Bank of America further into object technology than any other company I've seen. Vista and CreditCard OnLine have proven that objects are capable of creating mission-critical transactional applications."
PHOTO (COLOR): Sure: Concorde chose Corba because "we know it works," says Applbaum.
~~~~~~~~
By Andy Patrizio
Title: | Corba stakes out new territory. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Looks at growing interest in Object Management Group's Common Object Request Broker Architecture (CORBA). Releases of related products and tools as evidence for this growing interest; Examples of these products; Factors behind the driving interest in CORBA. |
AN: | 9609205043 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
Section: APPLICATION DEVELOPMENT
For a technology that has languished for several years, the Object Management Group's Corba specification is showing strong signs of life. Interest in Corba-related products is at an all-time high, as evidenced by a slew of product announcements over the past several weeks.
"Corba is starting to grow up," says Jeffrey Nickerson, technical director of emerging technologies for Coopers & Lybrand in Edison, N.J. "Corba development tools are maturing, and corporations are building applications with them. Most important, the tools vendors recognize there's a market here."
Having the support of major tools vendors is critical to Corba's success, Nickerson says. "Corba is great, but look at the size of the companies support it. They're tiny. The involvement of big, stable companies, like Sun and IBM, will give users a feeling of security." In fact, Sun Microsystems and IBM recently announced a cross-licensing deal to share their respective object technologies (IW, Aug. 19, p. 15).
OUTPOURING OF TOOLS
Corba is the Common Object Request Broker Architecture, an open specification that defines how objects-reusable chunks of code that make up client-server applications-communicate in distributed environments. Until recently, Corba was used primarily by C++ developers building Unix applications. However, there's been an outpouring of Corba tools for other programming languages and operating environments.
Corba tools that support Sun's Java, Microsoft's ActiveX, and numerous 4GLs were in full bloom at the recent Object World conference in San Jose, Calif. The Object Management Group (OMG) announced that member companies are supporting its ActiveX/Corba Interworking Specification. ACIS specifies a bidirectional communication mechanism between the ActiveX common object model and Corba objects, which ensures that objects from either object model can talk to each other.
Digital Equipment, Expersoft, Hewlett-Packard, Iona Technologies, and Visual Edge Software already ship Corba products with ACIS capabilities built in. Work is now under way to incorporate Microsoft's distributed common object model (DCOM) specification into ACIS.
Next Software Inc. of Redwood City, Calif., also threw its hat into the Corba-to-ActiveX ring. The vendor announced Corba support for its WebObjects and OpenStep development platforms. Next uses Iona's Orbix ORB object request broker in its tools, and has adopted ActiveX in its framework. The two developments give Next users near-seamless connectivity between Windows and Corba applications.
While some companies integrate Corba with other object technologies, other vendors are working to improve Corba's raw performance. On Aug. 19, embedded systems vendor Chorus Systems of Campbell, Calif., announced version 3.1 of its Corba-com-pliant Chorus/Cool ORB, which the company says communicates three times faster, and requires 50% less memory, than other shrink-wrapped object request brokers.
Chorus' Chorus/Cool ORB supports Windows 95, Windows NT, Linux, IBM AIX, Sun Solaris, SunOS, and SCO OpenServer 5. Cool ORB interoperates across all the supported platforms. Chorus officials say they are now working on adding support for HP/UX, SCO UnixWare, and Java.
Hewlett-Packard in Palo Alto, Calif., and Persistence Soft-ware in San Mateo, Calif., are tackling Corba's biggest weakness: the difficulty of implementing Corba's many distributed object services. Persistence's Orbix Interface Generator makes it easier for developers to tie Iona's Orbix ORB with Persistence's application server. This lets programmers develop applications that communicate with backend relational databases using object messaging.
HP is turning to application development "wizards"-step-by-step, procedural assistants-to guide programmers through the creation of Corba objects. The wizards will first appear in HP's ORB Plus 2.0. The product will also interoperate with the ActiveX component standard.
WEB OBJECTS
The advent of distributed computing over the Internet is perhaps the primary force driving interest in Cot-ha. ORBs that conform to the Corba specification are preferred by developers who want to join Web application servers and browser applications.
Like HTML, the language of theWeb, Corba ORBs are platform independent and can run across a variety of operating systems. Other object technologies, such as ActiveX and Netscape Plug-Ins, are hard-wired to their respective platforms. "The OMG's purpose is not to create a product, but rather to produce a standard for vendors to interpret," says Albert Eng, director of financial technology for the Canadian Imperial Bank of Commerce in New York.
Growing industry interest in Corba is bad news for Microsoft. It contends that OMG's Corba will remain a largely unadopted technology, one that Microsoft steadfastly refuses to support. "We don't focus on putting nails in [OMG's] coffin; they do a fine job of that by themselves," quips John Ludwig, VP for Microsoft's Internet tools and platforms division.
Even Corba proponents admit the technology has a long way to go before it poses a severe threat to Microsoft's ActiveX object technology. Corba may be technologically superior to ActiveX, but using Corba services is far more difficult than dragging-and-dropping an ActiveX control onto a Visual Basic form.
It takes a lot longer to build a Corba server than it does an OLE server, but the distributed capabilities of Corba services are greater, says Eng.
"With ActiveX, you just need a Visual Basic programmer, and you can get an OLE server running," he says. "But you get what you pay for."
PHOTO (COLOR): Spritely: Chorus/Cool ORB manages the interaction of objects across Solaris, Windows NT, Linux, and Chorus/OS.
~~~~~~~~
By Rich Levin
Title: | Corba middleware. |
Subject(s): | |
Source: | |
Abstract: | Reports on Expersoft Corp.'s formation of an alliance with Modulus Technologies Inc. to deliver the first Corba-compliant, integrated message-oriented middleware and object request broker. |
AN: | 9609111475 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
Section: In Shoft
Expersoft Corp. in San Diego and Modulus Technologies Inc. in Houston have formed an alliance to deliver what they call the first Corba-compliant, integrated message-oriented middleware (MOM) and object request broker (ORB). Expersoft plans to incorporate Modulus' MOM technology into its PowerBroker ORB. Both PowerBroker and Modulus' InterAgent MOM are Corba-compliant. A delivery data was not announced.
Objects first: PowerBroker ORB will integrate with InterAgent
middleware.
Title: | Corba gets center stage. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on the 1996 Object World Trade Show to be held in San Jose, California. Focus on the Common Object Request Broker Architecture (CORBA) computer network architecture; CORBA's features; Companies supporting the technology. |
AN: | 9608281748 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
CORBA GETS CENTER STAGE
After a five-year struggle, the technology known as Corba is gaining user interest as vendors roll out products that make use of the Common Object Request Broker Architecture. The interest will be evident at this week's Object World West trade show in San Jose, Calif., where Corba-compliant technologies will dominate product introductions, demonstrations, and industry alliances.
One of the most significant announcements, sources say, will be a cross-licensing agreement between Sun Microsystems and IBM that aims to let Sun's Solaris NEO, a Corba-compliant operating and application development system, interoperate with IBM's System Object Model (SOM) and Distributed System Object Model (DSOM). Officials at Sun and IBM acknowledge a cross-licensing agreement will be announced at Object World, but they refuse to provide details.
Sun's Joe, a Corba-compliant, Java-based object request broker, and IBM's MQSeries message-oriented middle-ware are expected to be mechanisms by which the partners provide inter-operability between their respective object models.
"The thing with Joe is that it is only going to Sun," says Don DePalma, a senior analyst with Forrester Research in Cambridge, Mass. "If IBM cross-licenses it, it's a quick step for them to get Java-to-SOM or Java-to-DSOM capabilities, which are IBM's object request brokers."
IBM's MQSeries middleware provides "a guaranteed delivery backbone for messages going across the network, and the messages could be Java-to-Corba ORB messages," DePalma says. "This adds some interesting capabilities like asynchronicity to object request brokers."
It could also make life easier for IS managers who are looking for major vendors such as Sun and IBM to support their Corba development efforts and applications. "So far, the Corba players have been tiny," says Jeff Nickerson, technical director of emerging technologies for Coopers & Lybrand in Edison, N.J. "To count on a company with 25 employees as your middleware provider scares a lot of people."
Several other companies are expected to make significant announcements at the show. Next Software Inc. in Redwood City, Calif., and Iona Technologies Ltd. in Dublin, Ireland, plan to reveal that Next will add support for Iona's market-leading Orbix 2.0 Corba ORB. Next will include Orbix with its WebObjects development platform and NextStep operating environment. This brings support for Corba 2.0 and Object Management Group's Internet Inter-ORB Protocol to both Next platforms. "It gives Next instant interoperability with the 20 computer platforms Orbix supports," a source close to the development says.
Also, Isis Distributed Systems in Marlborough, Mass., and Iona Technologies will announce Orbix+Isis for Windows NT. This product integrates fault-tolerant Corba objects with OLE interfaces. This lets popular development tools such as Microsoft Visual Basic invoke Corba objects through a standard OLE interface, according to company officials. Isis will demonstrate a Windows client application interoperating with back-end, fault-tolerant Corba applications.
In addition, DNS Technologies Inc. in San Francisco and GemStone Systems Inc. in Beaverton, Ore., will reveal a joint development agreement to integrate DNS's Smalltalk Broker Corba ORB with GemStone's Object Application Server. GemStone is a leading Smalltalk object application server for multitier client-server systems.
It is this rash of recent product releases that has users interested in Corba. "The distributed object-component architecture, whether it be Corba or [Microsoft's] ActiveX, is catching fire," says Albert Eng, director of financial products technology for the Canadian Imperial Bank of Commerce in New York. "Of the two, Corba is the compelling enterprise solution. It has a richer production environment, it's open, and it has proved it can be used in production settings."
Announcements of Corba support won't be limited to Object World West. On Aug. 19, sources say, Powersoft officials are planning to surprise attendees at the Powersoft Developer's Conference in Orlando, Fla., with a Corba-compliant version of Power-Builder 5.0. It will also feature support for Iona's Orbix.
One week later, IBM will roll out its OpenDoc 2.0 beta, adding Microsoft Windows 95 and Windows NT to the short list of supported operating systems. OpenDoc parts are cross-platform, Corba-compliant, drop-in software components for end-users and programmers. Previous OpenDoc prereleases supported Apple's Mac-OS and IBM's OS/2.
• Sun Microsystems and IBM will cross-license Sun's Corba-compliant operating and application development system and IBM's object request brokers.
• Corba will support Powersoft's PowerBuilder 5.0
• Next Software will announce support for Iona's Orbix Corba object request broker
~~~~~~~~
By Rich Levin
Title: | Netscape adopts CORBA object model for browser. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Introduces Netscape's Open Network Environment (ONE), a Java-based software development environment tuned for the Internet. Addition of the Common Object Request Broker Architecture's (CORBA) Internet Inter-ORB Protocol (IIOP) to version 4.0 of the Navigator Web browser software; ONE's inclusion of a Java class library dubbed the Internet Foundation Classes and Javascript version 1.1. |
AN: | 9610041856 |
ISSN: | 0746-8121 |
Database: | Academic Search Elite |
NETSCAPE ADOPTS CORBA OBJECT MODEL FOR BROWSER
A new Netscape application framework will let network managers deploy enterprise-wide intranet applications that are faster, more scalable and less bandwidth intensive.
Netscape's Open Network Environment (ONE), to be unveiled this week, is a Java-based software development environment tuned for the Internet. ONE will allow developers to take advantage of the Object Management Group's Common Object Request Broker Architecture object model to access applications residing remotely across the enterprise network.
While not abandoning the Common Gateway Interface (CGI) and HTTP interfaces, Netscape will add CORBA's Internet Inter-ORB Protocol (IIOP) to version 4.0 of its Navigator Web browser software. This will allow Web clients to invoke enterprise objects, processes and data directly, without having to access the Web server.
The result is that network managers will see lighter-weight database processes and easier maintenance of multitiered applications, according to industry observers.
In Line With Industry
"We have been using a third party's IIOP communications software, and Netscape's choice of an IIOP architecture helps to substantiate our efforts," said Jeff Scherb, executive vice president and chief technical officer of Dun & Bradstreet Software, Inc., Atlanta.
D&B's SmartStream Web Series, which does enterprise-wide financials and human-resource services, bridges the gap between Java objects running on existing client Web browsers, and middle-tier CORBA objects running on various enterprise servers.
The Open Network Environment will include a new Java class library that Netscape has dubbed the Internet Foundation Classes, as well as a new version of Javascript, version 1.1.
"Developers will no longer be writing directly to the metal," said Bob Lisbonne, vice president, client product marketing at Netscape. Instead, they will be using new higher-level tools from Netscape, Asymetrix Corp., Autodesk Inc., Borland International Inc., Corel Corp., Macromedia Inc., NetManage Inc., Next Software, Symantec Corp. and others in an overall application development framework.
The new Internet Foundation Classes (IFCs) will support Java, and, through Netscape's LiveConnect, can be accessed by JavaScript applications, HTML applications and third-party plug-ins. The new version of JavaScript will be able to pass parameters to other applications through LiveConnect. It will also be able to manage images on the HTML page and detect Netscape plug-ins.
Developers now have a choice between two basic object models, Microsoft's Common Object Model/Distributed COM and CORBA's, D&B's Scherb said.
"Microsoft has an impressive Internet strategy and we're evaluating pieces of it as it comes out, but the CORBA-Java-IIOP stuff exists today and, in comparison, is more mature," Scherb said.
"This is war," said Don DePalma, senior analyst at Forrester Research Inc., Cambridge, Mass. "It is the Mountain View coalition vs. the Redmond giant in a battle of dueling object models."
DePalma said he sees the Black Widow ORB development environment, which was developed by Post Modern Computing Technologies Inc. and licensed by Netscape as the heart of its client ORB-IIOP communications capability, as Netscape's trump card over Microsoft. "CORBA is more comprehensive, and more suited to the enterprise," he said.
Netscape's Lisbonne described Microsoft's Object Linking and Embedding Custom Controls as "legacy code."
He said that Netscape's support of CORBA standards does not include support of the recent CORBA-OLE gateway, which enables an OLE automation server to address the network as if it were a CORBA client stub.
"It may be a standard, but it's not a required part of the CORBA 2.0 standard," Lisbonne said. He added that developers can integrate existing C++ objects into their Internet applications through the Live Connect module.
Mike Kennedy, a program director at The Meta Group Inc.'s, Burlingame, Calif., site, says that sooner or later Netscape will be forced to include support for the CORBA-OLE gateway.
"Netscape doesn't recognize it yet, but they will have to support OLE-CORBA when ActiveX becomes distributed. Neither of the two object models will have a corner on everything," he said.
The ONE platform will roll out over the next three quarters. Navigator 4.0 will ship next quarter, and will contain the IIOP-CORBA-Black Widow software.
Two IFCs, user interface controls and user interface services, will also ship at that time, according to Netscape's Lisbonne. IFC classes for security, messaging, and distributed objects will ship in the fourth quarter of this year and first quarter of next year, along with a new generation of Netscape servers.
DIAGRAM: NETSCAPE'S IIOP CLIENT -- Netscape's Navigator 4.0 will contain a CORBA-compliant Object Request Broker (ORB), which will enable the browser to call remote programs, objects and data without channeling the requests through a Web server. Source: Netscape. Chart by Denise Edkins
~~~~~~~~
By MARTIN MARSHALL
Title: | Choose your architecture. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Focuses on the use of the Distributed Computing Environment (DCE) and Common Object Request Broker Architecture (Corba) in building large-scale distributed applications. Features; Complementary functions; Use of Corba-integrated applications in the Single Source of Product Data project. |
AN: | 9608070313 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
Section: Client-Server
Distributed Applications
Which widely backed, standards- based technology should you choose for building large-scale distributed applications? Does the Distributed Computing Environment meet your needs? Or will the Common Object Request Broker Architecture be a better fit? - Each has distinct strengths and weaknesses: DCE provides a good application infrastructure and cross-platform support but is complex to use and still lacks third-party software; Corba is still emerging and is relevant only for object-oriented systems. But-as you might expect since both are backed by most of the industry's big vendors-there's increasing interoperability, interreliance, and even overlap between the two technologies. The choices will be further complicated as Microsoft introduces its Distributed COM technology this year (see story, p. 57) and each technology weaves connections to the World Wide Web.
"We don't see DCE and Corba as competing technologies but as complementary ones that are on different maturity cycles, with DCE being the more mature," says Peter Barclay, manager of client-server services at manufacturing giant Caterpillar Inc. in Peoria, Ill. Caterpillar has rolled out DCE-based software to several thousand users, but found Corba products immature when it tested them last year.
Roger Gurnani, director of broadband systems at Bell Atlantic in Silver Spring, Md., says, "DCE is widely deployed and accepted across the [telecommunications] industry, while Corba holds the promise of reusability of objects and interoperability at the code level."
Anthony Brown, manager of object technology marketing at IBM in Somers, N.Y., says, "By 1997 or 1998, we expect to see more overlapping of DCE and Corba, although the essential differences between them will remain."
Those differences reflect the different heritages and goals of the two technologies. DCE, developed by the Open Group, an industry organization in Berkshire, England, is an attempt by vendors-including Digital Equipment, Hewlett-Packard, and IBM-to standardize the basic infrastructure for distributed applications. At DCE's core are standards for remote procedure calls (RPCs), directory services, distributed file systems, and security.
The Corba specifications are developed by the Object Management Group consortium in Framingham, Mass., whose members include Hewlett-Packard, IBM, Sun Microsystems, and most other big vendors. Corba provides a mechanism for different types of objects to interoperate via a piece of software called an object request broker (ORB); objects will be able to communicate over the Internet as well as internal networks.
Depends On The System
Right now, Corba and DCE are suitable for different types of systems, says Peter Tait, VP of marketing at PeerLogic Inc., a San Francisco tools developer. "If you're building an object-oriented system and want the benefits of object reuse, Corba is probably the choice because building them [objects] on top of DCE is hard work," he says. "But if you're not building an object-oriented system, Corba is irrelevant."
Though DCE hasn't been adopted as widely as originally predicted, large organizations including Caterpillar, Corning, and MCI have exploited its strengths.
Caterpillar, with some 60,000 users worldwide, picked DCE about two years ago to cut the cost and complexity of managing a three-tiered application architecture that included many different hardware platforms. Caterpillar installed IBM's MVS/ESA DCE software to let its mainframes work with distributed systems. "DCE gives us the ability to get interoperability among heterogeneous environments with good security," says Caterpillar's Barclay. The company also used DCE-based tools: the Entera development tools from Open Environment Corp., recently acquired by Borland International; and the Encina transaction monitor from Transarc. Caterpillar has rolled out its first DCE production application, which provides human resources functions, to thousands of employees.
However, DCE is far from trouble-free, Barclay says. "DCE is still very complex. We haven't been able to isolate our developers from the bits-and-bytes technical stuff of detailed C code," he says.
But Corba has proved even more troublesome. Barclay says Caterpillar tested Corba-based applications last year and experienced performance problems. "Corba 2.0 [the latest release of the Corba standard] was still being defined. Our programmers were taking too granular a view of objects, and consequently were making so many requests to ORBs that they were flooding the network."
Corba is being deployed, though, at some companies. Aircraft maker Boeing is using Corba to integrate off-the-shelf applications at one 250-person site, for example. In the coming months, the technology will be used by 1,000 more Boeing users at other sites, according to Ron Trout, a systems integration manager at Boeing's commercial airline group in Renton, Wash.
Boeing picked Corba last year as part of a reengineering effort aimed at revamping its manufacturing to simplify processes and systems and to reduce costs and product cycle times. "We adopted Corba as the standards-based foundation for systems integration, believing that an object-oriented approach would help us reduce the time it takes to integrate our computing applications," Trout says.
Options Evaluated
The Corba-integrated applications are being used in an important project called Single Source of Product Data (SSPD), an effort to manage access to and control of enterprisewide product data. "After evaluating our options for SSPD-DCE, Corba, and messaging middleware-we decided to choose off-the-shelf commercial applications and integrate them using Corba," Trout says.
Boeing selected applications from Baan International, CIM-LINC, Structural Dynamics Research, and Trilogy Development Group. Boeing found that Corba-compliant object-oriented technology seemed to be the only practical way to integrate such a diverse set of applications, according to Trout. For its Corba technology, the company chose the Orbix ORB from Iona Technologies in Dublin, Ireland.
When companies weigh the pros and cons of choosing DCE, Corba, or both, they must decide how far along the leading edge they want to be, advises Michael Kennedy, an analyst with the Meta Group in Burlingame, Calif.
"DCE has been around a lot longer, has more implementations, and is embedded in leading operating systems," he says. Kennedy notes, however, that DCE has fallen out of favor with some users because of its complexity, lack of third-party software, and weakness in object technology.
Yet DCE and Corba are moving closer together. "DCE started from a bottom-up focus, with people who wanted to build the communications infrastructure for supporting distributed applications," explains PeerLogic's Tait. "Corba came from people whose primary interest was to define how one object calls another-without caring what was underneath those objects. Gradually, we're starting to see the coming together of these two sets of focuses."
Some vendors' ORBs use DCE RPCs as a basic communications mechanism, for instance. A recent Open Group project aims to facilitate the integration of DCE with object-oriented technologies, while improving DCE's ease of use and object-oriented capabilities. The project's goal is to provide a standard set of object-oriented libraries by integrating HP's Object-Oriented Distributed Computing Environment technology with the latest release of DCE.
"The provision of object-oriented class libraries in DCE eliminates the need for vendors and customers to develop their own, potentially incompatible, solutions," says Mike Lambert, VP and chief technical officer of the Open Group.
Today, only a handful of users are likely to be able to take advantage of that integration, since the hype about objects far exceeds their marketplace success. "Most Corba-based products are not mature, and only a couple are ready for mission-critical applications today," says Roy Schulte, VP of systems software at Gartner Group Inc., an IT advisory firm in Stamford, Conn.
Still, Schulte, Kennedy, and others believe that the market for object technology will take off in the next few years. "By 1999," says Kennedy, "most organizations will have a heterogeneous object environment in which they will want both C++ and Smalltalk components to be Corba-compliant, and for those components to interoperate with their OLE-based components on the desktop."
Analysts say that demand will force tight interoperability among Corba, DCE, and Microsoft's DCOM. And that's good news for users.
GRAPH: Corba Dollars: Worldwide user spending on software supporting the standard
PHOTO (COLOR): Ron Trout, Boeing: "We decided to choose off- the-shelf applications and integrate them using Corba."
PHOTO (COLOR): Roger Gurnani, Bell Atlantic: "DCE is widely deployed and accepted across the telecom industry."
~~~~~~~~
By Herman Mehling
Title: | A sea of change for middleware. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Discusses market challenges facing data access middleware vendors. Competitors to business of connecting incompatible applications, servers and databases; Corba-compatible object request broker vendors. |
AN: | 9605215792 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
Section: Databases & Tools
Object Request Brokers
Data access middleware vendors are under attack on two fronts as competitors target their traditional business-connecting incompatible applications, servers, and databases. On one front is the growing number of Corba-compatible object request broker vendors that are trying to use the Internet to gain both market and mindshare. The second front is populated by database vendors interested in grabbing a piece of the exploding middleware market.
"The middleware market goes from $1 billion [in 1995] to $6 billion over the next five years," says Ed Ackley, director of middleware research for International Data Corp., a market research firm in Framingham, Mass. A market of that size draws attention, notes Ackley: "The guys who look for blips are going to notice this market is starting to scale up."
Showdown Coming The new generation of universal databases provides database management system (DBMS) vendors with an opportunity to challenge independent middleware companies. "We're going to see a showdown between the pure middleware vendors and the DBMS vendors as those market spaces merge," says Curt Monash, publisher of the Monash Software Letter in New York.
At the same time, ORB (object request broker) vendors argue that their products are the best way to link incompatible systems. "I don't think there's any question that ORBs will hurt [middleware vendors], ultimately," says Beach Clark, manager of network architecture for the Home Depot in Atlanta.
Still, data access vendors hold 47.5% of the middleware market, according to IDC, and seem prepared to battle to maintain their position.
For example, Visigenic Software Inc., an object database connectivity (ODBC) middleware vendor in San Mateo, Calif., acquired PostModern Computing, a high-profile ORB developer, earlier this month (IW, May 6, p. 32).
"ORB vendors are vulnerable because they're small," says IDC's Ackley. "In the case of Visigenic's acquisition [of PostModern], it was a matter of do-or-die. PostModern couldn't sustain themselves on their own."
Analysts say the acquisition may become a model for other data access vendors. Visigenic plans rapid delivery of a merged ORB/data access product that leverages the technology from both companies. "We're going to do it by having client-server [data access] be a special case of the more generalized object-messaging," says Roger Sippl, Visigenic's chairman and CEO.
Meanwhile, users will be able to consider technology developed by Intersolv Inc. in Rockville, Md., with the blessing of Sun Microsystems' JavaSoft operating unit. Last week, Intersolv announced the JDBC/ODBC Bridge, a system that links Java programs with any off-the-shelf ODBC driver.
Intersolv's product will be bundled for free in a forthcoming edition of JavaSoft's Java Development Kit. It will let Java developers connect their programs to almost any database without rearchitecting applications or network services. That could provide an advantage over the redevelopment that using an ORB requires.
Including ORBs, "there are five camps competing with one another," says Gerry Cohen, president and CEO of Information Builders Inc., a middleware vendor in New York. "Microsoft has OLE, IBM has OpenDoc, OMG has Corba, Digital has another layer. They're different architectures and they may never go anywhere."
Getting Along The leading ORB vendor, Iona Technologies, is addressing compatibility problems head-on through strategic partnerships and alliances. On May 8, Iona announced a collaboration with IBM that will strengthen interoperability between Orbix and key IBM products and technologies such as the System Object Model and OpenDoc components.
On May 13, Iona is expected to raise the curtain on a joint development agreement with France's O2 Technologies, which markets object database development tools. The companies will announce the immediate availability of an integrated C++ development environment for crafting distributed object database applications that comply with Corba and the Object Data Management Group specifications.
These moves, plus support for 20 major enterprise platforms, could give Iona's Orbix a big boost.
Data access tools 47.5% Messaging and transaction tools 46.5% Object request brokers 6.0% Total 1995 revenue:$1 billion
~~~~~~~~
By Rich Levin
Title: | Object standard. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports on Object Management Group's settling on a standard that will unite the world of Object Linking and Embedding (OLE)-driven desktop applications with object-oriented Unix and mainframe applications. Allowing of an enterprise application to make CORBA-compliant object available to OLE-based desktop applications and vice-versa. |
AN: | 9605082114 |
ISSN: | 0746-8121 |
Database: | Academic Search Elite |
Section: NETWORK APPLICATIONS
The Object Management Group last week settled on a standard interface that promises to unite the world of Object Linking and Embedding-driven desktop applications with object-oriented Unix and mainframe applications.
The Component Object Model-Common Object Request Broker Architecture (COM-CORBA) interworking standard is the client- side interface that would allow an enterprise application to make CORBA-compliant objects available to OLE-based desktop applications, and vice versa.
To the desktop application the interface appears to be just another OLE automation server making calls on the local machine, according to David Curtis, chief technical officer at Expersoft Corp., San Diego.
In fact, the interface is translating and redirecting those calls to a piece of software that appears to be a CORBA client stub. The calls are then passed along the network to a server-based CORBA-compliant object request broker using the Internet Inter-ORB Protocol (IIOP), Curtis said.
Pre-standard implementations of this interface appear in Expersoft's PowerBroker, Iona Technologies Inc.'s Orbix and PostModern Computing Technologies Inc.'s Orbeline object request brokers, and all three say they will change their software to conform to the new standard.
The first implementation of the new standard will be in Expersoft's CORBAPlus, which will be announced soon and delivered by early June.
"This standard has been a long time coming and it's later than we would have liked to have seen it," said John Rymer, vice president of the Giga Information Group, a Cambridge, Mass., consulting company.
Last week's standard will be followed in late 1996 by another that will define an interface at the server level between Microsoft Corp.'s Distributed COM (DCOM) and a CORBA ORB.
It will allow both IIOP and DCOM to be transmitted across enterprise networks, more tightly linking Microsoft's enterprise scheme with Unix, AS/400 and mainframe object models.
COMMWEEK interactive
* For more COBRA and COM-COBRA
VIEW: techweb.cmp.com/cw.current
click net news
~~~~~~~~
By MARTIN MARSHALL
Title: | Boeing's object push. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Focuses on Boeing's push for four software suppliers to integrate their packages by using the Common Object Request Broker Architecture (Corba) from the Object Management Group. Boeing's reengineering effort called Project Define and Control Airplane Configuration/Manufacturing Resource Management; Baan International; Trilogy Development Group; Structural Dynamics Research Co. (SDRC); Cimlinc. |
AN: | 9605090478 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
BOEING'S OBJECT PUSH
At Boeing, Corba objects are becoming the glue that binds commercial software packages. At the prodding of Boeing's Commercial Airplane Group, four software suppliers are enhancing their packages to work together by using the Common Object Request Broker Architecture (Corba) from the Object Management Group.
The effort comes at the insistence of Boeing, which has begun deploying products from those companies as part of a major reengineering effort. "Our [planes] are around for 30 to 40 years," says Doug Frederick, director of IS with Boeing's Commercial Airplane Group in Seattle. "Having one integrated system became important."
Baan International, Cimlinc, Structural Dynamics Research Co. (SDRC), and Trilogy met last week in an effort to integrate their applications using Corba interfaces. "Boeing is doing pioneering work in pushing suppliers like ourselves to become compliant," says Dave Auer, VP of strategic accounts at Cimlinc in Itasca, Ill.
Others On Board
Chris Stone, president of the Object Management Group in Framingham, Mass., says Boeing is not the only company pushing independent software vendors to add Corba to their applications. "Banks and telecommunications vendors are requiring it, too," says Stone. "You'll be seeing more of this."
The four software packages are being used in a reengineering project at Boeing that will extend to 70 engineering and manufacturing locations during the next two years. Boeing launched the project, called Define and Control Airplane Configuration/Manufacturing Resource Management, in late 1993 as a way to improve its parts-handling, inventory, and manufacturing processes. "It takes us from the beginning of a project, through design and production of parts, to the assembly of the fly-away product," says Frederick. Boeing installed the software in two plants south of Seattle in February; a full-scale rollout begins in July.
Besides the process planning product from Cimlinc, Boeing is using software for manufacturing resource management from Baan International in Grand Rapids, Mich.; product data management software from Metaphase Technology in Arden Hills, Minn. (supplied by SDRC); and software for airplane configuration from Trilogy Development Group in Austin, Texas. The packages run on Hewlett-Packard HP 9000 and Sequent servers and are tied into Oracle database management systems.
Boeing is using Orbix, a Corba-compliant object request broker from Iona Technologies Inc. in Cambridge, Mass., to tie it all together. Boeing wants to reduce the in-house effort required to integrate the applications and has mandated that the software suppliers build Corba interfaces into their packages. "As we started to nail all this together," says Frederick, "it became clear we didn't want point-to-point interfaces between them."
PHOTO (COLOR): Four in one: Boeing wants an integrated software system for building its planes
~~~~~~~~
By John Foley
Title: | The promise of distributed business components. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Discusses the advantages of replacing hand-crafted software with reusable components as a solution to the software crisis. Elements of object-oriented programming; Description of the Microsoft Component Object Model (COM) and the Object Management Group (OMG) Common Object Request Broker Architecture (CORBA) models; Middleware in transaction processing; Methods for designing components. |
AN: | 9605080986 |
ISSN: | 8756-2324 |
Database: | Academic Search Elite |
THE PROMISE OF DISTRIBUTED BUSINESS COMPONENTS
Introduction
The problem with current software is that it is extremely labor intensive. It takes too long to build and costs too much; it is almost always late and over budget; it is inflexible and difficult to repair; and the final results do not deliver what the customer really needs. This paper describes a possible solution to the software crisis by replacing hand-crafted software with reusable components. Two of the major architectures for component development (the Microsoft Component Object Model [COM] and the Object Management Group [OMGI Common Object Request Broker Architecture [CORBA]) are discussed. A methodology for building components via object-oriented frameworks is also presented.
Component-Based Software Development
The following subsections discuss four key aspects of component-based software development: key principles, new industries, new tools, and object-oriented technology and components.
Key Principles. The term "component" has different meanings in different situations. Thus, for purposes of this discussion, the following definition is provided:
The component-based software development process is composed of components, methodologies, and tools for building software. For companies that can take advantage of this process, component-based software development is expected to cut development time in half. Customer needs, represented as business models, can be fed through tools to develop a design and generate code for the application. The application can be built by assembling components using high-level logic both to use component functionality and to manage the relationships between components.
Components allow the design of large systems by providing the following two important benefits[1]:
The fundamental assumption about components is that purchasing them off the shelf makes more economic sense than building them from scratch.[2] Libraries of standard, reusable information systems components including architectures, designs, frameworks, code, test suites, and user interfaces will be available from a variety of the following sources:
New Industries. The systematic reuse of components will create a new industry of software component developers producing reusable components for the market. Developers in the software industry will also separate into the following three segments:
New Tools. A new generation of computer-aided software engineering (CASE) tools is needed to define the application logic that governs the interaction of components. The strength of CASE tools is that visual programming techniques are used to assemble applications by manipulating graphical icons and not code. Currently, few CASE tools can manipulate components. This situation will change, however, as new tools for application developers are introduced.
Object-oriented CASE tools either translate object diagrams produced by object-oriented methodologies into code or reengineer existing code into object diagrams. Some CASE tools include a repository for storing and retrieving components. The development methodology or process for building components and applications is critical, especially object-oriented development methodologies[1,3]
Object-Oriented Technology and Components. Components need not be object oriented. Object-oriented technology, however, has great advantages for building reusable components. It promotes component-based software development because it allows reusable designs in the form of classes and frameworks to be used instead of functions. Existing code that is made into a component for reuse need not be object oriented, but new components will most likely be developed using object-oriented methods.
The remainder of the paper describes how object-oriented technology and methodologies, along with distributed object standards and middleware, can be used to develop reusable components.
An Architecture for Building Components
This section describes the advantages of using object-oriented programming to build components. Distributed computing standards allow objects in different address spaces and on different computers to communicate with one another. Middleware, such as transaction processing monitors, are described as being the foundation for developing business components.
Object-Oriented Programming. An excellent tool for building reusable components is object-oriented programming, which is described as follows:
Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships.[4]
A class is a template for an object and defines the object's methods (functions) and internal variables. An object encapsulates state and behavior. Encapsulation provides modularity and information hiding. Development methods other than object-oriented programming provide solely for encapsulation but only if very carefully structured programming techniques are used.
Polymorphism is the ability of objects of different classes that are related by a common super class to respond differently to the same message, reducing the number of interfaces for a class. Thus, any object of different classes that provides the same set of operations can be used in place of a specific class.
Inheritance is the ability to create new subclasses that are enhancements of existing classes. The subclass inherits all methods and internal variables of its parent class. Inheritance allows a class to be reused in a modified form by subclassing.
Although the three aforementioned properties of object-oriented programming can simplify the construction of reusable and easily maintained classes, the major reason that object-oriented systems have been successful at software reuse is the change in the way systems are designed. Design and not just code is reused. A mature design is one that can be reused and customized.[5]
Standards for Distributed Computing. The following four critical needs of businesses affect the architecture for components:
The last need is perhaps the most important because it states that a component is more than just a reusable piece of code. A component is functionality that is available somewhere in the enterprise, and this functionality is available from remote locations exactly as if it existed locally. Two distributed computing models, the Microsoft COM and the OMG CORBA models, provide distributed object functionality. Both these architectural models can provide a basis for building components.
COM. A component software architecture, COM allows applications and systems to be built from components supplied by different software vendors. A COM component object or component (see Figure 1) is different from the traditional concept of objects in object-oriented programming in that a COM component object is a piece of compiled code providing some service. COM is the underlying architecture for higher-level software services, such as Microsoft's Object Linking and Embedding (OLE). OLE is both a compound document framework and a visual component architecture at a higher level than COM. All OLE services use COM to allow binary software components to connect to and communicate with each other across processes and computers.[6] (Note that COM, the Component Object Model, is different from the Common Object Model architecture for enabling interoperation between Microsoft's OLE and Digital's Object Broker[a] technology.)
The COM defines a binary standard for invoking methods on an object. Any language that can call functions through double-pointer indirection (in C, C++, Smalltalk, for example) can be used to write COM-based component objects that can interoperate. Well-defined collections of functions (or methods) that a component provides are called interfaces. Component objects always access other component objects through interface pointers. A component object can never access another component object's data. Only interfaces are exposed to other component objects. This encapsulation of data and processing is a fundamental requirement of component software.
A component object can have one or more interfaces. An interface carries no implementation and cannot be instantiated by itself. A component object must implement the interface and be instantiated for the interface to be accessible. The interface is simply a related group of functions providing functionality for the component. A developer uses.the object description language (ODL) to create a description of the interface's methods. The ODL compiler generates program header files and code for proxy and stub objects to use the interface. Other components only interact with pointers to interfaces, not with pointers to component objects. A component object can implement multiple interfaces representing different services provided. Every interface has a unique identifier (called a globally unique identifier or GUID) to eliminate naming conflicts. Interfaces never change. A new version of an interface is an entirely new one and is assigned a new identifier.
Component objects are programming-language independent because COM represents a binary-object standard. Each component object must implement a special interface called Unknown that allows clients to discover at run time whether an interface is supported by the component object. If the component object is not in process (as a dynamic linked library [DLL]) and exists as a separate process executing either on the same machine or another one, a remote procedure call (RPC) is made to enable local/remote transparency (cross-machine RPC has not yet been released by Microsoft).[6]
OLE is a set of system services built on COM for constructing compound documents and reusable components. OLE structured storage, drag and drop, embedding and linking, and in-place activation of objects are services to support compound documents composed of objects from different applications, available in a document-centric (as opposed to an application-centric) model. OLE automation and OLE controls, however, provide for component-based software. OLE automation allows a component object to expose all its methods and properties through the IDispatch interface, allowing late binding of method calls. OLE controls use most other OLE and COM technologies, including OLE automation and dispatch interfaces in addition to providing a user interface to receive input. OLE controls are Microsoft's definition of reusable components at the highest level.
CORBA. The OMG is a consortium of more than 500 hardware, software, and end-user companies founded in 1989 by a group of 11 firms including NCR Corp., Digital Equipment Corp., Hewlett-Packard Inc., Hyperdesk Inc., and SunSoft Corp. These companies, along with Object Design, authored the 1991 CORBA 1.0 specification. The goal of OMG is twofold: to establish agreement among system and application software vendors on a universal object-oriented set of standards for describing interfaces to distributed services and to use such interfaces for distributed services.
An object request broker (ORB) manages the interaction between client and server objects, including locating objects and marshaling (translating and transferring) object parameters and results between computers. OMG defines CORBA (see Figure 2) as describing interfaces for distributed services and how ORBs of different vendors would interoperate. The CORBA specification defines the architecture of an ORB, which enables and regulates interoperability between objects and applications. The recently approved CORBA 2.0 specification describes an interoperability protocol for accessing objects in ORBs provided by different vendors. In addition, the well-defined CORBAservices* are common object services that include life cycle, naming, events, persistence, and transactions, all built atop a CORBA-compliant ORB. CORBAfacilities* are built over the ORB and CORBAservices* and provide application-level functionality, such as mail, database queries, and compound documents.[7]
The CORBA object model is a client/server model in which clients send messages to servers having zero or more parameters and receive back a return value or an exception if a failure occurs. The interface is strictly separated from the implementation. In the OMG model, objects are identified not by memory addresses as in C++ but rather by object references. Object references identify a specific instance of an object at a specific location. An instance is the state of the object married to its functionality (much like a process is the instance of a running program, differing from other running copies of the program by its state).
CORBA objects are defined in interfaces expressed in the interface definition language (IDL). The term interface describes the methods that can be called on an object and the object's accessible attributes (public state variables), which describe how the object appears to the ORB and to clients. Interfaces do not address any implementation details. Clients use CORBA object services by either the IDL stub interface or the dynamic invocation interface, a mechanism for specifying requests at run time. IDL is strongly typed. Basic types are fundamental data types: integers, floating-point numbers, chars, Booleans, enums, strings; octets (8-bit data types), and a nonspecific type called any. Constructed types are more complex types, such as structs, unions, sequences, arrays, and the interface type that specifies which sets of operations an instance of that type must support.[8]
The IDL describing an interface is mapped into different programming languages, such as C or C++. A CORBA IDL compiler takes IDL as input and outputs the code for the server and/or client parts of a distributed object. These are stubs for the methods on the client side and skeletons for the method implementations on the server side. The code for marshaling parameters and results, for invoking objects, and for making the actual network calls are typically generated by the IDL compiler. The only thing that is not output is the actual implementation of the methods of the distributed class. These methods must be implemented by a developer.
Components In COM and CORBA. Both COM and CORBA interfaces can be used to define high-level functionality of components. These interfaces describe object services that can call other services as needed to implement the functionality. By wrapping business functionality with COM or CORBA to build reusable components, high-level components can provide functionality at a level that makes sense to the application developer. Components implemented as COM or CORBA objects can be used by other components and applications, and they can be accessible from ORBs of different vendors. The OMG is currently evaluating proposals for the COM and CORBA models to interoperate with each another. In the future; an enterprise will have both COM and CORBA environments, and resources in one environment must be accessible by the other.
One major difference between COM and CORBA is in the process by which both these architectures have been created. OMG has used an open process with respect to CORBA in which different vendors submit proposals in response to a request for proposals. Microsoft has taken a closed, proprietary approach in developing COM. It is anticipated that Microsoft's COM will dominate the PC and workgroup environments, and the OMG's CORBA will dominate midrange and enterprise server environments.
Middleware for Transaction Processing. Why examine transaction processing systems? Today, most business logic resides in applications that run on database systems. This business logic is an excellent candidate for being wrapped in components and made reusable.
TP monitors. The majority of database applications on which businesses run have the following three major components:
In non-distributed systems, all three of these components reside in one computer. A typical distributed data architecture has the data residing on a server, as well as multiple clients containing the presentation and business logic accessing it. These types of architectures frequently use Microsoft's LAN Manager[a] or Novell's NetWare[a] for remote file access, or Gupta, ORACLE, or Sybase products for remote database access. The business logic, however, resides on the client and the data resides on the server. To move more business logic to the server, stored procedures and applications offload more processing to the server on which the database is located[.9]
Both distributed data and distributed functionality require a transaction processing (TP) monitor (see Figure 3). Business logic can be executed on multiple server computers and the data may also reside on multiple servers. The inexpensive processing power of PCs has forced the presentation layer to the workstation. The business logic, however, must be maintained across some number of servers for centralized control and administration. A TP monitor manages the business logic on the servers by providing concurrency, transactions, and security--each a feature of the business-critical mainframe environment that no longer exists in the distributed client/server model.
A TP monitor is essentially a scheduler optimized for short-running applications. TP monitors allow many clients to access efficiently a much smaller number of application servers and yet still allow the configuration to grow by adding extra servers to handle increasing load. The TP monitor often supports multiple users by scheduling multiple instances of an application. This situation is ideal for languages like COBOL that do not support multi-threading. Examples of leading TP monitors are the NCR TOP END(TM) product, the Novell Tuxedo[a] monitor, and the IBM CICS[a] and Encina[a] products.
TP monitors allow global transactions over databases from different vendors. The X/OPEN[a] XA standard guarantees two-phase "commits" of transactions across multiple databases. Along with a transaction manager and systems management facility, a TP monitor also includes an application programming interface (API) to allow applications to use the asynchronous messaging and remote data update facilities. The NCR TOP END TP monitor, for example, includes location independence, load balancing, and automatic application-restart facilities, along with configuration and security management.
Integrating TP monitors and ORBs. Many advantages are realized by integrating a TP monitor and an ORB. TP monitors manage the data and the business logic of today's businesses. ORBs offer architectures for building the next generation of reusable distributed components. By combining the two, components can access existing business logic (in the form of database applications managed by the TP monitor) and the existing data in relational databases.
Object invocation is very similar to the message passing architecture of some TP monitors. Operations are the only way to access data. However, object activation (starting object instances not currently running) is a feature of ORBs while process scheduling across computers is not.[9] There is value in making the scheduling function of TP monitors available to ORB environments as well. Integrating a TP monitor with an ORB allows COM or CORBA components to be wrappers of existing business functionality stored as, for example, NCR TOP END applications. In the case of CORBA, IDL interfaces can be used to access TP monitor applications. In the case of OLE/COM, OLE controls provide a way to access the interface of a TP monitor application remotely. integrating a TP monitor with an ORB also provides X/OPEN XA-compliant standards as a way to implement object-oriented transactions. A TP monitor can be used as the middleware supporting reusable business components.
Methods for Designing Components
After covering the architecture for components and the required technology, the discussion now shifts to the techniques by which components are actually developed. Objects help in developing components in that a component can be considered a high-level object, but objects are not enough. Frameworks are needed to manage complexity.
Frameworks. Design reuse is facilitated by the use of object-oriented frameworks. In a 1991 paper, frameworks are described as follows:
A class describes the behavior of a single object. A framework describes the behavior of a set of classes that work together. Frameworks are abstractions of a set of interrelated classes. Individual classes may certainly be reusable, but the most value is achieved by using frameworks because the design is then reused, not just the code. A major difference between a framework and an arbitrary collection of classes, however closely related those classes might be functionally, is that a framework describes not only the objects but also their interactions with one another. Creating frameworks is a technique for organizing classes for reuse by maintaining their relationships.[10]
A framework is an example of a white-box component that must be modified to be used in different applications. Furthermore, you can "look inside" the component to reuse it. A black-box component, on the other hand, never changes and is used as is. With inheritance, the internals of parent classes are often visible to subclasses in a framework. Frameworks are one of the most useful forms of components. Frameworks, as white-box components, often include reuse of much larger parts, and they increase productivity significantly more than reuse of black-box components.[1]
Two types of frameworks currently exist: base and business frameworks. Base frameworks are the enabling technology that encapsulates the software infrastructure or platform, which can include the operating system, graphical user interface, distributed object request broker, TP monitor, and other middleware. Examples of base frameworks include the Microsoft Foundation Classes[a] (MFC[a]), the Borland Object Windows Library[a] (OWL[a]), and the Taligent CommonPoint[a] frameworks.
Business frameworks contain the knowledge of the objects in a business model and the relationships between the objects. Business frameworks can be used to build many different components for a single industry. Economically, it makes more sense to have a set of frameworks specializing in certain targeted industries while having a set of base frameworks that are used by all industries. These industry-specific frameworks would be built atop base frameworks that encapsulate the underlying technology. OMG is now developing standardized architectures for the business frameworks of various industries.
From Models to Components. As components grow to encompass greater functionality, the complexity of the component will increase significantly. Object technology uses abstractions in an attempt to solve the problem of how to build complex systems. Frameworks deliver functionality that resides at a higher level than classes. Components and frameworks become more complex as the application domain increases. But how does one decide what makes up a framework?
Good knowledge of the application domain is critical to building white-box components, such as frameworks. A domain expert must work with a component designer to use a modeling methodology and extract the valuable design patterns that occur in that domain. A design pattern is the core of a solution to a problem that occurs over and over.[11] Various methodologies, such as OMT[3] or Objectory[1], allow an expert to capture all the functional requirements of a system.
Inheritance frameworks may not always be acceptable. For example, unlike CORBA, COM does not allow implementation inheritance. In this case, COM containment and aggregation techniques (instead of inheritance) must be used to build new components composed of other components. Nevertheless, a framework provides for successive refinement and composition of simpler components (see Figure 4). The highest-level component is usually composed of many other components, either as a framework or via aggregation of other components. This is how complexity of components is managed. Thus, frameworks are not only examples of white-box components, but they also provide a means by which simple components can be used to develop more complex components.
Once the problem domain has been modeled, the model can be specified in CORBA IDL or Microsoft ODL. Various products available today will convert different object methodologies into IDL, allowing an expert to define the model entirely using a preferred methodology. Once the interfaces of the components have been designed, a developer would only have to code the actual implementation of the methods. This has the advantage of separating the coding from the design.
Component development is divided into two groups of experts: component designers and implementors. Similarly, application development is also divided into two groups of experts: component and application developers. The application itself is built by "knitting" components together using a development tool, such as Cadre Technology's Object Team Application Factory[a]. The application includes both business strategy and processes (work flows) for implementing components into useful applications.
The component has a high-level interface, and the implementation of its interface methods may call other components or interact with other frameworks. The component's interface is very similar to that of a COM or CORBA object except that a component provides functionality at a much larger granularity. For example, a customer account component may be built using an accounting framework atop other base frameworks. The component's client-based graphical front end may be running on Windows[a] workstations as an OLE control and require MFC as a base framework. The component's server-based part, however, may be running on a UNIX[a] workstation with an ORB to manage object activation and access. The ORB itself may be working in conjunction with a TP monitor to schedule processing and to provide transaction support to access the customer data in a relational data-base. Other components and frameworks may provide support to the server part of the distributed component.
Conclusion
The central problem that components address is complexity. To reduce it, efficient mechanisms for constructing components are implemented, and hand-crafted software is replaced with reusable components. Both the COM and CORBA architectures support reusable components. For accessing existing business logic, which frequently depends on the concept of transactions and access data residing in relational databases, a TP monitor must also be included in the architecture. Object-oriented technology and methodologies, along with distributed object standards and technology, provide techniques for building components as object-oriented frameworks.
[a]Trademarks
CICS and Encina are trademarks of International Business Machines Corp.
CommonPoint is a trademark of Taligent Corp.
CORBAfacilities and CORBAservices are trademarks of Object Management Group.
LAN Manager, MFC, Microsoft Foundation Classes, and Windows are trademarks of Microsoft Corp.
NetWare is a registered trademark and Tuxedo is a trademark of Novell, Inc.
ObjectBroker is a trademark of Digital Equipment Corp.
ObjectTeam Application Factory is a trademark of Cadre Technology.
Object Windows Library and OWL are trademarks of Borland Corp.
UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/OPEN Company Ltd.
X/OPEN is a trademark of X/OPEN Company Ltd.
DIAGRAM: Figure 1. The Microsoft Component Object Model (COM) allows applications and systems to be built from components supplied by different software vendors. A COM component object or component Is different from the traditional concept of objects in object-oriented programming In that a COM component object is a piece of compiled code providing some service. COM Is the underlying architecture for higher-level software services, such as object linking and embedding (OLE). This illustration shows a COM component object having three interfaces, one of which is being used by a client.
DIAGRAM: Figure 2. An object request broker (ORB) manages the Interaction between client and server objects, Including locating objects and marshaling object parameters and results between computers. OMG defines CORBA as describing Interfaces for distributed services and how ORBs of different vendors would Intemperate. The CORBA specification defines the architecture of an ORB, which enables and regulates interoperability between objects and applications. The Illustration shows u simplified architecture of a CORBA ORB.
DIAGRAM: Figure 3. Both distributed data and distributed functionality require a transaction processing (TP) monitor. Business logic can be executed on multiple server computers and the data may also reside on multiple servers. The Inexpensive processing power of PCs has forced the presentation layer to the workstation. The business logic, however, must be maintained across some number of servers for centralized administration. A TP monitor, shown linking clients with applications and data, manages the business logic on the servers.
DIAGRAM: Figure 4. In progressing from models to components, a framework provides for successive refinement and composition of simpler components. The highest-level component is usually composed of many other components, either as a framework or via aggregation of other components. This is how complexity of components is managed. The Illustration shows how applications are developed using components composed of business frameworks and other existing components atop base frameworks.
References
1. I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard, Object-Oriented Software Engineering: A Use-Case Driven Approach, ACM Press, Wokingham, UK, 1992.
2. Streamlining Software Development, SRI International, Business Intelligence Program, Report No. 833.
3. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-Oriented Modeling and Design, Prentice-Hall, Englewood Cliffs, New Jersey, 1991.
4. G. Booch, Object-Oriented Design with Applications, The Benjamin/Cummings Publishing Company, Inc., Redwood City, California, 1991.
5. R. E. Johnson and V. F. Russo, "Reusing Object-Oriented Designs," University of Illinois Technical Report UIUCDCS 91-1696, May 13, 1991.
6. K. Brockschmidt, Inside OLE, Second Edition, Microsoft Press, Redmond, Washington, 1995.
7. M. Betz, OMG's CORBA, Dr. Dobb's Special Report, Winter, 1994/95.
8. The Common Object Request Broker: Architecture and Specification, The Object Management Group, Revision 1.2, December 29, 1993.
9. E.E. Cobb, "TP Monitors and ORBs: A Superior Client/Server Alternative," Object Magazine, February 1995, pp. 57-61.
10. D. K. Kythe, "Strategies and Tools for Building Frameworks of Reusable Objects," Proceedings of the AT&T Symposium on Software Reuse, Holmdel, New Jersey, May 17, 1995.
11. E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Publishing Company, Inc., Reading, Massachusetts, 1995.
(Manuscript approved March 1996)
Panel 1. Abbreviations, Acronyms, and Terms
CASE--computer-aided software engineering COM--Component Object Model CORBA--Common Object Request Broker DLL--dynamic linked library GUID--globally unique identifier IDL--interface definition language MFC--Microsoft's Foundation Classes ODL--object description language OLE--Microsoft's Object Linking and Embedding OMG--Object Management Group ORB--object request broker OWL--the Borland Object Windows Library RPC--remote procedure call TP--transaction processing
~~~~~~~~
By Dave K. Kythe
Dave K. Kythe was a senior principal software engineer at AT&T Global
Information Solutions (now NCR) in West Columbia, South Carolina. He was
responsible for the AT&T COOPERATIVE FRAMEWORKS, a set of C++ class
libraries for CORBA[a]based distributed object computing. He has a
B.S. degree in computer science and mathematics from Tulane University in New
Orleans, Louisiana, and an M.S. in computer science from Indiana University in
Bloomington. Mr. Kythe, who joined AT&T in 1989, recently left the company
to accept another position.
Title: | Distributed objects, few standards. (cover story) |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Asserts that the computer networking industry expects to use object technology in the future of middleware. Prospects for the year 2000; The expected outcome of the battle between Microsoft's OLE and the anti-Microsoft alliance of OpenDoc and CORBA over the future of application-programmer-interface (API) technology; The future of keeping track of networked objects; Predictions from industry representatives. INSETS: Millennium prophesies (Forecasts for the year 2000). |
AN: | 9509267639 |
ISSN: | 1046-4468 |
Database: | Academic Search Elite |
Section: Features
Middleware:
Yes, we expect to object in the future. A few objects, hurdles even, are in the path toward enterprise objects across the network. From the current efforts to even get any object technology rolling, the future will bring increased use of object-oriented tools creating object-oriented applications. For this vision to work in the real world, the network must object, too. And it will, both by allowing object applications to work over the network, and, more important, by becoming more object-oriented itself.
Object APIs Solidify We'll see the results of the object API futures battle between Microsoft's OLE, the assembled anti-Microsoft crew's OpenDoc and the CORBA world put forth by the enterprise and open systems vendors. The winner? All of them, and we don't care which. The very fact that there are only two or three should be enabling enough. After all, we've lived with too many choices for so long that looking at only two or three will seem simple. Most importantly, we'll finally have products instead of presentations and unimplemented APIs.
In the end, any Object Request Broker (ORB) servicing these object-oriented applications will have to support all the APIs that generate significant market share. No single ORB will become the standard. Just as we have multiple data access vendors, RPC and messaging middleware products today, we will have many competing ORBs in five years.
It will be different in five years-different development tools and paradigms, different APIs, different middleware products and even new functionality-but in many respects the problems will remain the same. Creating good applications will never be simple or easy.
Deploying them, however, should indeed be easier with better desktop operating systems (imagine the 32-bit Windows OS after Cairo: fully protected and multitasking with even better usability than Windows95), five more years work on enterprise software distribution products (and even development tools themselves), and the move away from the fat client approach as three-tier implementations become well understood. Many application functionality changes won't affect the desktop at all.
Keeping Track of Networked Objects The next five years will see the ascendance of the directory service (along with security and time services) as the key service provided by middleware beyond today's simple connectivity and interprocess communication paradigm. This will enable single system login, the bane of most current multivendor, multisolution, multi-RDBMS, multiplatform shops.
Directory systems must be scaled up and scaled out to handle ever larger quantities of names. Moreover, Microsoft's vision of Cairo, NetWare's NDS, the DCE cell and the object stores of the future will have to keep track of much more than user and machine names. As applications become more and more distributed, expanding on the current enthusiasm for three-tier architectures, the directory system must keep track of all the computing parts of the applications, not only the data parts.
If objects really gain a foothold on the network, and we believe they will, then they will become more numerous and fine grained. Application components (software agents, stored procedures, remote procedures, objects) will be scattered across the netscape waiting to be accessed by other components running on clients and/or servers. Indeed, that very client/server terminology will fade into last year's buzz once this wider and more minute distribution of function and data takes place.
Key vendors (the DCE crew, the NOS players like Novell with NDS and Microsoft with Cairo, Banyan with StreetTalk and so on) will fight over the next five years to determine the leadership position in providing directory middleware. Currently, middleware vendors either provide varying degrees of directory support, or just act stupid and let the applications handle that internally. This has to stop. There must be one directory and it must be dynamic enough to keep track of objects that move around the network and duplicate themselves automatically to respond to load conditions. We only wish we believed this could happen by 2000.
Tying Networked Objects Together You won't be using data access middleware, like Oracle SQL&AST;Net and Sybase CT-Lib anymore, particularly at the desktop. Three-tier is in, and getting from the desktop to the middle will be the job of more generic and flexible middleware. Three-tier tool vendors like Fort , Dynasty and Seer have realized this and have long supported their own middleware for program-to-program communication. These vendors will soon give up making their own middleware and start supporting the stronger third-party products in order to concentrate on application development tools.
Data access middleware is just too tied to a two-tier logic distribution, to SQL as the only supported language, and to RDBMSes as the only application server (stored procedures) and data store. Moreover, the typical RPC-like synchronous blocking mechanism supported in data access middleware suffers on slower networks. Data access was enabling in the '90s, but in the next century we'll want more than just raw data over the network. Data manipulation must be spread across a distributed processing environment.
Data access won't disappear completely, but it will be localized in its use-particularly from the application server to data sources like RDBMSes, and only over centralized high-speed LANs. SAP's client/server R3 already looks this way.
Applications will be deployed across multiple middleware mechanisms. A client will use a messaging mechanism over a slow link to start an intermediate object, which in turn will use an RPC mechanism or a distributed transaction monitor (itself built on RPCs or messaging) or even traditional data access middleware to interact over the fast ATM backbone with other systems to get the answer. Mixed middleware solutions will be much easier with multitier distributed systems, and more effective.
The Network Underneath the Middleware What will middleware be looking down at on the network itself? Underneath middleware's session, presentation and even application service layers will be TCP/IP. In five years, the other's network protocols or transports are literally history. TCP/IP wins.
Middleware's networking job will (still) be to offer mechanisms that exploit the speed of ATM networks (RPCs' strength) while at the same time enabling applications over slow and intermittent links (the strength of message queuing).
RDBMS vendors are losing out to the tool vendors in the war for strategic product solution provider. The applications matter, and they'll use an RDBMS only if necessary. The applications will have to have middleware, though certainly not to connect to databases alone. Oracle and Sybase are right to avoid being smug about their RDBMS successes. In five years, RDBMSes will be a commodity for all but the most demanding applications. Picking an RDBMS won't even affect the desktop applications, since they will not directly connect to an RDBMS.
Yes, we do see the future in objects, despite the lack of standards owning the objectscape. Hope you object too.
ILLUSTRATION
~~~~~~~~
By Bruce Robertson
Bruce Robertson can be reached at brobertson@nwc.com.
Title: | Middleware aids inter-computer communication. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Focuses on the role of middleware in inter-computer communication. Definition of middleware; Importance of middleware; Issues involved with interoperating computer applications; Development of the Common Object Request Broker Architecture (CORBA) standard. |
AN: | 9509265355 |
ISSN: | 0747-3699 |
Database: | MasterFILE Premier |
Section: Special Report: Computers
With an absence of dramatic flair and imagination guaranteed to further their own negative stereotypes, technical computer professionals have adopted the term "middleware" to denote the layer of software connecting the bottom and top layers of software.
Applications like word processors, spreadsheets and data bases are regarded as top-layer software and are said to run "on top of' the operating systems. The operating system, in turn, is referred to as the bottom layer of software, because of its role as a foundation upon which other software is built.
The importance of middleware stems from the rising demand for applications running on multiple computers to exchange information, coupled with the increasing variety of operating systems and applications. When developing such applications, businesses should look to open industry standards with broad multi-vendor support, rather than lock themselves into any single vendor's proprietary solution.
Applications that can exchange information sometimes are said to "interoperate." Cutting a graph from a spreadsheet and pasting it into a report in a word processor is one example of applications exchanging data. In this case, the applications are running on a single computer and hence on top of a single operating system. The issues involved in making this kind of exchange work are well understood, and their complexity is comparatively minimal.
As a more complex example, consider how a large international shipping company might take advantage of computer technology. Every package the company received could be marked with a unique bar code. This bar code then could be entered into a data base describing the package, sender and destination.
As the package moved through the company, the bar code could be scanned so the package location would be known at all times. When the package was delivered, the recipient also would be entered into the data base.
Customers could access the data base to place requests for package pickup and then receive notification of the package's bar code when the package is picked up, Using knowledge of a package's bar code, the customer could query the data base to monitor the progress of the delivery. Furthermore, customers could receive bills for delivered packages and make completely electronic payments of those bills.
The computer systems underlying the preceding example have some important characteristics that need to be recognized in order to appreciate fully the vital role of middleware. First, it should be emphasized that this example explicitly described the use of multiple computer systems scattered throughout many locations: This is known as a "distributed system."
These computer systems would not be running identical application programs on top of a single operating system all from a single vendor. This software heterogeneity implies that incompatibilities could plague the exchange of information among the computer systems, thereby limiting the usefulness and effectiveness of the overall system. It is a major goal of middleware to eliminate such incompatibilities by providing a standard method for top-level applications to cooperate in a vendor-neutral fashion, independent of the supporting operating system.
Any application program that follows the standard will be able to communicate with any other application program following the same standard. in much the same way that facsimile machines made by different vendors and located in different countries still can exchange faxes.
Middleware also targets some of the more subtle issues involved with interoperating computer applications, such as performance, security and reliability.
Performance is a consideration in any computer system, particularly in one like the shipping company example that probably would have a large number of customers using it. If the customers perceived the system as too slow, it is likely they would switch to a competing shipping company.
Security, whether electronic or physical, must address the matter of authentication and authorization (given an authenticated person, does that person have permission to do what he or she is trying to do?). In the context of the above example, it is desirable for customers to be able to track only those packages that they themselves shipped or are expecting to receive. Furthermore, it is critical that the billing and payment be performed in such a way that both parties are assured that money is being exchanged in the correct amounts to and from the correct locations.
Reliability is very important in at least two distinct ways: First, the package tracking system should be available at all times. A customer should never be unable to request a package pickup or check the status of a package in transit because of computer malfunction, power failure or other calamity. This could result in a major loss of revenue.
What would happen if the customer's computer system, in the process of paying for a package delivery, verified the amount with the shipping company's computer system, updated its financial data base to reflect the reduction in funds and began transmitting the payment information but suddenly crashed before the information was received?
When the customer's computer rebooted, it might "think" that the bill was paid when it was not. Note that this or similar problems could occur even in completely secure systems if the transactions are not reliable.
Middleware can provide standardized methods for addressing performance, security and reliability. Performance and reliability can be handled with redundancy, and security can be handled with encryption.
In recognition of the importance of middle-ware, in 1989 a consortium called the Object Management Group was formed to create an opposed to proprietary--standard. Today, that standard, called the Common Object Request Broker Architecture (CORBA) is mature enough to be useful, and more than 500 companies boast of membership in the Object Management Group.
Several members of the group currently have shipping products, including, but certainly not limited to, SunSoft's DOE, Iona's Orbix, International Business Machine Corp.'s DSOM, and PostModern Computing's ORBeline. SunSoft and Iona even have demonstrated their middleware connecting applications running on top of SunSoft's Solaris UNIX operating systems and Microsoft's Windows, thereby proving that CORBA-compliant implementations from different vendors running on top of different operating systems indeed can intemperate to exchange data among computers.
While technically a member of the Object Management Group, Microsoft has announced no plans to develop a CORBA-compliant product. This is not surprising considering the company's traditional insistence on solutions based solely on its own proprietary products. OLE 2.0, a Microsoft product that has some characteristics of middleware, falls short of the mark due to its complete lack of support for inter-computer communication.
There is no mistaking the rising importance of networks of computers exchanging information. This trend brings with it the promise of greatly increased profitability for those companies willing to invest in harnessing the technology properly.
The price of this increased profitability is vastly more complex computer systems that now must deal. with heterogeneous operating systems, security and reliability, while maintaining sufficient performance to make the exchange of information among the applications still appealing.
Good middleware hides the incompatibilities among operating systems, and provides secure, reliable and fast communication, thereby enabling multiple applications running on a variety of computer systems to exchange data. This is done best within the context of an open industry standard with broad support from a variety of vendors.
PHOTO (BLACK & WHITE): J. Russell Noseworthy
~~~~~~~~
By J. RUSSELL NOSEWORTHY
Noseworthy is a doctoral candidate at the New York state Center for Advanced
Technology in Automation, Robotics and Manufacturing at Rensselaer Polytechnic
Institute in Troy.
Title: | Vendors unite for object standards. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Focuses on the Object Definition Alliance (ODA). Hopes to jump-start applications development for interactive services and electronic commerce through object specifications; Purpose of the vendor-driven coalition to go beyond the standards developed by the Object Management Group, which created CORBA, to designate standards for multimedia applications; Areas that ODA will target; Listing of members. |
AN: | 9508157646 |
ISSN: | 0746-8121 |
Database: | Academic Search Elite |
Section: Network Applications
The newly formed Object Definition Alliance, which has drawn the support of 16 Fortune 500 companies, hopes to jump-start applications development for interactive services and electronic commerce through object specifications.
ODA's specifications will include Common Object Request Broker Architecture/Interface Definition Language and textual descriptions of object operations, textual descriptions of object purposes and CORBA/IDL descriptions of object interfaces. The purpose of the vendor-driven coalition will be to go beyond the standards developed by the Object Management Group, which created CORBA, to designate standards for multimedia applications.
The ODA was initiated by Oracle Corp., Redwood Shores, Calif.ODA's standardization efforts are targeted at the interactive television, networked multimedia and electronic commerce industry areas, said Greg Newman, director of market development for Oracle New Media.
The ODA will target seven areas for standardization: financial services, for home banking and loans; electronic payment; corporate asset/content management (version control, document management); rights/royalties; retail, including on-line shopping, billing and inventory control; infrastructure, or system management, session creation and completion; and business objects, i.e., defining people, places and things.
After the drafts are posted, the ODA will attempt to push the specs through standards-making bodies.
VENDORS USERS Apple Computer Inc. Home Box Office Kaleida Labs Inc. MasterCard International Inc. MCI Communications Corpl PriceCostco Next Computer Inc. Visa Interactive Sun Microsystems Inc. Xerox Corp. Object Management Group Oracle Corp. Taligent Inc. VeriFone Inc. Wells Fargo Bank source: Object Definition Alliance
~~~~~~~~
By TALILA BARON
Title: | Bridging the object gap. |
Subject(s): | |
Source: | |
Author(s): | |
Abstract: | Reports that 13 companies are stating that they know the best way to use object-oriented communications to connect Microsoft Windows desktops to Unix and IBM OS/2 servers. Their disagreement on which is the best way; Their proposals submitted to the Object Management Group (OMG) for the forthcoming specification for linking Common Object Request Broker Architecture (Corba) with Microsoft's Object Linking and Embedding (OLE); Why some are not waiting for the specification. |
AN: | 9508167659 |
ISSN: | 8750-6874 |
Database: | Academic Search Elite |
Section: Databases & Tools
Standards
Thirteen computer companies say they know the best way to use object-oriented communications to connect Microsoft Windows desktops to Unix and IBM OS/2 servers. There's just one hitch: They don't all agree on how.
The 13 companies (see chart) will submit proposals by Aug. 22 for the Object Management Group's forthcoming specification for linking OMG's Corba (Common Object Request Broker Architecture) with Microsoft's OLE (Object Linking and Embedding).
Desktop applications typically use the Windows-based OLE object specification, while OS/2 or Unix servers tend to use Corba as their object model. Making sure there's a standard way to bridge the gap between the two object architectures is a high priority for many corporate users, so that desktop applications can access business objects residing on servers.
"We all know you can't control the Microsoft link to the desktop, and Corba is used for the higher-level services that Microsoft hasn't gotten involved in yet," says Tom Hein, manager of technology integration for heavy-equipment maker Deere & Co. in Moline, Ill.
Two or three years from now, "some larger organizations will be using DCE `the Open Software Foundation's Distributed Computing Environment', but a lot more `will still be' using Corba for integrating legacy systems that were never intended to work together," notes a consultant who requested anonymity.
But while corporate users are eager to nail down a level of compatibility between OLE and Corba object systems, Microsoft has been less enthusiastic. For years the Redmond, Wash., software giant pooh-poohed the need for any object system beyond the distributed version of OLE that will be part of its Cairo upgrade to Windows NT, slated to ship sometime late next year. That position has softened recently, however, and Microsoft will make its own OLE-to-Corba proposal in August. The company also plans to release some specifications for distributed OLE in October.
Proposals In The Works
Meanwhile, the 13 companies say they'll propose OLE-to-Corba solutions in August. OMG sources say there will be only about four separate proposals, because of partnering among the companies. The new round of OLE-to-Corba proposals coincides with announcements from many Corba vendors for products that can communicate directly with competing vendors' Corba versions.
With a final specification as much as a year away, independent vendors aren't waiting. Iona Technologies in Dublin, Ireland, and Visual Edge Software Ltd. in Montreal are already shipping OLE-to-Corba gateways. On Aug. 7, Expersoft Corp. in San Diego plans to announce a new version of its XShell Corba system, rechristened PowerBroker. The new release, slated to ship by year's end, will support both Corba and OLE and provide systems management capabilities, as well as communication between program objects.
Many corporate developers aren't waiting for a final specification, either. "Our customers don't want to care about the underlying object delivery system. They'd like the industry to provide that so they can get on with building business components, which is where the value is," says Michael Guttman, executive VP at object consulting group Genesis Development Corp. in West Chester, Pa., which has developed its own OLE-to-Corba technology.
Still, both vendors and corporate users say they'll support the Corba-to-OLE standard when it finally arrives. "Even a large company doesn't want to stand alone these days," says Deere's Tom Hein. "That used to be an advantage; now it's a liability."
Various Routes To Object Interoperability
Digital Equipment DCE and ObjectBroker Corba Object Request Broker (ORB) Expersoft PowerBroker (XShell) Corba ORB Fujitsu Corba ORB Genisis Development Enterprise-scale object development consulting Hewlett Packard Distributed smalltalk/ORB-Plus Corba ORB IBM System Object Model Corba ORB Iona Technologies Orbix Corba ORB Microsoft OLE/Windows common object model Siemens-Nixdorf Corba ORB Sun Microsystems Distributed object environment Corba ORB Sybase Open Client/Open Server object database extentions Taligent CommonPoint application development system Visual Edge Software Object Bridge OLE-to-Corba gateway
~~~~~~~~
By Frank Hayes
Title: | OMG to expand CORBA spec. |
Subject(s): | |
Source: | |
Abstract: | Reports on the plan of Object Management Corp. to expand its Common Object Request Broker Architecture (CORBA) specification; Seeking to make CORBA international standard; Incorporating facility for showing date and time; Adding Data Type Extensions to OMG's Interface Definition Language. |
AN: | 9508294504 |
ISSN: | 0746-8121 |
Database: | Academic Search Elite |
Section: Network Applications
In Brief
The Object Management Group, Framingham, Mass., has said it plans to expand
its Common Object Request Broker Architecture specification. The OMG seeks to
make CORBA an international standard; to incorporate a facility
for providing a standard way of showing date and time; and to add Data Type
Extensions to the OMG's Interface Definition Language.
CORBA Overview | CORBA Internet Sites | CORBA Books | CORBA Articles |