Michael Poulin wrote: > Since Service responsibilities are defined in the Service Contract, the > service backward compatibility is the backward compatibility of the > changes in the scope of the contract. I agree that interface change is > extremely undesirable situation but, being realistic, I cannot accept > the constraint "interface never changes", it is over-simplification to > me. We have to have a mechanism for management service usability even > when the interface changes.
Interfaces need to be able to change. But, that is no different than the issue that you enumerate below. If it is not backward compatible, then it will involve agreement and negociation with the customers. > Also, I am not sure that it is a 100% right idea when a backward > compatibility is totally delegated to the service provider because the > service consumer circumstances might change as well and what was OK > yesterday in the Service Contract might become not acceptable with new > service changes today. Right, so let me tell you some more about the facilities that Jini provides to address this issue. 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. 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. There are some other features of JERI and the Jini platform that can be used as well. Gregg Wonderly > So, I propose the service consumer to decide if the service is backward > compatible to the consumer needs via the service version validation. > That is, the service provider reflects all changes in the service > compound version to signal its consumers about changes, the consumer's > version policy enforcement decides if the service is still to deal with > (Service Versioning For SOA - http://java.sys-con.com/read/250503.htm). > > - Michael > > > */Gregg Wonderly <[EMAIL PROTECTED]>/* wrote: > > Jan Algermissen wrote: > > I have a question regarding evolution: you mention payload evolution > > (XML language evolution) but not interface evolution. IMHO, the > > letter is the far more critical issue because it is much harder to > > provide a clean strategy. While a theory of versioning is doable for > > e.g. XML languages, I cannot really see one for interfaces. > > > > Since interfaces are allowed to evolve in a SOA how does one deal > > with such change? > > > > I am not asking how to handle an individual change, but how one > > achieves a cliean strategy (as we have for the payload)? > > One of the primary issues to address is backward compatibility. In an > environment where you are responsible for every client and service, > you can > easily feel compelled to just use the "change everything at once" > strategy, > and remove the old interface compatiblity and just deal with the issues. > > In a decoupled/distributed system where clients are more like > "customers" or > remote, out of timezone and control users, then you have to deal > with the > backward compatibility issue. > > I think it's important to use technologies which really support this > from the > start. XML based Data, allows evolution only by "adding" data items. > You have > to extend the document in a way that doesn't conflict with current > syntax > (structure) and meaning (content). That's "possible", but can cause > a lot of > old wood to be left lying around to rot in a volatile environment > where a lot of > change is happening continuously. > > The interface part of this comes back to the transport technology. REST > proponents would tell you that the interface never changes with > REST. However, > the document is the interface to the applications' functionality. It > has to be > populated a particular way for a particular instance of the service. > > If there are multiple versions of the service, and a client has to > use all of > them, and there is a good implementation of backward compatibility, > the client > will be forced to use the lowest common denominator, unless it is > upgraded in > some way. > > The mobile code model, such as that in Java and extended by the Jini > platform, > allows a client to be unaware of optimizations and versioning going > on in the > service architecture. This can happen because the Java language > interface is > the typical service discovery mechanism, so a client always gets > something that > implements the version of the service interface it knows about. > > If I want to upgrade the service interface, I can implement a smart > proxy that > continues to provide the old interface by delegating to the new > interface. > > I might have an interface like this with lots of granularity, but > which is > causing me to add more overrides of add() as different types are needed. > > public interface ServiceV1 extends Remote { > public int add( int v1, int v2 ) throws RemoteException; > public double add( double v1, double v2 ) throws RemoteException; > } > > So, I read this group and find out about less granularity and decide > that I > really want my service to just use the following interface. > > public interface ServiceV2 extends Remote { > public Number add( Number v1, Number v2 ) throws RemoteException; > } > > So, I create the smart proxy as: > > public class SmartProxyV2 implements > InterfaceV1,InterfaceV2,Serializable { > private ServiceV2 delegate; > public SmartProxyV2( ServiceV2 delegate ) { > this.delegate = delegate; > } > > public int add( int v1, int v2 ) throws RemoteException { > return add( new Integer(v1), > new Integer(v2) ).intValue(); > } > > public double add( double v1, double v2 ) throws RemoteException { > return add( new Double(v1), > new Double(v2) ).doubleValue(); > } > > public Number add( Number v1, Number v2 ) throws RemoteException { > return delegate.add( v1, v2 ); > } > } > > If you use something with mobile code, in this type of situation, > this really > simplifies things. Because the Service can evolve and version > independent of > client upgrade, without any backward compatibility present in the > Service. > Instead, the backward compatibility is just in the smart proxy. > > A web page is a form of mobile code, as are AJAX applications and > many other > similar technologies. However, web browsers don't have a generally > extensible > discovery mechanism. They have to have a starting point in the sense > of an > IP address. That IP address might change every place that you take > your laptop > depending on several things. > > The Jini platform utilizes IP multicast for discovery of nearby > services and can > be configured to use unicast (an IP address) lookup for finding well > known > services in connected networks. > > There are a lot of choices these days. Mobile code happens to > provide a number > of very important benefits that most SOA systems/platforms don't > provide. > > Gregg Wonderly > > > ------------------------------------------------------------------------ > Sucker-punch spam < > http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/mailbeta/features_spam.html> > > with award-winning protection. > Try the free Yahoo! Mail Beta. < > http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/mailbeta/features_spam.html> > > >
