Client Distributed Objects for Windows

Juan J. Collas
Moreira Consulting, Inc.

CONFIDENTIAL
20 September 94 [DRAFT]

Executive Summary

NeXT 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:

Lowers customer resistance to NeXT object solutions due to existing investments in Microsoft technology.
Helps close sales today for customers who are exploring options for client/server initiatives.
Strengthens and cements NeXT's role as a provider of the object engines in an enterprise-wide network.
Is cheap to develop and cost-effective for the customer to deploy.
Has a quick-time to market, taking under 6 months to develop and productize.

Client DO for Windows is a set of development libraries, much like NeXT's PDO offering. However, being much more light-weight than PDO, it only offers a C-language binding to already existing Distributed Objects on the network and an OLE-compliant control to integrate with tools such as Microsoft Visual Basic and C++. Client DO has no capability to vend objects to the network. The purpose of Client DO is to allow non-NEXTSTEP platforms such as Microsoft Windows 3.11 to access and send messages to DO instances on NEXTSTEP and OpenStep machines.

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:

Inexpensive: It is cheap for NeXT to develop, and should be cheap for the customer to acquire.
Rapid Product Cycle: Short development time (less than 6 man months) means quick time to market.
Strategic: Allows NeXT in the door with an enterprise solution on the desktop talking to NeXT-based servers before Microsoft can define OLE3.
Scalable: With enterprise development based on DO technology, the desktop can scale from Windows 3.11 with Client DO to RobinHood, then to OpenStep.
Inclusive: DO capabilities can be added to Windows apps, solidifying NeXT as the enterprise engine of choice for corporations.
Low Entry: Companies can start developing with Client DO for under $1000 (NEXTSTEP User as DO server, Client DO).
Lessened Developer Training: Since the Client DO API is in C, developers don't have to learn Objective-C in order to develop code that participates in the OpenStep enterprise.

Customers will always consider a solution if it can successfully integrate their existing hardware and software into a viable enterprise solution, especially if it can be done cheaply and quickly. This is the primary purpose of Client DO.

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 Feedback

Our 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 Design

Client 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:

A dynamic link library under Windows that handles the specifics of the DO protocol.
An OLE compliant "app" which allows Microsoft applications to view NEXTSTEP Distributed Objects as objects within the OLE application.
An OLE custom control (OCX) that lets a Visual Basic or C++ user access to the DO proxy.

The Client PDO API

The 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);

This returns a DOProxy object or NULL, which means that the connection didn't take place.

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:

    DOProxy *aProxy;
    float retVal;

    /* if aProxy is NULL, we didn't connect correctly */
    aProxy = DOConnectTo("*", "TempConverter");

    DOSendMsg(aProxy, "convertToCelsius:", &retVal, 120.0);

    printf("Celsius value is: %f\n", retVal);

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 Interface

The 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
    Dim X

    Set Calc = CreateObject("Proxy.TempConverter")

    X = Calc.ConvertToCelsius(120.0)

    Print "120.0 degree Fahrenheit in Celsius = ", X

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 Concerns

It'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:

RobinHood is 18 months away. Client DO is 4 months away from start of development.
Client DO has far less training and development requirements on customers (C-based API, OCX interface under Windows).
Client DO should be very cheap to the customer, $20-$40 a seat. This makes the barriers of entry very low for hesitant customers.
Client DO allows customers to start deploying NeXT technology over a year before delivery of RobinHood.

As the founders of Hewlett Packard once said "If we don't eat our young, our competitors will." It's worth noting that quote when considering whether Client DO will hurt sales of RobinHood.

Next Steps

In 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.