sunflash-Distributed to mailing list sunflash@suntri sunflash-Send requests and problem reports to owner-sunflash@suntri.east.sun.com ---------------------------------------------------------------------------- The Florida SunFlash The Vision And The Reality Of Application Integration Object Link Environment (OLE) & ToolTalk SunFLASH Vol 53 #36 May 1993 ---------------------------------------------------------------------------- This is an article by W. Frank King of Pencom Software that was submitted by Elizabeth Richardson (Public Relations Specialist, eli@pencom.com). -johnj ---------------------------------------------------------------------------- 53.36 The Vision And The Reality Of Application Integration A brief technical article that describes and contracts Microsoft's Object Link Environment (OLE) and SunSoft's ToolTalk Service. By W. Frank King of Pencom Software. ---------------------------------------------------------------------------- The Vision And The Reality Of Application Integration - How To Get Real W. Frank King, Pencom Software The information technology industry has been awaiting the wide-spread adoption of distributed applications processing for some time now and there are an amazing variety of technologies available. Efforts like the Common Open Software Environment point the way to future technologies based on "Open UNIX", DCE, objects and multi-media. The vision is one of networked nodes of cooperating systems executing tasks assigned based on optimally efficient resources, all making the manipulation of information as easy, fast and seamless as calling home. This is truly an appealing vision for companies whose competitive advantage resides in the instant availability and manipulation of information. Unfortunately, for most companies, the reality is more of heterogeneous islands of computer technology, some with networking capability, but definitely not cooperating "object-ware" based applications. The question for most companies is not whether to move forward with this technology, but where to begin and at what cost. Integration Approaches In the past, the answer to developing "integrated applications" was a simple one - choose a single vendor and its proprietary hardware and proprietary software. The centralized mainframe platform provided a basic level of consistency for the integration of related tasks. The mainframe and applications were developed by a single company, taking advantage of the distinctive proprietary hardware features. This was an easy approach, but the capabilities were very limited. The advent of the microprocessor quickly eliminated the tight integration and centralized control of information technology inherent in the mainframe solution. With microprocessor-based systems, individual users were able to solve specific "point problems" with off-the-shelf software applications. The fact that a particular word processor, spread sheet, or electronic mail system did not interact in a smooth manner was less of a concern than was maintaining a smooth operating hardware system platform. With the proliferation of the UNIX multi-user operating system and networking technologies, those islands of automation have slowly become reintegrated into a mass of interacting, all-be-it uncooperative technology. The "distributed" part of the equation had become reality, but not the "cooperative" part. The advantages of centralized information technology, including instant and seamless data availability and integrated tool sets have been outside the grasp of most networked environments. Clearly, there are a number of technologies which emerged during the 1980s, some of which have become entrenched in their use. Technologies such as TCP/IP, remote procedure calls, peer-to-peer communications, network file systems and so on, have helped to integrate user applications and have increased overall productivity. The problem is that these technologies have dealt with the integration problem at too low of a level. The complexity inherent in these tools limits the development of cooperative applications and prevents large scale deployment of integrated solutions. Technologies of the late 1980s and early 1990s are pointing the way to an easier-to-use method for distributed application integration, including object-oriented programming, the Distributed Computing Environment from OSF and the Object Management Group's object request broker technology. Unfortunately, these technologies are very new or still under definition and have thus been slow to find their way into corporate America. All these technologies have pointed the way toward the ultimate proliferation of cooperating integrated applications. There is a need for a solution which is available across multiple platforms and will provide a path to the emerging technologies. Such a solution will provide the ultimate, open systems-based object-oriented solution to cooperative applications processing. Customers who need a solution today cannot wait for the slow moving standards process in order to get moving. Application Integration Frameworks To The Rescue There are two major application processing frameworks available now which will help companies start taking the steps toward the implementing the cooperating distributed model of the future. These products include the Object Link Environment (OLE) from Microsoft and the ToolTalk Service from SunSoft. In addition to these general purpose frameworks, there are a large number of rapid application development environments which are being promoted as tools for application development . These niche focused products will not be considered here. The goals of OLE and ToolTalk are to provide the glue which allows applications to share information with one another in an easy and consistent manner. Applications which work with one another provide for an automated workflow, tying together synergistic yet non-integrated tasks. These "enabled" applications are more than merely sharing information in generic and standardized formats, these frameworks promise to a level of integration possible only by capturing domain specific details of the task at hand. For example, a visual communications artist may use a concept drawing board to create initial ideas. Selecting one of the ideas for further refinement, a drawing tool may be used to refine the general concept. The approved concept may then be completed through the use of a photo-realistic imaging / paint tool. Finally, color separations must be generated. Each of these steps are distinct, with no one application providing the complete solution to the entire task. Yet there are applications which provide "point solutions." Integration of the point products will allow for the automation of the entire task and allow each application to communicate information specific to the visual communications process. Such is the concept of application integration. It allows the visual communications professional to select "best-of-breed" applications which work cooperatively in order to solve the complete task. The challenge lies in setting up a framework in which the applications do not require a direct or "hard-coded" knowledge of each other in order to communicate with each other. This "plug-and-play" capability also requires that existing applications can be integrated into the framework, either through source code modifications or through encapsulation with interoperability "wrappers." The ability to work in a network is also important since the future vision is one of distributed networked systems. Working in a network means that an application which requires access to a resource, need not have a predefined source to gain that access. The request for information must be satisfiable dynamically, with the application framework handling the detail. Scaleability in performance is also needed so when other applications or users are added to a cooperative session, the communication points between the applications do not become overloaded. OLE from Microsoft is the only approach to providing application interoperability for the PC marketplace. The promise of OLE is one of Windows applications exporting their most important features to other applications. OLE provides several capabilities. First, OLE allows applications to export data, independent of format, into objects which can then be manipulated independent of the object contents allowing for the creation of compound documents. Next, OLE allows for the automatic editing and updating of objects, refered to as "edit-in-place." For example, if a graph is generated based on the contents of a spreadsheet, and the graph is placed into a word processor, then the contents of the word processor document will be updated automatically when the numbers in the spreadsheet are changed. Finally, OLE also allows for the exporting of an application's functions for manipulation of the object. OLE-enabled application data may be be either linked or embedded. With linking, the information is stored separate from the compound document within which it is stored. Any other compound documents which reference the data will always reflect the newest version. Embedding the data places it completely within the compound document. Changes to the data are localized to the document within which the object is embedded. In an OLE-enabled application, an object is defined to be any specific data which may be selected for editing within that application. This data object may then be inserted as either a linked or embedded object within a compound document. Selection of the object for edit starts the application in which the object was created. OLE also has the concept of a package, which provides a iconic representation of either an object, command or any part of a document. As with the object, a package may be inserted into any document created by an OLE-enabled application and selection of the package allows for the execution of any command within the application in which the package was originally created. OLE's functionality is much like a single platform RPC mechanism that allows a local application to make calls to procedures within other applications on the same platform. OLE holds it own in a single user PC environment, in which a software developer knows as the sematics of the programs which are to become "OLE-enabled." The sheer number of Windows 3.1 installations means that OLE will be a major force in the marketplace. OLE-enabled applications are available today in large numbers. Unfortunately, OLE falls short in two area. First, OLE does not inherently provide support for distributed networked applications. OLE 2.0 will support networking only in so far as the user can mount remote disks in order to create a single virtual file system. Second, the OLE interface is quite difficult to learn and use. Programmers who are developing OLE applications can provide only general types of data sharing and processing. OLE provides no mechanism for defining communications messages which are specific to a particular market or task, since there is no specific message protocol defined other than a general object linking mechanism. In spite of these short-comings, OLE will be a major force in the PC marketplace. How well it will compete in the broader client/server distributed computing marketplace is not clear. A different approach to application integration is represented by ToolTalk from SunSoft. This technology has been chosen by Common Open Software Environment (COSE) backers HP, IBM, Sun, SCO, USL, and Univel as the basis for developing the open systems industry standard for application connectivity. ToolTalk already provides a portable, asynchronous, multicast message service which is built on top a remote procedure call mechanism. ToolTalk does provide for true open systems inter-application connectivity since the ToolTalk Service is available on Sun, HP, IBM, DEC, SGI, Integraph, NCR and Cray platforms. Unlike OLE, ToolTalk was designed with a true distributed architecture in mind. A major design goal of ToolTalk was to enable universal "plug-and-play" application integration for large numbers of users doing a wide variety of tasks across the network. By providing a software message server for each user's applications and by enabling those servers to cooperate transparently to both users and developers, ToolTalk allows for consist performance as the number of users increases. Additionally, it allows any application to interact with any other application on the network without restriction. Through interoperability alliances, software suppliers and end-users have defined market specific application message sets for ToolTalk that allow applications to integrate using those messages. The messaging protocol describes how applications interact in order to accomplish a particular task. Standard message sets have been defined for Desktop Services, Document and Media Exchange and Computer-Aided Software Engineering (CASE). Applications will plug-and-play, assuming adherence to particular application messaging protocols. This is a much more general approach than that which was taken by Microsoft with their OLE product. This generality allows for a tighter functional integration of applications by creating well-defined task-specific messages. ToolTalk is an inherently network-based framework, supporting both individual sessions and global distributed workgroups. The ToolTalk service hides the location of cooperating applications from the programmer (and thus the user) by allowing applications to post their interest in particular types of messages. The ToolTalk Service coordinates the receipt and delivery of massages to the applications which have expressed an interest in particular kinds of messages. This makes it very straightforward to program the ToolTalk API since the sharing of information is loosely coupled via the ToolTalk Service servers. In addition to providing a open backbone for the development of integrated enterprise-wide applications today, ToolTalk is positioned to move developers and users of cooperating object-based applications to the future. SunSoft has committed to port the ToolTalk API to the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA). This object-oriented computational model will allow for the development of enterprise-scalebale distributed object-based applications and will provide a full range of tools and services for the development of cooperating applications. As CORBA-based technology becomes prevalent, applications which are written to the ToolTalk API will also run in other CORBA-compliant environments that support the ToolTalk API. Despite much hype and a lot of vision, distributed cooperating applications are making their way to reality. Two major competing interfaces are available today: OLE and ToolTalk. These two frameworks compete in different markets, provide functionality at very different levels, and provide a stable environment for developing cooperating applications today. The priority that a particular company places on individual versus distributed enterprise application integrate will determine whether OLE or ToolTalk is the right solution for them. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ For information send mail to info-sunflash@Sun.COM. Subscription requests should be sent to sunflash-request@Sun.COM. Archives are on solar.nova.edu, ftp.uu.net, sunsite.unc.edu, src.doc.ic.ac.uk and ftp.adelaide.edu.au All prices, availability, and other statements relating to Sun or third party products are valid in the U.S. only. Please contact your local Sales Representative for details of pricing and product availability in your region. Descriptions of, or references to products or publications within SunFlash does not imply an endorsement of that product or publication by Sun Microsystems. Send brief articles (e.g. third party announcements) and include contact information (non-800#, fax #, email, etc) to: John McLaughlin, SunFlash editor, flash@Sun.COM. +1 305 351 4909