1. Field of the Invention
The present invention relates to a communication gateway for providing access to an enterprise server application from a Distributed Component Object Model (DCOM) environment, and more specifically, to a system in which a developer creates a DCOM client which communicates through a standardized DCOM server and generic gateway to an On-Line Transaction Processing (OLTP) Enterprise Server Application.
2. Description of the Prior Art
The methods by which companies conduct business with their customers are undergoing fundamental changes, due in large part to World Wide Web technology. In addition, the same technology that makes a company accessible to the world, may be used on internal company networks for conducting operational and administrative tasks.
One of the technologies underlying the World Wide Web is the prospect of using component software technologyxe2x80x94the idea of breaking large, complex software applications into a series of pre-built and easily developed, understood, and changed software modules called componentsxe2x80x94as a means to deliver software solutions much more quickly and at a lower cost (source: DCOM: A Business Overview, online at http://www.microsoft.com/ntserver/guide/dcom.asp). The goal is to achieve economies of scale for software deployment across the industry.
A component architecture for building software applications will enable this by: 1) speeding developmentxe2x80x94enabling programmers to build solutions faster by assembling software from pre-built parts; 2) lowering integration costsxe2x80x94providing a common set of interfaces for software programs from different vendors means less custom work is required to integrate components into complete solutions; 3) improving deployment flexibilityxe2x80x94making it easier to customize a software solution for different areas of a company by simply changing some of the components in the overall application; and 4) lowering maintenance costsxe2x80x94isolating software function into discreet components provides a low-cost, efficient mechanism to upgrade a component without having to retrofit the entire application.
A distributed component architecture applies these benefits across a broader scale of multiuser applications. The Distributed Component Object Model (DCOM), developed by Microsoft Corporation, has several strengths that make it a key technology for achieving this. Because it is an ActiveX technology, DCOM works natively with Internet technologies like TCP/IP, the Java language, and the HTTP network protocol, providing xe2x80x9cobject gluexe2x80x9d that will enable business applications to work across the Web. DCOM is also an open technology that runs on multiple platforms.
DCOM has its roots in Microsoft""s object technology, which has evolved over the last decade from DDE (Dynamic Data Exchange, a form of messaging between Windows programs), OLE (Object Linking and Embedding, embedding visual links between programs within an application), COM (the Component Object Model, used as the basis for all object binding), and ActiveX (COM enabled for the Internet). As stated earlier, applications built from components are simply easier to debug and evolve than large, monolithic applications.
The logical boundary for component applications is no longer on a single machine. Businesses want to leverage the benefits of component development across a broader set of shared applications that operate on multiple machines. These types of applications are referred to as xe2x80x9cthree-tierxe2x80x9d or xe2x80x9cn-tierxe2x80x9d applications, where xe2x80x9ctiersxe2x80x9d of application logic, presentation services, business services, and information retrieval and management services, are broken into different components that can communicate directly with each other across a network. To the end user, these applications appear as a seamless extension of their existing desktop environment.
The simplicity, ubiquity, and industry momentum of standard Internet protocols like HTTP make it an ideal technology for linking components together for applications that span machine boundaries. HTTP is easy to program, is inherently cross-platform, and supports an accessible, universal naming service. Much of the excitement around the Java language derives from its potential as a mechanism to build distributed component applications on the Internet. In addition to Java support, DCOM enables components written in other languages, including C, COBOL, Basic, and Pascal, to communicate over the Internet, providing a growth path for existing applications to support Web technology.
As distributed component architectures, such as DCOM, are making their mark as a technology that enables software components to communicate directly with each other across networks, many businesses have a wealth of information that is managed by prior art data base management systems such as DMS, RDMS, DB2, Oracle, Ingres, Sybase, Informix, and many others. In addition, many of the database management systems are available as resources in a larger transaction processing system.
One key to the future success of a business may lie in its ability to capitalize on the ability to interconnect a distributed component architecture, such as DCOM, with existing enterprise On-Line Transaction Processing (OLTP) systems. It defeats the two main goals of component-based development, fast time-to-market and lower development costs, if companies are forced to xe2x80x9chand codexe2x80x9d into their component applications the mission critical services that are required for online production systems.
One method of affecting the desired communication involves development of a unique DCOM server in accordance with the transaction to be executed. This unique DCOM server permits the developer to generate a DCOM client which can communicate through the unique DCOM server to the OLTP platform. A gateway hosted by the OLTP platform interfaces the unique DCOM server to the OLTP system.
The present invention overcomes many of the disadvantages associated with the prior art by providing a generic interface mechanism whereby a remote client residing within a Distributed Component Object Model (DCOM) environment calls services on an enterprise On-Line Transaction Processing (OLTP) system. Thus, the present invention xe2x80x9cmarriesxe2x80x9d the DCOM client architecture and the transactional client/server architecture by providing a generic DCOM server operating within the DCOM environment which communicates through a gateway to the OLTP platform. The services on the OLTP system are designed to accomplish a specific task, for example, update a user""s bank account balance following a debit or credit. In a preferred embodiment, the OLTP system is X/Open compliant. The DCOM Client can be any type of client, including a Visual Basic client, C++ client, or a Web Browser with Active Server Pages (ASP).
A DCOM Client Application is provided visibility to available services on an enterprise OLTP system such as the Unisys 2200 because the Application is linked to a library built from an Enterprise OLTP service view file. This view file defines what input parameters will be provided to the OLTP service and the size and type of each input parameter. If the Enterprise OLTP service is to provide output back to DCOM Client Application, the output view file definition is provided.
When an OLTP request is issued from a DCOM Client, the DCOM Client Application first builds a buffer containing the service call and the appropriate set of input parameters, then passes this information to the generic DCOM Server of the present invention. The DCOM Server receives the service calls from the DCOM Client Application, builds an input buffer from the input parameters, and passes the information to the gateway via a standard pipe. The gateway receives the input buffer from the generic DCOM Server by listening to the pipe. The gateway then forwards the input buffer to the communications program, which in a preferred embodiment is the Open/OLTP HTP:c program. Finally, the communications program passes the input buffer to the enterprise node for processing by the requested service.
After the OLTP system services the request, a response is passed back via an output buffer to the gateway, which returns this buffer to the generic DCOM Server. The Generic DCOM Server then unpacks the output buffer into individual output parameters, and returns the parameters to the DCOM Client application.
It is most important that in accordance with the present invention, the Generic DCOM Server and the DCOM Gateway are completely provided to the DCOM client developer by the system vendor. Thus, the client developer is able to generate a complete DCOM client, calling upon the substantial capabilities and services of the OLTP system, without the necessity of interacting in a developmental way with the DCOM communications protocol. The client developer in essence performs the entire developmental task within the DCOM environment. The Generic DCOM Server and DCOM Gateway are supplied to insulate the client developer from the details of the communication interface between the DCOM terminal and the OLTP host platform.
The present invention shortens application development time by permitting the developer to concentrate only upon client development without concern for generation of a unique DCOM server for each client. Furthermore, because the developer is insulated from the DCOM communications protocol, the development can be accomplished using a high level, commonly available development tool, such as Visual Basic. The DCOM system, such as NT, experiences greater reliability and maintainability, because a single generic server and gateway are substituted for potentially unique servers and gateways for each client application.
USPTO Backgrounds
USPTO Backgrounds