Page 2 of 4
Most CORBA implementations in the market support versions 1.1 and 1.2 of the standard; only a handful support some of the more advanced features found in version 2.0. One important component of 2.0 is the Internet Inter-ORB Protocol (IIOP). The IIOP specification allows ORBs from different vendors to communicate on the local network or even across the Internet using the Transmision Control Protocol/Internet Protocol (TCP/IP) as the basis of data transport. It is not surprising to hear that even with a common standard, ORBs are implemented and behave differently; thus the need for IIOP. For example, until the release of an IIOP capable ORB by Sun, Joe can communicate only between applications that conform to the NEO system.
Companies such as Iona Technologies provide ORBs that can interface with other object models such as COM/DCOM that forms the basis of Microsoft's OLE and distributed OLE system. It has not been proven which is the "best" object model by far; most have specific uses. Microsoft's system works very well if you are in a Microsoft environment, of course, which synchronizes with their philosophy. Other models such as DSOM from IBM simply move the focus of execution from the desktop (in COM) to the server, which is also how CORBA works.
NEO is not an acronym for anything, or so Sun would have us believe. My guess is "Networked Enterprise Objects"; I could be wrong, it could be something "Not Entirely Obvious." In either case, NEO is the release version of Sun's former Distributed Objects Everywhere (DOE) which promises to do just that: Take the computing industry into the world of distributed object computing. With all the hoopla, you should know that Sun is by no means the first to come up with this paradigm. It has existed for quite some time. Smalltalk from Xerox PARC, for example, implemented the same concept well over a decade ago. However, Smalltalk as a language has never caught the popularity of others. NeXT Software has actually had a distributed enterprise object system for several years and would best count as the most mature of commercial distributed object environments. Beset with its own problems, NeXT has not managed to popularize this system widely. Nevertheless, other vendors recognize the importance of this concept, which is why NeXT's OpenStep has been licensed by some of the top vendors, including Sun. NEO can interface directly with OpenStep as naturally as with its own components.
NEO consists of several components: Solaris NEO, the operating system component; WorkShop NEO, the software development environment; and NEO Administration Tools, which consists of converted versions of classic Sun applications such as Solstice Manager (Sun Net Manager, to the old hats). Why would you even want to have new versions of these same packages to support NEO? Couldn't a new version just be added in as a layered product? The clear answer is no; you can certainly access current applications and systems through NEO, but each of these applications acts as a monolithic system through the eyes of the NEO client application. What you need is to create interfaces at the different levels of each product, so that they can be accessed in subsets. That would make a much more efficient system, where you use only the resources you need.