Patent Application
20080077709
The subject matter, which is regarded as the invention, is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:
One aspect of the exemplary embodiments is a method for client to retrieve schema from SDO-based remote service. In another aspect of the exemplary embodiments, a remote service interface is dynamically changed at runtime, by a client, by extending the schema of the data object to include more attributes. In yet another exemplary embodiment, the remote service's business logic is able to interpret new schema and support the new attributes without restart the server.
SDO-based local service is a proxy of the SDO-based remote service at the local JVM (Java Virtual Machine) of clients. The SDO-based local service implements the SDO-based remote service so that client applications can use it the same way as the SDO-based remote service. The implementation of the local service solves the problem of transferring schema remotely by converting them to serializable form of byte arrays. In addition, the implementation hides the complexity of looking up remote service, and retrieving and registering schema from the clients. As a result, by using an SDO-based local service, the exemplary embodiments of the present invention allow clients to dynamically extend the interface of remote service remotely at runtime. The schema used may be extended to support additional syntaxes, matching rules, attribute types, and object classes. For example, following is a sample method of SDO-based EJB service, which allows a client to create a “Person.” For instance:
Assume a client wishes to create a new type called “Employee,” which extends from “Person” type with one additional attribute called “EmployeeNumber.” The client may also desire to perform this operation dynamically at runtime, which means the service cannot be stopped and restarted. The new XML schema will look like this:
For the SDO-based remote service, which allows clients to dynamically extend its interface, two support methods may be desired. These support methods are: (1) “getSchema”, which allows clients to retrieve latest schema from service, and (2) “addSchema”, which allows clients to extend service interface by adding new schema. Besides these two methods, a method “create” is provided to allow client to create a new “Person” or “Employee”.
Referring to
The communication of the SDO-based local service 34 with the SDO-based remote service 30 can be summarized as follows. (1) During the start process of SDO-based remote service 30, it loads the schema from XSD schema files 20 and registers the schema as Ecore model 22 in the Server JVM 14. (2) Client 118 calls SDO-based local service 34 to create a “Person”. (3) Since this is the first time SDO-based local service 34 being called, it needs to locate the SDO-based remote service 30. (4) After the service is located, SDO-based local service 34 calls method “getSchema” 24 to request the schema from the SDO-based remote service 30. (5) The service serializes the Ecore model 22 in server JVM 14 to byte array. (6) The serialized schema is then returned back to the SDO-based local service 34. (7) After receiving the byte array form of the schema, the SDO-based local service 34 restores it back to Ecore model 16 and register it in client JVM 12. (8) Finally, the SDO-based local service 34 continue the call from the client 118 by calling method “create” 28 of SDO-based remote service 30. This method will create new “Person” on the server.
Referring to
Specifically, the communication of the SDO-based local service 64 with the SDO-based remote service 62 can be summarized as follows. (1) The client calls the method “addSchema” of SDO-based local service 64 to add a new type called “Employee,” which has a new attribute called “EmployeeNumber.” (2) SDO-based local service 64 passes the call to SDO-based remote service 62. (3) SDO-based remote service 62 validates the new schema to make sure that the request does not change the existing schema, only add new schema to existing schema. After validation, SDO-based remote service 62 merges the added schema with existing schema and registers the new schema as Ecore model 54 in the Server JVM 44. (4) The SDO-based remote service 62 saves the schema back to schema files so that the new schema is still there when service restarts. The server business logic should be able to interpret the new schema and change its internal configuration to support this new type “Employee”. (5) SDO-based local service 64 calls method “getSchema” 56 to request the new schema from the SDO-based remote service 62. (6) The service serializes the Ecore model 54 in server JVM 44 to byte array. (7) The serialized schema is then returned back to the SDO-based local service 64. (8) After receiving the byte array form of the schema, the SDO-based local service 64 restores it back to Ecore model 46 and register it in client JVM 42. (9) The client 148 can now call the method “create” to create the new type “Employee” with new attribute “EmployeeNumber.” (10) SDO-based local service 64 passes the call to SDO-based remote service 62 to finish the call to create the new type “Employee”.
In the implementation of the algorithm, the SDO-based local service help clients to do the entire schema related tasks. This can relieve clients from the above work and concentrate on business functions, thus effectively using resources.
Since the new schema extends, not changes the existing schema, the new schema should not affect other clients. If another client attempts to extend the service interface with new schema that conflicts with the new schema created by a first client (e.g., creating a new type which also named “Employee” in the same name space), then the service makes an exception to this request. Specifically, the client calls method “getSchema” to retrieve the latest schema from service and use the “Employee” type created by the first schema. The client can also try to create the type again with different name or different name space.
Following are some sample code of the implementation for the process in
When a client needs to access SDO-based remote service, it creates an SDO-based local service instance first. In the following example, the remote server is implemented as EJB interface. “LocalServiceProvider” is the SDO-based local service. An instance of “LocalServiceProvider” is created with the host name of the remote EJB server and the RMI (Remote Method Invocation) port. Specifically:
During the initialization of the SDO-based local service instance, it looks up the remote service, and then retrieves the schema packages from the service. For example, the getSchema method of the remote service converts the Ecore model from “EPackage” to byte arrays. The following exemplary code illustrates a method of performing such task:
After the SDO-based local service instance obtains the byte arrays from SDO-based remote service, it restores the schema packages from byte arrays back to “EPackage”, and registers them in a local VJM as Ecore model:
All the above steps are transparent to the client. They are part of the initialization process of the SDO-based local service. After the client creates this new instance of SDO-based local service, the client can then access the remote service through this local service. For example:
The capabilities of the present invention can be implemented in software, firmware, hardware or some combination thereof.
As one example, one or more aspects of the present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately.
There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.
While the preferred embodiment to the invention has been described, it will be understood that those skilled in the art, both now and in the future, may make various improvements and enhancements which fall within the scope of the claims which follow. These claims should be construed to maintain the proper protection for the invention first described.
