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
