Client Distributed Objects for WindowsJuan J. Collas
Moreira Consulting, Inc.
20 September 94 [DRAFT]
Executive SummaryNeXT has a gap in its product offerings for enterprise-wide object solutions. There is no product available from NeXT that allows non-NEXTSTEP desktop client machines to access Distributed Objects running on NEXTSTEP and OpenStep platforms. RobinHood, currently under non-disclosure, will bring the run-time environment of NEXTSTEP to both Microsoft's Chicago and Daytona NT platforms, but that will not be available for 18 months.
If NeXT has no solution to sell customers in the next 18 months, there is a real risk that NeXT will not be in a position to become a core technology in the bulk of enterprise network deployments due to the market competition from both Taligent and Microsoft, both of whom will be releasing object-oriented environments targeted at the enterprise.
Client DO for Windows is an enabling technology that:
Why Client Distributed Objects?Most companies hesitate to commit to solutions that aren't end to end. Deploying PDO servers and Openstep clients works to some degree, but excludes Windows 3.1 machines, SunOS, Macintoshes and other non-Openstep compliant machines from the enterprise developed on top of NEXTSTEP technology. One solution is to develop portable client technology that allows non-Openstep machines to participate in communicating with Openstep servers using Distributed Object technology.
This can be done by writing a PDO Client library which is written in C code which allows applications that use the client library to communicate with Distributed Objects. This client library would implement the DO protocol and allow simple method calls to DOs to return data from the servers. This would allow non-Openstep machines to participate in a PDO network, although clearly not as fully as an Openstep application.
In order to make a client PDO application under Windows 3.1 more attractive, Visual Basic custom controls could be written that interface to the PDO client DLL to make it very easy to connect to and extract data from a DO. This would make a PDO server-based application more attractive to customers, since they could preserve their existing investment in older technology while moving forward into advanced NeXT-based solutions.
The reason to do this is to extend NeXT's powerful Distributed Object enterprise messaging technology to systems that presently cannot support NEXTSTEP or OpenStep directly, whether for technical or corporate reasons. This will reduce customer resistance to NEXTSTEP technology in the enterprise based on the argument that NEXT technology doesn't provide a solution for already existing legacy client systems (ie, Windows).
NeXT now has solutions that allow access to back-end legacy data with the release of Enterprise Objects and other third-party products. NeXT does not have a solution to integrate the thousands of PCs running Microsoft Windows into those back-end solutions, leaving a significant portion of the customer's re-engineering issues unanswered. Client DO for Windows provides the answers that NeXT needs in order to succeed with new accounts preparing to explore and deploy object technology.
Potential NEXTSTEP customers are generally unable to implement NEXTSTEP solutions because their existing investment in legacy systems is immense; mainframe applications on the back-end, underperforming Windows applications on obsolete hardware on the front-end. Deploying NEXTSTEP in their enterprise requires a very large investment in new hardware, a new operating system, training, developer support, and user acceptance. For most companies, this cost is too great, especially since they know that Microsoft will deliver a solution within the next couple of years. A company might reasonably argue that it's generally better to do nothing than commit to a technological solution from a company whose viability may be questioned in two years, stranding the customer with an unmaintainable enterprise solution.
Client DO is appealing for several reasons:
It's very important to own the back-end of a business, because if you're like NeXT and don't have a high-volume presence in the market, you need to control the core of a business enterprise. PDO servers on the back-end do this, since both Openstep and non-Openstep machines can participate, minimizing the cost to a business to deploy the NeXT enterprise solution.
Customer FeedbackOur experience with customers who have not used NEXTSTEP and are embarking on a client/server re-engineering strategy has been overwhelmingly positive when we talk about Client DO as a potential solution to the legacy problem for Windows clients.
For example, Gillette North Atlantic is in the middle of a client/server re-engineering effort. When presented with 3270Builder as a solution for providing clean object-oriented access to his mainframe data, he eventually turned to the issue of how his existing Windows PCs would get access to these objects. Client DO is a perfect solution to this issue.
John Hancock is another instance of a client with similar needs to Gillette. They are exploring a PowerBuilder to Sybase solution for re-hosting their IBM mainframe data. The 300 client seats must be Windows. Client DO is again a crucial piece of the NeXT solution.
Fidelity Investments can already use Client DO technology to point out to their senior management that using NEXTSTEP now does not exclude Fidelity's major commitment to Windows. Fidelity is foremost a Microsoft environment, and new technology must always consider that factor when providing solutions. Client DO is a solution that allows Fidelity to continue developing NEXTSTEP solutions, knowing that they can be integrated into the corporate structure at some time in the future.
In short, Client DO is also a political solution. It allows senior management to feel secure that any new applications developed in NEXTSTEP/OpenStep can be accessed by the existing Windows applications. This is a powerful argument in favor of exploring and deploying NeXT enterprise technologies.
Functional DesignClient DO for Windows consists of a DLL which implements the NeXT Distributed Object protocol. There is also an OCX (OLE Custom Control) which allows Visual C++ and Visual Basic developers to create a DO proxy "control" which will facilitate communication to a DO server. There will be very little code to write, since the DO OCX will handle all the communication issues including extracting all the methods that the vended DO has, and presenting them to the Windows developer as OLE actions. This OCX will allow the client developer to send messages to the vended DO, and retrieve data from it easily. All the hard work is handled by the DO DLL on the client (type marshalling, error handling, connection negotiation).
The components of Client DO are:
The Client PDO APIThe client PDO interface is comprised of a single data structure and two C function calls:
The data structure is called DOProxy. It is a data structure that contains network connection information, and a reference to the object on the DO server side. It is opaque to the programmer.
In order to acquire a DOProxy, you need to connect to a vended DO. Here is an example of the DOConnectTo function:
DOProxy *DOConnectTo(const char *host, const char *objname);
With a DOProxy structure, methods can be called on the object with DOSendMsg. Since the PDO protocol actually passes back the entire protocol description and argument types as part of its internal protocol negotiation, the DOProxy object can keep track of the message types for its object, removing the necessity of explicitly providing type string information to the DOSendMsg function call. The format for the DOSendMsg call is:
DOSendMsg(DOProxy *proxy, const char *msgname, void *retVal, ...)
For example, to call the DO method ' - (float)convertToCelsius:(float)aFloat;' on the appropriate DO object, the C code would look like:
Of course, this function can return other DOProxy objects, just the way DO does. Although the call looks synchronous, DOSendMsg looks at the method signature. The signature encodes whether the call is synchronous or asynchronous, so DOSendMsg can return immediately, if that information is encoded into the method call.
The OLE InterfaceThe OLE interface depends on the current state of Microsoft software API advancements. One possible way is to use the OLE automation technique, which lets the Microsoft Visual programming tools create 'objects' which can access OLE-compliant applications. By creating a 'proxy' application, connections can be established to vended Distributed Objects and encapsulated with Microsoft's data structures.
Here's some sample Visual Basic code which communicates dynamically with a vended DO object called "Calculator". Note that the OLE Proxy object is doing simple name mappings to conform to the OLE interface style.
Dim Calc as Object
On top of that, an OLE Custom Control (OCX) can be built that shields the Microsoft programmer from writing Visual C++ or Basic code. This could be argued to be an optional component for delivery, but it does simplify the programmer's interface to the proxy.
Issues and ConcernsIt's been suggested that this product should be implemented as a private, non-DO protocol which could connect from the client to the DO server machine, and a process which could communicate from the private server on the DO server machine to the vended DO. Other 3rd party tools do this, such as DEC's ORB, along with Iona's and Xpersoft's offerings.
This approach misses the point; the assumption here is that NeXT shouldn't share the DO protocol. Ideally, NeXT would own the Client DO, since that shows potential customers that NeXT has a commitment to this approach as an enterprise-wide strategy. If NeXT doesn't extend the DO protocol to the client platform, then NeXT will have no advantage over other 3-party middleware solutions. The purpose here is for NeXT to have a seamless solution from the desktop to the DO server.
The issue of CORBA compliance has also been raised; this is addressed by making sure that the Client DO library is developed as a framework which can include other protocols. Since the core idea of DO is the proxy, the creation of a proxy can include Microsoft's OLE3 (Distributed), Sun's RPC and DOE, OSF's DCE, and OMG's CORBA. Having the ability to handle multiple protocols diminishes Microsoft's exclusive grasp on the desktop and allows NeXT to control the APIs for enterprise communication.
One concern that's harder to answer is whether the forthcoming RobinHood announcement will diminish any requirement for Client DO. Alternatively, Client DO might eat away at some of RobinHood's market share. It won't, for several reasons:
Next StepsIn order to develop a true client DO implementation, NeXT would have to make the DO protocol public and stable so that the implementation can work with existing DO objects. Although NeXT could argue that the details of the protocol are proprietary, network protocols invariably benefit from having their descriptions made public, since that increases the number of available implementations, which increases the likelihood of their being adopted as de facto standards. As an example, Sun made the XDR and RPC protocols used in NFS public domain, which has guaranteed the dominance of NFS as a network file standard on all Unix machines.
Realistically, NeXT would own this technology, since it is a strategic component of an enterprise-wide solution. It's estimated that providing the specified components as product will take 4-6 months. NeXT does not need to make developer resources available, since the project can easily be contracted out, assuming that NeXT makes the protocol specifications public.