WO2003032117A2 - Dynamic corba gateway for corba and non-corba clients and services - Google Patents

Dynamic corba gateway for corba and non-corba clients and services Download PDF

Info

Publication number
WO2003032117A2
WO2003032117A2 PCT/US2002/032037 US0232037W WO03032117A2 WO 2003032117 A2 WO2003032117 A2 WO 2003032117A2 US 0232037 W US0232037 W US 0232037W WO 03032117 A2 WO03032117 A2 WO 03032117A2
Authority
WO
WIPO (PCT)
Prior art keywords
corba
soap
service
client
virtual
Prior art date
Application number
PCT/US2002/032037
Other languages
French (fr)
Other versions
WO2003032117A3 (en
Inventor
Aleksandr V. Zhdankin
Aleksey P. Dolgov
Original Assignee
Harris Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Harris Corporation filed Critical Harris Corporation
Priority to AU2002330269A priority Critical patent/AU2002330269A1/en
Publication of WO2003032117A2 publication Critical patent/WO2003032117A2/en
Publication of WO2003032117A3 publication Critical patent/WO2003032117A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/465Distributed object oriented systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/46Indexing scheme relating to G06F9/46
    • G06F2209/461Bridge

Definitions

  • This invention relates to the field of distributed object computing in a client-server environment, and more particularly, this invention relates to a Common Object Request Broker Architecture (CORBA) used in distributed object computing.
  • CORBA Common Object Request Broker Architecture
  • objects are pieces of software that encapsulate an internal state and make it accessible through an interface, including object operations and attributes that are remotely accessible.
  • a naming service can be used to connect portions of the interface.
  • Clients invoke operations on the remote object, which acts as a server.
  • Objects belong to classes that are incrementally modified through inheritance. Examples of well-known object-oriented languages using these types of objects include Java or C++.
  • the objects are collections of operations that share a state, where the operations determine the messages (or calls) to which the object can respond. This shared state is hidden from the outside world and only accessible to the objects operations.
  • One key aspect of object oriented programming is the reuse of programming effort by the reuse of sub-classes.
  • Physical resources can have components that can be modeled in an object oriented manner and this programming effort can be re-used.
  • Different programs such as Java or C++, enable direct reuse of classes, but usually only if the same language can be bound or linked together.
  • control and data processing functions are distributed among many geographically spaced computers at different locations making control over interfacing and communication among the different physical devices problematic.
  • OMG Object Management Group
  • CORBA Common Object Request Broker Architecture
  • the CORBA architecture uses an Interface Definition Language (IDL) , which is a declarative language similar to C++. It includes interfaces that are similar to classes of interface inheritance with input and output arguments and data types that are passed along with an operation.
  • IDL Interface Definition Language
  • the Interface Definition Language declares remotely accessible server objects in a platform in programming language-neutral manner without implementation.
  • the CORBA architecture also includes an Object Request Broker (ORB) , which allows a client to communicate to an object through an object reference that acts as a pointer.
  • ORB Object Request Broker
  • the Object Request Broker finds a server object for a client request and prepares the object to receive the request, transmit the request from the client to the server object, and return output arguments back to the client application.
  • RPC object-oriented Request Procedure Call
  • Other elements of the CORBA architecture include a
  • POA Portable Object Adaptor
  • DII Dynamic Invocation Interface
  • HOP Internet Inter-ORB Protocol
  • II Dynamic Invocation Interface
  • II Dynamic Invocation Interface
  • HOP Internet Inter-ORB Protocol
  • II Dynamic Invocation Interface
  • II Dynamic Invocation Interface
  • HOP Internet Inter-ORB Protocol
  • II Dynamic Invocation Interface
  • II Dynamic Invocation Interface
  • HOP Internet Inter-ORB Protocol
  • Interface and Implementation Repository as known to those skilled in the art.
  • One of the drawbacks of most CORBA architectures is that once the definition of the interface application provides or uses has changed, it should be rebuilt in order to work with the new interface even if the dynamic invocation is used.
  • CORBA gateways There are some prior art CORBA gateways that approach this problem. Some scriptable interface specifications are supported by the Object Management Group. For example, one CORBA script language implementation allows CORBA applications (or services) to be revealed to a non- CORBA client. This type of CORBA universal gateway has been used before and is not tied to a particular scripting language. The CORBA object is serialized to HTML or a Simple Object Access Protocol (SOAP) and published. There are also several implementations of Extensible Markup Language (XML) to CORBA bridges. These capabilities, however, are more restrictive and are not used for dynamic CORA systems implementation.
  • XML Extensible Markup Language
  • the present invention is advantageous and allows a service that is not specified through a Common Object Request Broker Architecture (CORBA) to be exposed to a client that is CORBA specified.
  • CORBA Common Object Request Broker Architecture
  • a SOAP request can be prepared by interactive scripting as part of a client's business logic function that is operable via a SOAP interface.
  • References can be created and maintained to virtual CORBA services via a virtual CORBA service object.
  • the virtual CORBA services can be addressed by a set of HTTP Uniform Resource Locators (URL's) .
  • the references can be exposed as a monolithic CORBA service.
  • the CORBA name value list data types can be serialized SOAP messages.
  • An Internet Inter-ORB Protocol (HOP) callback can be generated using a Simple Object Access Protocol (SOAP) message.
  • SOAP Simple Object Access Protocol
  • Interface Definition Language (IDL) method calls can be translated to the SOAP messages.
  • a specified method implementation HTTP uniform resource locator can also be transmitted via a virtual CORBA service object that forms a CORBA gateway.
  • FIG. 1 is a high level block diagram showing a standard Object Request Broker (ORB) .
  • ORB Object Request Broker
  • FIG. 2 is another high level block diagram illustrating a standard CORBA infrastructure implemented in a communications network.
  • FIG. 3 is a high level block diagram of the dynamic CORBA gateway of the present invention, which creates and maintains references to virtual CORBA services that can be addressed by a set of HTTP Uniform Resource Locators (URL's) and exposed to the CORBA system as a monolithic CORBA service .
  • URL's Uniform Resource Locators
  • FIG. 4 is another high level block diagram of the dynamic CORBA gateway of the present invention and showing intercommunication among the CORBA clients and non-CORBA services.
  • FIG. 5 is a high level block diagram showing various components of the dynamic CORBA gateway and system of the present invention.
  • FIG. 6 is another block flow diagram showing collaboration among non-CORBA clients, non-CORBA services and CORBA applications as an example of the present invention.
  • the present invention advantageously provides a dynamic CORBA gateway that allows a CORBA service to be exposed to a non-CORBA client, and a non-CORBA service to be exposed to a CORBA client.
  • An Internet Inter-ORB Protocol (HOP) callback occurs using a Simple Object Access Protocol (SOAP) message.
  • SOAP Simple Object Access Protocol
  • a Dynamic Client Business Logic function has a script that prepares a SOAP request and is operable with a SOAP upstream interface, a SOAP downstream interface, and a Virtual CORBA Service Object (VCSO) . Pluggable dynamic modules for service implementation are operable with the SOAP downstream interface using the Simple Object Access Protocol.
  • CORBA CORBA architecture and Simple Object Access Protocol (SOAP)
  • SOAP Simple Object Access Protocol
  • CORBA architecture includes a series of standards and protocols to allow interprocess communication in a heterogenous environment of a large communications network such as the internet, enterprise, or similar networks.
  • Applications can be written easily for many different operating systems at once in different languages using CORBA, thus, making CORBA one of the more popular interprocess communication techniques.
  • OMG Object Management Group
  • CORBA an Object Request Broker (ORB) is used to send requests between different applications.
  • CORBA defines the conventions and protocols that are followed by CORBA implementations. Vendors and software developers translate the specification into a working implementation. As a result of its general applicability, the CORBA specification has been created for many different operating systems, including the popular C++ and Java applications . Any CORBA implementation usually matches the defined interfaces and defined protocols, allowing it to communicate with other CORBA implementations .
  • CORBA applications use objects that reside on different computers used throughout a distributed computing environment. These objects perform duties defined by their implementation. Objects act as servers in the system and can move as required. The client communicates to an object via an object reference, which acts as a pointer to the object to allow requests for operations and data access to be sent from the client to the server via the Object Request Broker (ORB) . Every object on an ORB has a code written to perform tasks on a server machine, thus doing the object work. This code can be in any language and can perform tasks supported by an operating system and hardware. A request reaches an ORB and is passed to a Portable Object Adapter (POA), forming a link between the object's implementation and its presence on the ORB.
  • POA Portable Object Adapter
  • the Portable Object Adapter informs the ORB that any requests for the new object reference are routed to it.
  • a client can receive an object reference using Interoperable Object References (IOR) and a naming service. Every object on an ORB includes an IOR that acts as a global identifier string to identify the machine in which the associated object is located and the interface the particular object supports.
  • IOR Interoperable Object References
  • Every object on an ORB includes an IOR that acts as a global identifier string to identify the machine in which the associated object is located and the interface the particular object supports.
  • a client can receive a reference to an object via the naming service.
  • FIG. 1 shows a prior art, standard ORB 10 and object adapters 12.
  • the client 14 has an object reference 16 generated from a server's IOR.
  • the object adapter 12 is operable with the implementation 18 and connects to the object reference 16 of the ORB. It is operable with the client and Interoperable Client Reference 20.
  • IDL Interface Definition Language
  • a CORBA implementation usually comes with one or more IDL compilers that are operable with stub and skeleton files, which are language and ORB-dependent .
  • the IDL file generates stubs and skeletons for each language and ORB implementation.
  • Stubs are generated by a compiler and used in client processes to communicate with a server.
  • Skeleton files are the converse of stubs, and receive requests from an ORB, call a proper implementation, and return results.
  • the Dynamic Invocation Interface defines the functions for creating request messages and delivering them to server objects.
  • the Internet Inter-ORB Protocol is a simplified RPC protocol that invokes server objects via the internet.
  • a CORBA Interface Repository can be formed as a database containing type information for interfaces available in a CORBA system architecture.
  • the present invention also uses a Simple Object Access Protocol (SOAP) upstream interface and downstream interface with an Internet Inter-ORB Protocol (HOP) callback over the SOAP.
  • SOAP is often used in current worldwide web development and its most common form is an Apache implementation, as known to those skilled in the art.
  • SOAP is a protocol useful in distributed architecture that allows information exchange over HTTP (Hypertext Transfer Protocol) , which is the standard method of publishing information as hypertext in HTMP (Hypertext Markup Language) format on the internet.
  • HTTP Hypertext Transfer Protocol
  • HTMP Hypertext Markup Language
  • the SOAP specification includes three components: (1) a SOAP envelope; (2) a set of encoding rules; and (3) a means of interaction between a request and response. These three components allow error handling, support for encodings, serialization of custom parameters via a serializer, and HTTP use to make it advantageous as a distributed protocol.
  • the SOAP envelope provides information about the message that is being encoded in a SOAP payload, including data about the receiver and sender, and details about the message.
  • the header of a SOAP envelope can specify how a message is to be processed. This is different from a standard XML-RPC call, where the messages and coding are wrapped in a single XML fragment.
  • SOAP also allows the encoding of user-defined data types. In an RPC and XML-RPC call, encoding only occurs for a predefined set of data types. In SOAP, on the other hand, XML schemes are used to specify new data types that can be represented in XML as part of a SOAP payload.
  • any data type can be encoded in a SOAP message that could logically be described in an XML scheme using the Extensible Markup Language, allowing HTML to be interoperable on the worldwide web.
  • SOAP a call object is resonant in memory and set with the method to invoke the encoding style and parameters .
  • Various parameters can be set and can provide fault responses.
  • a SOAP API can communicate with the server and receive SOAP messages. It is also possible to run a SOAP server, which can receive messages from a SOAP client. It is possible to use SOAP-RPC or SOAP messaging. Referring now to FIG.
  • FIG. 3 there is illustrated in block diagram the dynamic CORBA gateway system 50 of the present invention, showing in detail various components of the dynamic CORBA gateway that creates and maintains references to virtual CORBA services, where the service can be addressed by a set of Hypertext Transfer Protocol (HTTP) Uniform Resource Locators (URL's) and exposed to the CORBA system as a monolithic CORBA service.
  • HTTP Hypertext Transfer Protocol
  • URL's Uniform Resource Locators
  • the various elements include the ordinary CORBA client 52 and ordinary CORBA server 54 that communicate with each other through a standard CORBA interface 56.
  • a Dynamic Client Business Logic function 58 includes software logic with scripting to form an interactive script. This can be developed by techniques known to those skilled in the art.
  • the Virtual CORBA Service Object (VCSO) 64 is similar to a Portable Object Adapter, and thus, separates the CORBA, but allows implementation using different languages. It communicates through the SOAP protocol to the SOAP downstream interface 62 to expose pluggable dynamic modules for service implementation 66 as CORBA objects. Thus, non- CORBA services are exposed to the CORBA objects.
  • VCSO Virtual CORBA Service Object
  • FIG. 4 Another high level block diagram of the dynamic CORBA gateway is shown in FIG. 4, showing a dynamic CORBA adapter 70, which includes the CORBA gateway 72 having the Virtual CORBA Service Object 64, operable with CORBA clients 52 and business logic/protocol adapters 74 that are written under the scripting languages and communicating with the non- CORBA services 76, which could be devices or web services.
  • a dynamic CORBA adapter 70 which includes the CORBA gateway 72 having the Virtual CORBA Service Object 64, operable with CORBA clients 52 and business logic/protocol adapters 74 that are written under the scripting languages and communicating with the non- CORBA services 76, which could be devices or web services.
  • Having the gateway in the middle allows the system to separate clients and servers business logic from the CORBA communication mechanism.
  • complex CORBA IDL processing and binding to the particular ORB is not necessary.
  • the generic SOAP to CORBA encoding/decoding can be developed by techniques known to those skilled in the art and allows
  • CORBA clients 52 are accessing the "virtual services" as normal CORBA servers, parsing an IOR, and talking to the CORBA objects residing on the gateway.
  • the gateway performs translations of the IDL method calls to SOAP messages and sends them to the specified method implementation HTTP URL.
  • the gateway also provides the access to remote CORBA services over the web. This allows the clients to be written on any programming and scripting language that can operate with strings and implement the HTTP client and servers.
  • the gateway technology of the present invention allows the implementation of the callback mechanism when the CORBA object may be created on the client side and passed along the CORBA method call (over SOAP) . It may be called back later by the remote CORBA server which gives the possibility of creation of a complete client.
  • This given approach to the dynamic CORBA interface implementation provides the architecture for generic CORBA/non-CORBA services.
  • the adapter as described is one of the several beneficial elements introduced by the present invention.
  • the architecture of the present invention uses a CORBA gateway in a dynamic CORBA interface implementation.
  • This approach allows the complete separation of business logic both for CORBA clients and servers from the CORBA communication infrastructure exposing or accessing CORBA services using SOAP over HTTP. No use of CORBA specific code and procedures is necessary to provide services through CORBA or use services exposed through CORBA. This also allows implementation of the client callback mechanism, which is not implemented by existing CORBA to SOAP systems.
  • the dynamic CORBA scripting system of the present invention allows the scriptable CORBA services to be implemented using SOAP over HTTP. Every CORBA service exposed through the dynamic gateway and described by the particular IDL has the corresponding HTTP URL pointing to the location where the business implementation of the service resides. This approach allows a separate URL to be specified for every IDL method, which distributes the service among many platforms at the same time and providing the one point of service access through a Virtual CORBA Service Object 64, as shown in FIG. 1.
  • the present invention also allows the programming of client and servers business procedures using any scripting or programming language (including CGI scripts, servlets and Java server pages), which can operate with strings and support creation of HTTP clients and servers .
  • any scripting or programming language including CGI scripts, servlets and Java server pages
  • the present invention also provides a generic implementation for the CORBA/non-CORBA services generic adapter architecture, which allows CORBA clients to access different non-CORBA services.
  • this architecture can provide access of distributed web services to the CORBA clients (the problem described earlier) .
  • the generic CORBA adapter uses the CORBA gateway, maintaining the Virtual CORBA Service Objects (VCSO) and the CORBA independent pluggable modules to provide the business information preprocessing, and forwarding requests to different non-CORBA services.
  • VCSO Virtual CORBA Service Objects
  • This approach hides the actual location and nature (implementation) of the particular services from the CORBA system elements, as shown in FIG. 4.
  • Another advantageous result of the dynamic CORBA interface implementation of the present invention is generic SOAP/CORBA encoding/decoding protocol.
  • the encoding/decoding of the data objects, which are passed and returned along the CORBA calls, is performed by serializing of the CORBA NV list data type to SOAP messages. This method works with any possible complex data and dynamic introduction of new IDL data types without modifications of the gateway code and the code of the existing business modules.
  • the object request broker (ORB) 100 includes the Internet Inter-ORB Protocol (HOP) objects 102, a CORBA Message Listener 104 and Java objects 106 as part of the interface (IFR) 108 of the ORB 100.
  • HOP Internet Inter-ORB Protocol
  • CORBA Message Listener 104 Java objects 106 as part of the interface (IFR) 108 of the ORB 100.
  • the Implementation Objects Pool 118 calls the SOAP client 136 and sends a request to a non- CORBA service.
  • the SOAP Server 132 calls the CORBA Object Manager 112 to call CORBA objects.
  • the CORBA Message Listener 104 calls the Servant Objects 120.
  • the SOAP Server 132 calls the CORBA Object Manager 112 and Java Object Database 114.
  • the CORBA Object Manager 112 calls the SOAP Server 132.
  • FIG. 6 illustrates a high level collaboration block diagram and points out the different calls and interaction among objects.
  • a non-CORBA client 200 is illustrated as operative with a non-CORBA service 202 to communicate with the CORBA application 204.
  • the Gateway Servlet 206 is operative with the SOAP Gateway 208 and SOAP Serializer 210.
  • the CORBA Object Manager 212 is operative with the Java Object Database 214.
  • the SOAP client 216 is operative with the Java Object Database 214 and the
  • the collaboration example set forth in FIG. 6 is illustrated with sequential numbers for functional flow and described briefly.
  • the non-CORBA client 200 can call the
  • the CORBA Object Manager 212 is operative with the Java Object Database 214 to store the object reference and return an object ID through the SOAP Gateway 208.
  • a data object is created and a data object added.
  • An object is created and an object ID returned through the SOAP Gateway 208.
  • the object attributes can be set and sent through the SOAP Gateway 208 to the Java Object Database 214.
  • the Gateway Servlet 206 calls a CORBA object and the SOAP Gateway 208 allows the object to be obtained.
  • Object references are returned via the Java Object Database 214.
  • a name value list (NV List) is decoded and encoded through the SOAP Serializer 210 and SOAP Gateway 208.
  • An object call is made by the CORBA Object Manager 212 back through the SOAP Gateway 208.
  • Object data is obtained through the SOAP Gateway 208 and returned.
  • a server object can be created via the Non-CORBA Service 202 and the Gateway Servlet 206 and operative with the CORBA Object Manager 212. Server objects are created and later objects are deleted via the Java Object Database 214.

Abstract

A dynamic CORBA gateway allows CORBA services (54) to be exposed to non-CORBA clients and non-CORBA services to be exposed to CORBA clients (52) over a Simple Object Access Protocol (SOAP) with a SOAP upstream (60) and downstream (62) interface and Virtual CORBA Service Object (64).

Description

DYNAMIC CORBA GATEWAY FOR CORBA AND NON-CORBA CLIENTS AND SERVICES
Field of the Invention
This invention relates to the field of distributed object computing in a client-server environment, and more particularly, this invention relates to a Common Object Request Broker Architecture (CORBA) used in distributed object computing.
Background of the Invention
The increase in the number of communication industries, internet technologies, and worldwide web (WWW) users has resulted in a large number of programs using Object Oriented Programming (OOP) techniques. This type of programming is applicable to client-server computing using a distributed computing model where client applications request services from a server. The client applications and server processes typically operate on different computers interconnected to each other via a network, such as the internet. As is well known, the client application sends messages to the server via the network, while the server or program listens for client requests that are transmitted back via the network. The servers receive requests and perform actions .
In distributed object computing and object- oriented programming, objects are pieces of software that encapsulate an internal state and make it accessible through an interface, including object operations and attributes that are remotely accessible. A naming service can be used to connect portions of the interface. Clients, in turn, invoke operations on the remote object, which acts as a server. Objects belong to classes that are incrementally modified through inheritance. Examples of well-known object-oriented languages using these types of objects include Java or C++. The objects are collections of operations that share a state, where the operations determine the messages (or calls) to which the object can respond. This shared state is hidden from the outside world and only accessible to the objects operations.
One key aspect of object oriented programming is the reuse of programming effort by the reuse of sub-classes. Physical resources can have components that can be modeled in an object oriented manner and this programming effort can be re-used. Different programs, such as Java or C++, enable direct reuse of classes, but usually only if the same language can be bound or linked together. With the rise of the internet and larger communications networks, control and data processing functions are distributed among many geographically spaced computers at different locations making control over interfacing and communication among the different physical devices problematic.
Internet applications are becoming increasingly more difficult to communicate with each other because different machines with one architecture and code must communicate with other machines that are built around different architectures and codes. In response to this problem, the Object Management Group (OMG) has developed the Common Object Request Broker Architecture (CORBA) specification, which is a protocol for interprocess communication in a heterogenous environment. This infrastructure allows objects to converse independent of specific platforms and techniques used to implement the objects. As a result, there is interoperability between objects and those built-in, different languages that operate on different machines in a heterogenous distributed environment.
The CORBA architecture uses an Interface Definition Language (IDL) , which is a declarative language similar to C++. It includes interfaces that are similar to classes of interface inheritance with input and output arguments and data types that are passed along with an operation. The Interface Definition Language declares remotely accessible server objects in a platform in programming language-neutral manner without implementation. The CORBA architecture also includes an Object Request Broker (ORB) , which allows a client to communicate to an object through an object reference that acts as a pointer. The Object Request Broker finds a server object for a client request and prepares the object to receive the request, transmit the request from the client to the server object, and return output arguments back to the client application. Thus, an Object Request Broker provides an object-oriented Request Procedure Call (RPC) facility. Other elements of the CORBA architecture include a
Portable Object Adaptor (POA) , Dynamic Invocation Interface (DII) , Internet Inter-ORB Protocol (HOP) , and an Interface and Implementation Repository, as known to those skilled in the art. One of the drawbacks of most CORBA architectures is that once the definition of the interface application provides or uses has changed, it should be rebuilt in order to work with the new interface even if the dynamic invocation is used. Opposite to programming languages, such as C++ and Java, usually used to build CORBA clients and servers, use of scripting language does not require extra compilation steps.
The changes made to interfaces obtain instant support by script ( s ) modification .
There are some prior art CORBA gateways that approach this problem. Some scriptable interface specifications are supported by the Object Management Group. For example, one CORBA script language implementation allows CORBA applications (or services) to be revealed to a non- CORBA client. This type of CORBA universal gateway has been used before and is not tied to a particular scripting language. The CORBA object is serialized to HTML or a Simple Object Access Protocol (SOAP) and published. There are also several implementations of Extensible Markup Language (XML) to CORBA bridges. These capabilities, however, are more restrictive and are not used for dynamic CORA systems implementation.
It is desirable, however, that a more sophisticated CORBA gateway system would allow a server and scripting language to be implemented such that a CORBA client can accept this server from the non-CORBA device or program.
Summary of the Invention
The present invention is advantageous and allows a service that is not specified through a Common Object Request Broker Architecture (CORBA) to be exposed to a client that is CORBA specified. A SOAP request can be prepared by interactive scripting as part of a client's business logic function that is operable via a SOAP interface. References can be created and maintained to virtual CORBA services via a virtual CORBA service object. The virtual CORBA services can be addressed by a set of HTTP Uniform Resource Locators (URL's) . The references can be exposed as a monolithic CORBA service. The CORBA name value list data types can be serialized SOAP messages. An Internet Inter-ORB Protocol (HOP) callback can be generated using a Simple Object Access Protocol (SOAP) message.
In yet another aspect of the present invention, Interface Definition Language (IDL) method calls can be translated to the SOAP messages. A specified method implementation HTTP uniform resource locator can also be transmitted via a virtual CORBA service object that forms a CORBA gateway. Brief Description of the Drawings
Other objects, features and advantages of the present invention will become apparent from the detailed description of the invention which follows, when considered in light of the accompanying drawings in which:
FIG. 1 is a high level block diagram showing a standard Object Request Broker (ORB) .
FIG. 2 is another high level block diagram illustrating a standard CORBA infrastructure implemented in a communications network.
FIG. 3 is a high level block diagram of the dynamic CORBA gateway of the present invention, which creates and maintains references to virtual CORBA services that can be addressed by a set of HTTP Uniform Resource Locators (URL's) and exposed to the CORBA system as a monolithic CORBA service .
FIG. 4 is another high level block diagram of the dynamic CORBA gateway of the present invention and showing intercommunication among the CORBA clients and non-CORBA services.
FIG. 5 is a high level block diagram showing various components of the dynamic CORBA gateway and system of the present invention.
FIG. 6 is another block flow diagram showing collaboration among non-CORBA clients, non-CORBA services and CORBA applications as an example of the present invention.
Detailed Description of the Preferred Embodiments
The present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.
The present invention advantageously provides a dynamic CORBA gateway that allows a CORBA service to be exposed to a non-CORBA client, and a non-CORBA service to be exposed to a CORBA client. An Internet Inter-ORB Protocol (HOP) callback occurs using a Simple Object Access Protocol (SOAP) message. A Dynamic Client Business Logic function has a script that prepares a SOAP request and is operable with a SOAP upstream interface, a SOAP downstream interface, and a Virtual CORBA Service Object (VCSO) . Pluggable dynamic modules for service implementation are operable with the SOAP downstream interface using the Simple Object Access Protocol.
For purposes of background, a brief description of a CORBA architecture and Simple Object Access Protocol (SOAP) is first described followed by a detailed description of the present invention. It is well known that the CORBA architecture includes a series of standards and protocols to allow interprocess communication in a heterogenous environment of a large communications network such as the internet, enterprise, or similar networks. Applications can be written easily for many different operating systems at once in different languages using CORBA, thus, making CORBA one of the more popular interprocess communication techniques. It was developed as part of the Object Management Group (OMG) . In CORBA, an Object Request Broker (ORB) is used to send requests between different applications. As is known to those skilled in the art, the CORBA specification defines the conventions and protocols that are followed by CORBA implementations. Vendors and software developers translate the specification into a working implementation. As a result of its general applicability, the CORBA specification has been created for many different operating systems, including the popular C++ and Java applications . Any CORBA implementation usually matches the defined interfaces and defined protocols, allowing it to communicate with other CORBA implementations .
As noted before, CORBA applications use objects that reside on different computers used throughout a distributed computing environment. These objects perform duties defined by their implementation. Objects act as servers in the system and can move as required. The client communicates to an object via an object reference, which acts as a pointer to the object to allow requests for operations and data access to be sent from the client to the server via the Object Request Broker (ORB) . Every object on an ORB has a code written to perform tasks on a server machine, thus doing the object work. This code can be in any language and can perform tasks supported by an operating system and hardware. A request reaches an ORB and is passed to a Portable Object Adapter (POA), forming a link between the object's implementation and its presence on the ORB. The Portable Object Adapter informs the ORB that any requests for the new object reference are routed to it. A client can receive an object reference using Interoperable Object References (IOR) and a naming service. Every object on an ORB includes an IOR that acts as a global identifier string to identify the machine in which the associated object is located and the interface the particular object supports. A client can receive a reference to an object via the naming service. FIG. 1 shows a prior art, standard ORB 10 and object adapters 12. The client 14 has an object reference 16 generated from a server's IOR. Thus, the object adapter 12 is operable with the implementation 18 and connects to the object reference 16 of the ORB. It is operable with the client and Interoperable Client Reference 20. Always associated with the CORBA architecture is the Interface Definition Language (IDL) , which defines the public interfaces to various objects in the system, while also allowing definition of core data types. A CORBA implementation usually comes with one or more IDL compilers that are operable with stub and skeleton files, which are language and ORB-dependent . The IDL file generates stubs and skeletons for each language and ORB implementation. Stubs are generated by a compiler and used in client processes to communicate with a server. Skeleton files, on the other hand, are the converse of stubs, and receive requests from an ORB, call a proper implementation, and return results.
FIG. 2 shows a CORBA system architecture with a first and second device 22, 24 and a client 26 that is operable with the stub file 28 and ORB 30, and uses an Internet Inter-ORB Protocol (HOP) message to define a transport layer for sending messages as part of the general inter-ORB protocol over TCP/IP to the second device 24. It also includes an ORB 32, object adapter 34, skeleton files 36, and implementation 38. The HOP maps messages to TCP/IP messages. As part of the object adapter 34, operations are exported to create object references to register and activate server objects and authenticate requests. A server can install a reference in a name server such that a client can retrieve the reference and invoke the server. The Dynamic Invocation Interface defines the functions for creating request messages and delivering them to server objects. The Internet Inter-ORB Protocol is a simplified RPC protocol that invokes server objects via the internet. A CORBA Interface Repository can be formed as a database containing type information for interfaces available in a CORBA system architecture.
The present invention also uses a Simple Object Access Protocol (SOAP) upstream interface and downstream interface with an Internet Inter-ORB Protocol (HOP) callback over the SOAP. SOAP is often used in current worldwide web development and its most common form is an Apache implementation, as known to those skilled in the art. SOAP is a protocol useful in distributed architecture that allows information exchange over HTTP (Hypertext Transfer Protocol) , which is the standard method of publishing information as hypertext in HTMP (Hypertext Markup Language) format on the internet. SOAP is advantageous when different firewalls are encountered. Also, it is typically not necessary when using SOAP to have sockets listening on different ports. As known to those skilled in the art, the SOAP specification includes three components: (1) a SOAP envelope; (2) a set of encoding rules; and (3) a means of interaction between a request and response. These three components allow error handling, support for encodings, serialization of custom parameters via a serializer, and HTTP use to make it advantageous as a distributed protocol.
The SOAP envelope provides information about the message that is being encoded in a SOAP payload, including data about the receiver and sender, and details about the message. The header of a SOAP envelope can specify how a message is to be processed. This is different from a standard XML-RPC call, where the messages and coding are wrapped in a single XML fragment. SOAP also allows the encoding of user-defined data types. In an RPC and XML-RPC call, encoding only occurs for a predefined set of data types. In SOAP, on the other hand, XML schemes are used to specify new data types that can be represented in XML as part of a SOAP payload. Thus, any data type can be encoded in a SOAP message that could logically be described in an XML scheme using the Extensible Markup Language, allowing HTML to be interoperable on the worldwide web. In SOAP, a call object is resonant in memory and set with the method to invoke the encoding style and parameters . Various parameters can be set and can provide fault responses. A SOAP API can communicate with the server and receive SOAP messages. It is also possible to run a SOAP server, which can receive messages from a SOAP client. It is possible to use SOAP-RPC or SOAP messaging. Referring now to FIG. 3, there is illustrated in block diagram the dynamic CORBA gateway system 50 of the present invention, showing in detail various components of the dynamic CORBA gateway that creates and maintains references to virtual CORBA services, where the service can be addressed by a set of Hypertext Transfer Protocol (HTTP) Uniform Resource Locators (URL's) and exposed to the CORBA system as a monolithic CORBA service. The various elements include the ordinary CORBA client 52 and ordinary CORBA server 54 that communicate with each other through a standard CORBA interface 56. A Dynamic Client Business Logic function 58 includes software logic with scripting to form an interactive script. This can be developed by techniques known to those skilled in the art. It communicates using the Simple Object Access Protocol (SOAP) via a SOAP upstream interface 60 that is operable with the CORBA interface 56. A SOAP downstream interface 62 is also operable with the CORBA interface. The Dynamic Client Business Logic function 58 includes the scripting that prepares the SOAP request as a simple text message in an XML language, and sends it over the dynamic CORBA gateway to the ordinary CORBA server 54. This client may implement the CORBA objects which can be an HOP callback over SOAP, and thus, called by the CORBA server as if they were CORBA implemented. A CORBA object makes the CORBA call transfers to SOAP call, and the client is called using the SOAP protocol to expose the CORBA to a non-CORBA client. The Virtual CORBA Service Object (VCSO) 64 is similar to a Portable Object Adapter, and thus, separates the CORBA, but allows implementation using different languages. It communicates through the SOAP protocol to the SOAP downstream interface 62 to expose pluggable dynamic modules for service implementation 66 as CORBA objects. Thus, non- CORBA services are exposed to the CORBA objects.
Another high level block diagram of the dynamic CORBA gateway is shown in FIG. 4, showing a dynamic CORBA adapter 70, which includes the CORBA gateway 72 having the Virtual CORBA Service Object 64, operable with CORBA clients 52 and business logic/protocol adapters 74 that are written under the scripting languages and communicating with the non- CORBA services 76, which could be devices or web services. Having the gateway in the middle allows the system to separate clients and servers business logic from the CORBA communication mechanism. As a result, complex CORBA IDL processing and binding to the particular ORB is not necessary. The generic SOAP to CORBA encoding/decoding can be developed by techniques known to those skilled in the art and allows the introduction of new complex data types without modification of already deployed services.
CORBA clients 52 are accessing the "virtual services" as normal CORBA servers, parsing an IOR, and talking to the CORBA objects residing on the gateway. The gateway performs translations of the IDL method calls to SOAP messages and sends them to the specified method implementation HTTP URL.
The gateway also provides the access to remote CORBA services over the web. This allows the clients to be written on any programming and scripting language that can operate with strings and implement the HTTP client and servers. Opposite to all existing implementations, the gateway technology of the present invention allows the implementation of the callback mechanism when the CORBA object may be created on the client side and passed along the CORBA method call (over SOAP) . It may be called back later by the remote CORBA server which gives the possibility of creation of a complete client. This given approach to the dynamic CORBA interface implementation provides the architecture for generic CORBA/non-CORBA services. The adapter as described is one of the several beneficial elements introduced by the present invention.
The architecture of the present invention uses a CORBA gateway in a dynamic CORBA interface implementation. This approach allows the complete separation of business logic both for CORBA clients and servers from the CORBA communication infrastructure exposing or accessing CORBA services using SOAP over HTTP. No use of CORBA specific code and procedures is necessary to provide services through CORBA or use services exposed through CORBA. This also allows implementation of the client callback mechanism, which is not implemented by existing CORBA to SOAP systems.
The dynamic CORBA scripting system of the present invention allows the scriptable CORBA services to be implemented using SOAP over HTTP. Every CORBA service exposed through the dynamic gateway and described by the particular IDL has the corresponding HTTP URL pointing to the location where the business implementation of the service resides. This approach allows a separate URL to be specified for every IDL method, which distributes the service among many platforms at the same time and providing the one point of service access through a Virtual CORBA Service Object 64, as shown in FIG. 1.
The present invention also allows the programming of client and servers business procedures using any scripting or programming language (including CGI scripts, servlets and Java server pages), which can operate with strings and support creation of HTTP clients and servers .
The present invention also provides a generic implementation for the CORBA/non-CORBA services generic adapter architecture, which allows CORBA clients to access different non-CORBA services. For example, this architecture can provide access of distributed web services to the CORBA clients (the problem described earlier) . The generic CORBA adapter uses the CORBA gateway, maintaining the Virtual CORBA Service Objects (VCSO) and the CORBA independent pluggable modules to provide the business information preprocessing, and forwarding requests to different non-CORBA services. This approach hides the actual location and nature (implementation) of the particular services from the CORBA system elements, as shown in FIG. 4. Another advantageous result of the dynamic CORBA interface implementation of the present invention is generic SOAP/CORBA encoding/decoding protocol. The encoding/decoding of the data objects, which are passed and returned along the CORBA calls, is performed by serializing of the CORBA NV list data type to SOAP messages. This method works with any possible complex data and dynamic introduction of new IDL data types without modifications of the gateway code and the code of the existing business modules.
Referring now to FIG. 5, there is illustrated a block diagram showing different components of the system architecture of the present invention that forms the dynamic CORBA gateway. Different calls and uses between the components are illustrated by the dashed lines. The object request broker (ORB) 100 includes the Internet Inter-ORB Protocol (HOP) objects 102, a CORBA Message Listener 104 and Java objects 106 as part of the interface (IFR) 108 of the ORB 100.
The object manager 110 of the present invention separates the CORBA object manager 112 from the Java object database 114 having Java objects 116. An Implementation Objects Pool 118 includes generic Servant Objects 120 and communicates with the ORB 100. As known to those skilled in the art, the ORB 100 locates the servant object 120 for a client request and provides an object oriented RPC facility. The Simple Object Access Protocol function 130 includes a SOAP server 132, Serializers 134, a SOAP Client 136 and a Servlet 138. This Serializer 134 can be a generic serializer and convert any CORBA data type to a SOAP stream without modification of the code. The Implementation Objects Pool 118 calls the SOAP client 136 and sends a request to a non- CORBA service. The SOAP Server 132 calls the CORBA Object Manager 112 to call CORBA objects. The CORBA Message Listener 104 calls the Servant Objects 120. The SOAP Server 132 calls the CORBA Object Manager 112 and Java Object Database 114. The CORBA Object Manager 112 calls the SOAP Server 132.
FIG. 6 illustrates a high level collaboration block diagram and points out the different calls and interaction among objects. As illustrated, a non-CORBA client 200 is illustrated as operative with a non-CORBA service 202 to communicate with the CORBA application 204. The Gateway Servlet 206 is operative with the SOAP Gateway 208 and SOAP Serializer 210. The CORBA Object Manager 212 is operative with the Java Object Database 214. The SOAP client 216 is operative with the Java Object Database 214 and the
Implementation Object for the Servant 218, which in turn, is operative with the Portable Object Adapter (POA) 220.
The collaboration example set forth in FIG. 6 is illustrated with sequential numbers for functional flow and described briefly. The non-CORBA client 200 can call the
CORBA object through the Gateway Servlet 206 and SOAP Gateway 208 and an object is created. The CORBA Object Manager 212 is operative with the Java Object Database 214 to store the object reference and return an object ID through the SOAP Gateway 208. A data object is created and a data object added. An object is created and an object ID returned through the SOAP Gateway 208. The object attributes can be set and sent through the SOAP Gateway 208 to the Java Object Database 214. The Gateway Servlet 206 calls a CORBA object and the SOAP Gateway 208 allows the object to be obtained. Object references are returned via the Java Object Database 214. A name value list (NV List) is decoded and encoded through the SOAP Serializer 210 and SOAP Gateway 208. An object call is made by the CORBA Object Manager 212 back through the SOAP Gateway 208.
The POA 220 is operative with the Implementation Object 218 and an HOP call is made with the result returned.
Object data is obtained through the SOAP Gateway 208 and returned. A server object can be created via the Non-CORBA Service 202 and the Gateway Servlet 206 and operative with the CORBA Object Manager 212. Server objects are created and later objects are deleted via the Java Object Database 214.
In another aspect of the invention, the SOAP client 200 is operative with the Java Object Database 214 to store object data and return object data via associated components. The SOAP client 200 makes a call to the Non-CORBA Service 202 and at the same time, the SOAP client 200 is operative with the SOAP Serializer 210 to encode the name value list and decode the name value list. Object data is put via the Non-CORBA Service 202 to the Gateway Servlet 206 and object data returned. Object ID is transferred from the
Non-CORBA Service to the Non-CORBA Client and object data returned. Results are returned and a return value obtained.
It is evident from the present invention that not only are CORBA services exposed to non-CORBA clients, but also non-CORBA services are exposed to CORBA clients using the dynamic CORBA gateway.
Many modifications and other embodiments of the invention will come to the mind of one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed, and that the modifications and embodiments are intended to be included within the scope of the dependent claims.

Claims

THAT WHICH IS CLAIMED IS:
1. A method of communicating within a distributed object oriented computing system comprising the step of: exposing a service that is not specified through a
Common Object Request Broker Architecture (CORBA) to a client that is CORBA specified using a Simple Object Access Protocol (SOAP) message.
2. A method according to Claim 1, and further comprising the step of preparing a SOAP request by interactive scripting as part of a client business logic function and operable via a SOAP interface.
3. A method according to Claim 1, and further comprising the step of creating and maintaining references to virtual CORBA services via a Virtual CORBA Service Object.
4. A method according to Claim 3, and further comprising the step of addressing the Virtual CORBA services by a set of HTTP Uniform Resource Locators (URL's).
5. A method according to Claim 4, wherein the references can be exposed as a monolithic CORBA service.
6. A method according to Claim 1, and further comprising the step of serializing CORBA Name Value list data types to SOAP messages.
7. A method of communicating within a distributed object oriented computing system comprising the steps of: exposing a service that is not specified through a Common Object Request Broker Architecture (CORBA) to a client that is CORBA specified using a Simple Object Access Protocol (SOAP) message; and implementing Internet Inter-ORB Protocol (HOP) callbacks using Simple Object Access Protocol (SOAP) .
8. A method according to Claim 7, and further comprising the step of preparing a SOAP request from interactive scripting as part of a client business logic function and operable via a SOAP interface.
9. A method according to Claim 7, and further comprising the step of creating and maintaining references to virtual CORBA services via a Virtual CORBA Service Object.
10. A method according to Claim 9, and further comprising the step of addressing the Virtual CORBA services by a set of HTTP Uniform Resource Locators (URL's) .
11. A method according to Claim 10, wherein the references can be exposed as a monolithic CORBA service.
12. A method according to Claim 7, and further comprising the step of serializing CORBA Name Value list data types to SOAP messages.
13. A method of communicating within a distributed object oriented computing system comprising the step of: exposing a service that is not specified through a Common Object Request Broker Architecture (CORBA) to a client that is CORBA specified using a Simple Object Access Protocol (SOAP) message; translating Interface Definition Language (IDL) method calls to the SOAP messages; and transmitting to a specified method implementation HTTP Uniform Resource Locator (URL) via a Virtual CORBA Service Object that forms a CORBA gateway having virtual CORBA services.
14. A method according to Claim 13, and further comprising the step of preparing a SOAP request by interactive scripting as part of a client business logic function and operable via a SOAP interface .
15. A method according to Claim 13, and further comprising the step of creating and maintaining references to virtual CORBA services via the Virtual CORBA Service Object.
16. A method according to Claim 15, and further comprising the step of addressing the Virtual CORBA services by a set of HTTP Uniform Resource Locators (URL's) .
17. A method according to Claim 16, wherein the references can be exposed as a monolithic CORBA service.
18. A method according to Claim 13, and further comprising the step of serializing CORBA Name Value list data types to SOAP messages.
19. A distributed object computing system comprising: a service that is not specified through a Common Object Request Broker Architecture (CORBA) ; a client that is CORBA specified; and a CORBA gateway having a Simple Object Access Protocol (SOAP) interface and Virtual CORBA Service Object through which the service that is not specified through CORBA is exposed to the client that is CORBA specified.
20. A distributed object computing system according to Claim 19, and further comprising a Dynamic Client Business Logic function operative with an Internet Inter-ORB Protocol (HOP) callback using a SOAP message.
21. A distributed object computing system according to Claim 19, wherein said Virtual CORBA Service Object is operative as a Portable Object Adapter.
22. A distributed object computing system according to Claim 19, and further comprising a serializer for serializing CORBA Name Value list data types to SOAP messages .
23. A distributed object computing system according to Claim 19, wherein said CORBA gateway is operative for translating Interface Definition Language method calls to SOAP messages.
PCT/US2002/032037 2001-10-11 2002-10-07 Dynamic corba gateway for corba and non-corba clients and services WO2003032117A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002330269A AU2002330269A1 (en) 2001-10-11 2002-10-07 Dynamic corba gateway for corba and non-corba clients and services

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/976,244 US6757899B2 (en) 2001-10-11 2001-10-11 Dynamic CORBA gateway for CORBA and non-CORBA clients and services
US09/976,244 2001-10-11

Publications (2)

Publication Number Publication Date
WO2003032117A2 true WO2003032117A2 (en) 2003-04-17
WO2003032117A3 WO2003032117A3 (en) 2003-11-06

Family

ID=25523911

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/032037 WO2003032117A2 (en) 2001-10-11 2002-10-07 Dynamic corba gateway for corba and non-corba clients and services

Country Status (3)

Country Link
US (1) US6757899B2 (en)
AU (1) AU2002330269A1 (en)
WO (1) WO2003032117A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11856150B2 (en) 2008-04-02 2023-12-26 Twilio Inc. System and method for processing telephony sessions

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7188158B1 (en) * 2000-07-15 2007-03-06 Hewlett-Packard Development Company, L.P. System and method for component-based software development
US7117239B1 (en) 2000-07-28 2006-10-03 Axeda Corporation Reporting the state of an apparatus to a remote computer
US8108543B2 (en) 2000-09-22 2012-01-31 Axeda Corporation Retrieving data from a server
US7185014B1 (en) 2000-09-22 2007-02-27 Axeda Corporation Retrieving data from a server
US20200143474A1 (en) * 2000-10-31 2020-05-07 Integral Development, Corporation System and method for conducting web-based financial transactions in capital markets
US8019807B2 (en) 2001-05-23 2011-09-13 Wireless Enterprise Solutions Technology Limited Method and system for communication between computer systems
EP1321853A3 (en) * 2001-12-10 2009-12-23 Sap Ag Dynamic component transfer based on resource negotiations between computer systems
US7254601B2 (en) 2001-12-20 2007-08-07 Questra Corporation Method and apparatus for managing intelligent assets in a distributed environment
US7921023B2 (en) * 2001-12-28 2011-04-05 Sap Aktiengesellschaft Portal for implementation of multiple software components
US7290267B2 (en) * 2002-01-23 2007-10-30 International Business Machines Corporation Multi-protocol object distribution
US7036110B2 (en) * 2002-03-21 2006-04-25 Sun Microsystems, Inc. Mechanism to manage the lifecycle of a resource adapter
US20030182426A1 (en) * 2002-03-21 2003-09-25 Sun Microsystems, Inc. Apparatus and method of lazy connection transaction enlistment
US7089317B2 (en) * 2002-03-21 2006-08-08 Sun Microsystems, Inc. Architecture for plugging messaging systems into an application server
US7058950B2 (en) * 2002-03-21 2006-06-06 Sun Microsystems, Inc. Callback event listener mechanism for resource adapter work executions performed by an application server thread
US7178149B2 (en) 2002-04-17 2007-02-13 Axeda Corporation XML scripting of soap commands
US7490334B2 (en) * 2002-04-25 2009-02-10 Sun Microsystems, Inc. Resource adapter with modular system management interface
AU2003239385A1 (en) 2002-05-10 2003-11-11 Richard R. Reisman Method and apparatus for browsing using multiple coordinated device
US7539998B1 (en) * 2002-06-06 2009-05-26 Vance Jay Klingman Mechanism for converting CORBA object requests to native XATMI service requests
US7376958B1 (en) * 2002-06-06 2008-05-20 Unisys Corporation Method and apparatus for honoring CORBA transaction requests by a legacy data base management system
US20030233477A1 (en) * 2002-06-17 2003-12-18 Microsoft Corporation Extensible infrastructure for manipulating messages communicated over a distributed network
US7353521B1 (en) 2002-10-19 2008-04-01 Borland Software Corporation Object oriented distributed software system with methodology for piggybacked reflective callbacks
US7966418B2 (en) 2003-02-21 2011-06-21 Axeda Corporation Establishing a virtual tunnel between two computer programs
US7331049B1 (en) 2003-04-21 2008-02-12 Borland Software Corporation System and methodology providing typed event and notification services
ATE304254T1 (en) * 2003-05-23 2005-09-15 Cit Alcatel METHOD AND SYSTEM FOR GENERATING A PROTOCOL-INDEPENDENT META-MODEL IN A NETWORK MANAGEMENT SYSTEM OF A TELECOMMUNICATIONS NETWORK
US20050022208A1 (en) * 2003-07-24 2005-01-27 Bolar Daniel Roy Corba gateway
US7293254B2 (en) * 2003-09-18 2007-11-06 Microsoft Corporation Extensibility application programming interface and framework for meta-model objects
US7953769B1 (en) * 2004-01-21 2011-05-31 Computer Associates Think, Inc. XML data packaging system and method
US7970801B1 (en) * 2004-01-21 2011-06-28 Computer Associates Think, Inc. Data packaging system and method
US7890604B2 (en) 2004-05-07 2011-02-15 Microsoft Corproation Client-side callbacks to server events
US9026578B2 (en) 2004-05-14 2015-05-05 Microsoft Corporation Systems and methods for persisting data between web pages
US7702724B1 (en) * 2004-05-27 2010-04-20 Oracle America, Inc. Web services message broker architecture
EP1617329A1 (en) * 2004-07-13 2006-01-18 Alcatel Method of generating services
US7483994B1 (en) 2004-11-01 2009-01-27 Ameriprise Financial, Inc. System and method for creating a standard envelope structure
US7668930B2 (en) * 2004-11-18 2010-02-23 International Business Machines Corporation Web service distribution system over the World Wide Web using web services description language (WSDL) standard including implementation for uniformly generating all fault conditions in WSDL message format
US7444346B2 (en) * 2005-05-27 2008-10-28 At&T Intellectual Property I.L.P. System and method for simple object access protocol access to interface definition language based services
US20070083524A1 (en) * 2005-10-07 2007-04-12 Fung Haley H L Apparatus, system, and method for implementing an IMS SOAP gateway to enable an IMS application to operate as a web service client
US7818294B2 (en) * 2005-10-07 2010-10-19 International Business Machines Corporation Apparatus, system, and method for implementing an IMS SOAP gateway
US7770146B2 (en) * 2006-05-19 2010-08-03 Sap Ag Computer software development incorporating core and compound services
US8370479B2 (en) 2006-10-03 2013-02-05 Axeda Acquisition Corporation System and method for dynamically grouping devices based on present device conditions
US8065397B2 (en) 2006-12-26 2011-11-22 Axeda Acquisition Corporation Managing configurations of distributed devices
US8478861B2 (en) * 2007-07-06 2013-07-02 Axeda Acquisition Corp. Managing distributed devices with limited connectivity
US8225337B2 (en) * 2008-08-29 2012-07-17 Red Hat, Inc. Application programming interface enhancement
US9804899B2 (en) * 2009-07-31 2017-10-31 Ixia Communications using the common object request broker architecture (CORBA)
US9489488B2 (en) * 2011-09-23 2016-11-08 Roche Diabetes Care, Inc. Protocol independent interface supporting general communications interface debugging and testing tool
US9619248B2 (en) * 2013-08-30 2017-04-11 Bluedata Software, Inc. Configuration manager and method for configuring a host system for processing a processing job in a virtual data-processing environment
US20150289000A1 (en) * 2014-04-04 2015-10-08 CSC Holdings, LLC Programmatic Buying and Selling of Television Advertising
US10771283B2 (en) * 2018-07-06 2020-09-08 Sap Se Virtual cloud node
US10652077B2 (en) * 2018-08-31 2020-05-12 Subcom, Llc Techniques for interfacing between web services and interface description language (IDL)-based remote procedure call (RPC) services and an optical communication system implementing same
CN113489723B (en) * 2021-07-05 2022-11-22 平安科技(深圳)有限公司 Data transmission method, system, computer device and storage medium

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5862328A (en) * 1995-09-15 1999-01-19 International Business Machines Corporation Bridge for a client-server environment
US6282580B1 (en) * 1996-07-02 2001-08-28 Sun Microsystems, Inc. Bridge providing communication between different implementations of object request brokers

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2142564T3 (en) 1996-08-20 2000-04-16 Cit Alcatel PROCEDURE FOR ADMINISTERING THE SPECIFICATION OF OBJECTS.
US6222533B1 (en) 1997-08-25 2001-04-24 I2 Technologies, Inc. System and process having a universal adapter framework and providing a global user interface and global messaging bus
US5974416A (en) 1997-11-10 1999-10-26 Microsoft Corporation Method of creating a tabular data stream for sending rows of data between client and server
US6192250B1 (en) 1997-12-05 2001-02-20 Lucent Technologies Inc. Cluster mobile switching center
GB2332288A (en) 1997-12-10 1999-06-16 Northern Telecom Ltd agent enabling technology
US6266695B1 (en) 1997-12-23 2001-07-24 Alcatel Usa Sourcing, L.P. Telecommunications switch management system
US6138110A (en) 1997-12-30 2000-10-24 Alcatel Usa Sourcing, L.P. Method and system for provisioning telecommunications services in an advanced intelligent network
US6061729A (en) 1997-12-31 2000-05-09 Alcatel Usa Sourcing, L.P. Method and system for communicating service information in an advanced intelligent network
US6012067A (en) 1998-03-02 2000-01-04 Sarkar; Shyam Sundar Method and apparatus for storing and manipulating objects in a plurality of relational data managers on the web
US6222916B1 (en) 1998-05-22 2001-04-24 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for introducing and modifying telecommunications services
US6229803B1 (en) 1998-08-05 2001-05-08 Sprint Communications Co. L.P. Telecommunications provider agent
US20010027439A1 (en) 1999-07-16 2001-10-04 Holtzman Henry N. Method and system for computerized form completion
JP3675292B2 (en) 2000-03-30 2005-07-27 日本電気株式会社 CORBA single restart method for embedded devices

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5862328A (en) * 1995-09-15 1999-01-19 International Business Machines Corporation Bridge for a client-server environment
US6282580B1 (en) * 1996-07-02 2001-08-28 Sun Microsystems, Inc. Bridge providing communication between different implementations of object request brokers

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FATOOHI R. ET AL.: 'Migration of DCE applications into CORBA and SOAP environments' SOFTWARE - PRACTICE AND EXPERIENCE March 2002, page 18, XP001141805 *
JEPSEN T.: 'SOAP cleans up interoperability problems on the web' IEEE January 2001, pages 52 - 55, XP002216700 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11856150B2 (en) 2008-04-02 2023-12-26 Twilio Inc. System and method for processing telephony sessions

Also Published As

Publication number Publication date
AU2002330269A1 (en) 2003-04-22
WO2003032117A3 (en) 2003-11-06
US20030074485A1 (en) 2003-04-17
US6757899B2 (en) 2004-06-29

Similar Documents

Publication Publication Date Title
US6757899B2 (en) Dynamic CORBA gateway for CORBA and non-CORBA clients and services
US6947965B2 (en) System and method for communications in a distributed computing environment
US6951021B1 (en) System and method for server-side communication support in a distributed computing environment
US6931455B1 (en) System and method for communications between a CORBA object request broker and a non-CORBA object request broker
US6629128B1 (en) System and method for distributed processing in a computer network
US6993774B1 (en) System and method for remote enabling classes without interfaces
US6938087B1 (en) Distributed universal communication module for facilitating delivery of network services to one or more devices communicating over multiple transport facilities
US6622175B1 (en) System and method for communications in a distributed processing environment
US7587447B2 (en) Systems, methods and computer programs for implementing and accessing web services
US7818294B2 (en) Apparatus, system, and method for implementing an IMS SOAP gateway
US20040045004A1 (en) System for runtime web service to java translation
US20040044656A1 (en) System for web service generation and brokering
US6804816B1 (en) Method and template for developing device-centric network management applications
US20070083524A1 (en) Apparatus, system, and method for implementing an IMS SOAP gateway to enable an IMS application to operate as a web service client
US20030233477A1 (en) Extensible infrastructure for manipulating messages communicated over a distributed network
EP1197859A1 (en) Method and device for remotely using a data-processing object in a communications network
JP2005174120A (en) Web service connection processing method, system, and program
JP2006195979A (en) Web application architecture
CN100512304C (en) Method for providing network service based on middleware platform
CN112988409B (en) Interface calling method and device, computer equipment and storage medium
Rees et al. A web of distributed objects
US7392060B2 (en) Mobile exchange infrastructure
Ayala et al. Open Source Web Services
Zou et al. Towards a Webcentric Legacy System Migration Framework
WO2003024054A2 (en) Inbound connector

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ OM PH PL PT RU SD SE SG SI SK SL TJ TM TN TR TZ UA UG UZ VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP