U.S. patent application number 11/685117 was filed with the patent office on 2007-11-01 for discovery and integration of jini services in non-java clients.
Invention is credited to Edala R. Narasimha, Krishnamurthy Srinivasan.
Application Number | 20070256086 11/685117 |
Document ID | / |
Family ID | 24951246 |
Filed Date | 2007-11-01 |
United States Patent
Application |
20070256086 |
Kind Code |
A1 |
Srinivasan; Krishnamurthy ;
et al. |
November 1, 2007 |
DISCOVERY AND INTEGRATION OF JINI SERVICES IN NON-JAVA CLIENTS
Abstract
A system of forming a bridge between non Java services and a
Jini (.TM.) 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 (.TM.) broker.
Inventors: |
Srinivasan; Krishnamurthy;
(Chandler, AZ) ; Narasimha; Edala R.; (Tempe,
AZ) |
Correspondence
Address: |
FISH & RICHARDSON, PC
P.O. BOX 1022
MINNEAPOLIS
MN
55440-1022
US
|
Family ID: |
24951246 |
Appl. No.: |
11/685117 |
Filed: |
March 12, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09734333 |
Nov 30, 2000 |
7191453 |
|
|
11685117 |
Mar 12, 2007 |
|
|
|
Current U.S.
Class: |
719/328 |
Current CPC
Class: |
G06F 9/465 20130101 |
Class at
Publication: |
719/328 |
International
Class: |
G06F 3/00 20060101
G06F003/00 |
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.TM. interface; the first application programming
interface comprises a Java.TM. application programming interface;
and the second application programming interface comprises a
non-Java.TM. 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.TM. 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.TM. interface; and the first application
programming interface comprises a Java.TM. 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.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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.
BACKGROUND
[0002] Jini (.TM.) 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 (.TM.) operates by registering
services, and responding to client inquiries about one of these
services. Jini (.TM.) also provides proxy code to the client
allowing the client to communicate with the services. In this way,
Jini (.TM.) acts as a broker between the client and the existing
services.
[0003] Jini (.TM.) 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 (.TM.).
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] These and other aspects will now be described in detail with
reference to the accompanying drawings.
[0005] FIG. 1 shows an operation of the bridge of the present
system, forming an interface between non Java services and a Jini
(.TM.) broker;
[0006] FIG. 2 shows a flowchart of operation of the system;
[0007] FIG. 3 shows an example of encapsulating CORBA
component.
DETAILED DESCRIPTION
[0008] 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 (.TM.)
protocol. In this way, Jini (.TM.) 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.
[0009] The current Jini (.TM.) interface will register services
which have a Java Application Programming Interface ("API").
Services without a Java API cannot be registered with Jini (.TM.).
While the present application specifically describes using Jini
(.TM.), it should be understood that any service requiring a Java
API could be similarly used.
[0010] The operation is shown in FIG. 1. A Java service normally
publishes itself or its proxy to Jini (.TM.), along with a set of
search attributes that can be used by services that are searching
among the services. According to the present system, a non Java
service 100 is published, using a Java compliant "wrapper", as
described. The wrapper acts like Java proxy code, and points to the
non Java service, in the same way that Java proxy code would point
to the Java service.
[0011] 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 FIG. 1.
The point and click operation is used to instruct the bridge 110 to
publish the service.
[0012] The bridge 110 operates as shown in the flowchart of FIG. 2.
At 200, the bridge performs run-time introspection of the service
component 100. At 210, the bridge identifies the
methods/functionality within the service. This can use dynamic
inspection and/or keywords, metatags, or other kinds of application
inspection. At 220, these results are stated as a list of different
functionalities and other relevant information. FIG. 1 shows the
functionalities graphically as 120. This list will be used to form
the eventual code.
[0013] 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 (.TM.). In addition to the keywords
identified by introspection, a user may also specify additional
keywords in the Graphical User Interface (GUI).
[0014] Jini (.TM.) stores the proxy objects and a set of search
attribute objects shown as 152, 154, shown in FIG. 1.
[0015] The Jini (.TM.) 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.
[0016] At 260, the bridge receives a Jini (.TM.) lease object based
on the successful registration of the Jini (.TM.) 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 (.TM.).
[0017] A service is published to Jini (.TM.) 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 (.TM.) may publish their proxies instead. Constraints
such as heaviness, native dependability, and the like may prevent
the service from directly publishing to Jini (.TM.). 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
(.TM.), along with a set of search attributes. Once the Java
objects have been transported to Jini (.TM.), they are delivered to
clients responsive to notifications of service matches.
[0018] 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 (.TM.), would do so directly. This
enables clients to directly use the service objects.
[0019] Non Jini (.TM.) services may not have a proxy, or such a
proxy may need to be generated as part of the Jini (.TM.)
registration process.
[0020] Certain distributed application environments allow services
to register with them through an identifier. One example is a GUID
key for COM components.
[0021] As an example of operation, FIG. 3 shows how the system
could publish and obtain different information. A service 300,
e.g., a CORBA service is coupled to the code generator 305 which
provides an wrapper around the CORBA shown as 310. Once in the
wrapper, the CORBA code appears to the broker or proxy as Java
code, i.e., it is no different like any other Java application. At
315, the application is published with the Jini (.TM.) broker. FIG.
3B, shows a client, which is a non Java client such as an
Excel(.TM.) client asking for services. At 330, the request for
services is also placed in a wrapper at 335 and placed to Jini
(.TM.). Jini (.TM.) returns the request.
[0022] Although only a few embodiments have been disclosed in
detail above, other modifications are possible.
* * * * *