Michael Poulin wrote: > > > Gregg Wonderly wrote: > > The JERI stack provides a constraint mechanism which allows a client to > > assert a particular "authentication" that must be provided. This is > typically > > used to say "I am being served by the right entity". The service level > agreement > > that you inked out, will still be applicable in that sense. You could also > use > > constraints to demand a particular versioning apply to an SLA as well. > > I am not sure I've got it. Does it mean that the client authenticates > the service and agrees to be served "by the right entity"? Or the client > requests "the right entity" in the right version and the service > provider has to provide for it or deny the request?
The client performs a lookup using a service template. It can apply constraints during lookup so that it only uses valid lookup services too. Once the lookup returns, it will not be able to use services which fail to meet the constraints it has asserted, including authentication requirements and codebase related policy. > Another question: > does the client get aware of particular version by retrieving it from > the SLA? If i is correct, is this operation automated? How the client > knows that the version of the service is the right for him? There is not a standard for SLA in Jini itself. Certainly, there are many tools these days in Java SE which can be used to measure and manage SLA kinds of things. The RIO system provides a SLA capable engine which is typically used to manage which services are running by assessing telemetry sorts of things like loads and number of active services. But technically, anything that you can dynamically see, and turn into a measurement can drive RIO to take action. > > As a final say, as a client, you can specify the Java policy using an > httpmd: > > url structure. The httpmd: protocol handler, will process URLs which > include a > > md5 or other sum over the content of the jar file. So, when you grant > policy > > for the use of that service, you can say "I'll only use this specific > version of > > the code"! This really allows a number of things about the service and SLA > to > > be managed on both ends while still allowing the power of mobile code to > be > > used. > > > > Thus, when a new version of the service becomes available, you can just > grant > > policy to the new httpmd: specified jar URL and then you'll be able to use > that > > version of the service without having to "install" a new version of the > client. > > This sounds like a client can grant a policy to the service and declare > (in the policy) that only particualr version of the service is used by > the client. The policy implementation in Jini is based on the Java Permission implementation. In the client, you typically grant permissions for what can happen inside of code that you download. In some cases, attributes of versioning can be managed in that way. I'm not aware of any specific toolset targeted specifically at controlling versioning in this way, but can think of several things that one might do in different circumstances. > Is it correct understanding? If so, it is quite close to > what I proposed with policy-based version control. In my case I am going > a bit further, I guess: the policy specified by the client relates to > the version of the service and policy rules can assess current and > several future versions even if they are not backward compatible (I do > not need to grant policy every time when the version changes) depending > on the client's needs. The Jini policy granting, based on Permissions has a lot of flexability in how you might apply it to different needs. Without specific examples, I don't know that I can provide words here for a "solution". > Overall, does it look like a right idea for entire SOA (Jini, > WebServices, REST, CORBA, etc.) - using client's policy to assess > compatibility between service version and the client's needs (and code)? There are ways to do this type of thing, and I think it's good to let the client be able to assert some expectations of what it needs the service to do. Gregg Wonderly
