DISCOVERY AND INTEGRATION OF JINI SERVICES IN NON-JAVA CLIENTS
A system of forming a bridge between non Java services and a Jini (™) interface. A non Java service is encapsulated using special code which makes it look like a Java service. Other aspects are also automatically formed. The Java service is automatically published with a broker such as a Jini (™) broker.
This application is a continuation application of and claims priority to U.S. patent application Ser. No. 09/734,333, filed Nov. 30, 2000. The disclosure of the prior application is considered part of (and is incorporated by reference in) the disclosure of this application.
BACKGROUNDJini (™) is an established specification which allows application services to announce their availability dynamically. Users of services can dynamically find an application service using Jini. Examples can include services providing freight rates, stock quotes, price inventory levels for products or modules (e.g., calculators) for applications. Jini (™) operates by registering services, and responding to client inquiries about one of these services. Jini (™) also provides proxy code to the client allowing the client to communicate with the services. In this way, Jini (™) acts as a broker between the client and the existing services.
Jini (™) has been written in a way such that it can only be used by services written in Java. Many non-Java services (“legacy” services), however exist. These services cannot operate through Jini (™).
BRIEF DESCRIPTION OF THE DRAWINGSThese and other aspects will now be described in detail with reference to the accompanying drawings.
The present application defines a bridge between non Java services and a client which is requesting such services. More specifically, the bridge provides a code generator to generate a proxy code that wraps the non-Java object, and hence enables communication between the client and the service. A surrogate object publishes information about the service and proxy. The surrogate object maintains this information using the Jini (™) protocol. In this way, Jini (™) can be used in its normal way, but can used as a broker for non-Java services. Jini stores the code, by indexing the code directly, or by indexing proxy code.
The current Jini (™) interface will register services which have a Java Application Programming Interface (“API”). Services without a Java API cannot be registered with Jini (™). While the present application specifically describes using Jini (™), it should be understood that any service requiring a Java API could be similarly used.
The operation is shown in
A GUI (Graphical User Interface) allows a user to point and click the location of a service interface file representing the non-Java component, here an ActiveX component. For example, this may be an OCX file for an activeX component 100 as shown in
The bridge 110 operates as shown in the flowchart of
At 230, this system forms middle tier tunneling proxy code 140 to form a bridge between the client and the service. Other information obtained from introspection at 210 is used to generate search attributes. These form keywords which are used to supplement the keyword repository in Jini (™). In addition to the keywords identified by introspection, a user may also specify additional keywords in the Graphical User Interface (GUI).
Jini (™) stores the proxy objects and a set of search attribute objects shown as 152, 154, shown in
The Jini (™) service is shown as 150. A client, or a service-proxy for the client, makes a call to the backend service wrapper object. The wrapper object redirects the call to the actual Component Object Model (“COM”) or CORBA component. Each time such a call is made, the bridge 110 generates code that redirects the calls to the service 100. The generated code may be Java proxy code.
At 260, the bridge receives a Jini (™) lease object based on the successful registration of the Jini (™) object. The lease object shown as 142 keeps the object definition up-to-date. The bridge renews the lease from time to time, thereby insuring up-to-date information in Jini (™).
A service is published to Jini (™) in the following way. First, the service is serialized as a Java object, if it can be so serialized. Other, non Java compliant services are packaged as described above. Services which are incapable of being serialized into Jini (™) may publish their proxies instead. Constraints such as heaviness, native dependability, and the like may prevent the service from directly publishing to Jini (™). The proxy is a serializable lightweight Java object that acts as the service delegate. The proxies act as middle tiered objects allowing access of services on the back end. The object or proxy is sent to Jini (™), along with a set of search attributes. Once the Java objects have been transported to Jini (™), they are delivered to clients responsive to notifications of service matches.
Another aspect is to allow publishing either Jini or non Jini services. Any service that is capable of serialized in itself, and publishing itself to Jini (™), would do so directly. This enables clients to directly use the service objects.
Non Jini (™) services may not have a proxy, or such a proxy may need to be generated as part of the Jini (™) registration process.
Certain distributed application environments allow services to register with them through an identifier. One example is a GUID key for COM components.
As an example of operation,
Although only a few embodiments have been disclosed in detail above, other modifications are possible.
Claims
1. A system comprising:
- a collection of clients that receive services;
- a client/server broker configured to register application services that have a first application programming interface and identify the registered application services to the clients;
- a first application service that has the first application programming interface and is configured to publish an announcement of an availability of the first application service;
- a second application service that has a second application programming interface and is configured to publish an announcement of an availability of the second application service; and
- a bridge configured to wrap the announcement of the availability of the second application service in a wrapper that is compliant with the first application programming interface so that the client/server broker can register both the first application service and the second application service.
2. The system of claim 1, wherein the bridge comprises a proxy code generator and is configured to wrap the announcement of the availability of the second application service in the proxy code.
3. The system of claim 1, wherein the bridge is configured to inspect the second application service to identify functionality of the second application service and to identify the functionality to the client/server broker.
4. The system of claim 3, wherein the bridge is configured to inspect the second application service using dynamic inspection.
5. The system of claim 1, wherein the client/server broker is configured to identify functionality of the registered application services to the clients.
6. The system of claim 1, further comprising a memory associated with the client/server broker, wherein the memory includes information describing the registered application services.
7. The system of claim 6, wherein the information describing the registered application services comprises a keyword repository.
8. The system of claim 1, wherein:
- the client/server broker comprises a Jini™ interface;
- the first application programming interface comprises a Java™ application programming interface; and
- the second application programming interface comprises a non-Java™ application programming interface.
9. The system of claim 1, further comprising a third application service proxy that has the first application programming interface and is configured to publish an announcement of an availability of the first application service.
10. A method comprising:
- inspecting an application service;
- identifying that the application service has a functionality;
- forming proxy code describing the identified functionality; and
- forming a bridge between the application service and a client using the proxy code.
11. The method of claim 10, wherein forming the proxy code comprises middle tier tunneling proxy code.
12. The method of claim 10, wherein forming the proxy code comprises forming Java™ proxy code.
13. The method of claim 10, wherein forming the bridge between the application service and the client comprises registering the application service with a client/server broker.
14. The method of claim 13, wherein:
- the client/server broker is configured to register application services that have a first application programming interface; and
- registering the application service comprises wrapping an announcement of an availability of the application service in a wrapper that is compliant with the first application programming interface.
15. The method of claim 14, further comprising receiving a lease object from the client/server broker indicating that the application service has been registered.
16. The method of claim 14, wherein:
- the client/server broker comprises a Jini™ interface; and
- the first application programming interface comprises a Java™ application programming interface.
17. The method of claim 10, further comprising:
- generating a collection of search attributes based on results of inspecting the application service; and
- making the collection of search attributes available to the client/server broker.
18. The method of claim 10, wherein inspecting the application service comprises dynamically inspecting the application service.
19. The method of claim 10, wherein inspecting the application service comprises identifying a metatag associated with the application service.
Type: Application
Filed: Mar 12, 2007
Publication Date: Nov 1, 2007
Inventors: Krishnamurthy Srinivasan (Chandler, AZ), Edala Narasimha (Tempe, AZ)
Application Number: 11/685,117
International Classification: G06F 3/00 (20060101);