Sponsored Link •
I've been working on an enhancement to Jini servce lookup in my reef project over on jini.org. I've still got more work to do before getting to the proposal stage. Here's where I'm at.
ServiceRegistrar's lookup(ServiceTemplate,int) method returns a ServiceMatches object that then provides access to an array of ServiceItem Objects. The ServiceItem class has no accessor methods, and just provides fields with access to the unmarshalled form of the service registration data values, namely the ServiceID, an Entry and service object.
What happens with this implementation is that if a ServiceTemplate matches more than just a couple of services, a whole bunch of code downloads can occur and a lot of time can elapse while the service code is downloaded and the service registration objects are instantiated. This API doesn't provide any real flexibility in controlling when unmarshalling occurs or which values are unmarshalled.
With 4 machines, that means about 100 serviceUIs and about 60 download requests using ServiceRegistrar to lookup these services. The kicker is that some of the users of these clients connect with a cellphone dialup or similar low bandwidth connection to access the mainUI for some of these services.
I was confronted with a real need to greatly reduce and explicitly control the moment of downloading code. The client computers are not big computers either, so I really need to control the total number of live objects too.
This is largely a valid response from a number of perspectives, but it doesn't make it any easier to get the results one might really need. It is an architecture which uses existing functionality and extends it to be more useful. The fact that there is some additional work involved in creating and deploying another service creates some barries however.
One of the issues with the service lookup/matching specification is that it doesn't demand marshalling it just says that lookup comparisons must be equivalent to MarshalledObject.equals() behavior. There are some interesting reasons why one might choose to not specify the required implementation. But, this, to me, leaves the door opened for lookup service implementations that won't use marshalling, and thus won't provide the client the opportunity to control the unmarshalling.
The BasicILFactory class provides the ability to supply MethodConstraints to dictate what types of criteria the transport, invocation and client environments must meet to use the service. There are some interesting interactions here from the perspective that you can tell the invocation layer that your service needs to have a secure transport, with the endpoint implementation providing this guarentee. There are some interactions through the layers that make it possible for the question of "is this constraint met?" to be answered. This happens through a number of paths of execution from both the client side (proxy preparation) and the service side (proxy verification and invocation layer validation during inbound calls).
I'd like for service lookup results to allow the client software to query the service for its requirements so that a first time use of a service could allow the client to assert the required constraint implementations through dialogs or wizards that would help users understand more about the service requirements. Currently, these implementation details are manually managed and the deployment environment is assumed to be managed by well trained people who most likely already know the requirements that need to be met.
Login identities for authentication and authorization are one barrier, but there are other constraints that the user can meet with explicit control of their environment.
This basic filtering request has come up in the Javaspaces realm too. There are a wide diversity of potential needs for matching/discovering/filtering in the real world. There needs to be some more flexibility in matching. One of the problems is that matching in the server to control returned results is going to be limited because of the desires to keep user supplied code out of the lookup service to manage integrity and reliability issues. The current ServiceTemplate provides exact matching using simple equals() comparisons.
I'd like to extend this ability to include some more explicit control over the results of matching to better control bandwidth based performance. It would be nice to get 1 result efficiently (getting access to a single well known service), but not be burdened by the API when 100 results (all services that provide a serviceUI) would make sense as well.
|Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments.|