| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

### Wrapping

One of the main themes of Microsoft’s approach to other platforms is that the connectivity being provided by the ports of DCOM is there primarily to enable the developer to link to existing applications. Microsoft is not keen on developers writing lots of new components on machines running Unix or MVS, for example, for the simple and very obvious reason that it prolongs the life of these operating systems, when Microsoft wants the world to use Windows.

Digital and HP, of course, do want you to write lots of new applications on their Digital Unix, HP-UX, and OpenVMS machines for the equally obvious reason that they want to prolong the life of these systems this is one area where Microsoft and its partners don’t agree. Anyway, talk to Microsoft and they will actively discourage you from putting new components on these other boxes and operating systems, while encouraging you to access your legacy/heritage systems on these boxes.

If you want to invoke or use legacy code from an object-oriented application, however, you have to give it an object-oriented interface—make it look like a component and adapt the logic to respond to object-based calls. Generally speaking the legacy code acts as a server for client requests, so the wrapper code turns the legacy code into a “pseudo-object” (or objects) that can be invoked using object-oriented techniques. This process is termed “wrapping” A wrapper is a “software envelope for existing business functions that hides the implementation details of the function.”

The functions of a piece of software can be accessed via screens or terminals, a callable API, a command line interface, or via other sorts of input such as transaction files. Wrapping technology works best when applied to software accessed via APIs or command lines and in practice, is better applied to application functions like an application package, software package, or in-house application. Both the API and Command line then represent the functionality of the internal code and the ‘calls’ are then translated into object-oriented invocations.

Many ORB vendors talk about wrapping as though it was a simple case of adding a few lines of code. The very word “wrapping” conjures up images of presents being wrapped in paper rather than the sort of complex problem-ridden task it actually is. The sorts of problems the developer has to overcome in practice are:

  • the application state may need to be preserved between wrapper invocations
  • object and method calls may not map one for one with function calls
  • application error conditions must be mapped to wrapper code exceptions
  • application and wrapper code threads have to be matched (they can become mismatched if not properly managed)
  • input/output and the matching of data structures from OO to other structures can be complex
  • there are implicit problems with performance as translation is involved

The developer must first decide which of the functions in the legacy code are “invokable” from the client. He then builds an interface which represents these as objects and methods. The interface can be generated in the normal way to provide stub code in C or C++, for example, but the developer must then map the C and C++ data structures to the internal data structures (in COBOL, say) and map object calls to function calls. It is the wrapper code which does this mapping and translating. Where the application is accessed via a command line interface, the wrapper code can invoke the application and execute application commands in an operating system specific script.

The wrapper code developed by the programmer may consist of a portion which takes the input from the server stub (unmarshalled data but in object-based form), a mapping portion to do all the translation needed, and a third portion which interacts directly with the legacy application. In practice the mapping section can become extremely complex—one to many, many to many, and many to one mappings between object invocations and function calls can occur. In some cases a separate “Interface Engine” is needed rather than a simple wrapper, which can handle multiple clients and servers.

Thus, Digital’s search for third-party wrapping software to be provided with their ports is particularly welcome. I recommend that if you do want to access existing systems from a component that you do look for third-party products to help you. It is worth mentioning that Software AG has added some extremely useful automatic technology to their “EntireX” range of products, which enable Natural programs to be wrapped as ActiveX components.

Previous | Table of Contents | Next