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? 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?
> 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.
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.
Overall, does it look like a right idea for entier SOA (Jini, WebServices,
REST, CORBA, etc.) - using client's policy to assess compatibility between
service version and the client's needs (and code)?
- Michael
Gregg Wonderly <[EMAIL PROTECTED]> wrote:
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>
>
>
---------------------------------
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
