Hi Murray, I do not agree with you. I do not think code mobility violates service-orientation. I think code mobility enables service-orientation in some cases. The provisioning of executable code is just part of the service. I think code mobility adds new capabilities to your middleware, you can now decide to push some service logic into the service consumer context. The service contract will continue to be necessary and the service logic will continue to be provisioned and controlled by the service provider. The problem with code provisioning today is that it creates constraints on the implementation of the service consumer. In the case of Jini, that constraint is the use of Java which I don't consider personally as a constraint ;-) but for clients not written in Java at all, for sure it is a constraint. Kind regards. Robin
--- In [email protected], "Spork, Murray" <[EMAIL PROTECTED]> wrote: > > The notion of "provision" (and that there is a real > person or organisation behind that providor) is a central and critical > aspect of service orientation. It may appear a subtle distinction at > first - but it has many profound implications (such as services should > not leak technical exceptions). > > This is also BTW the reason why code mobility violates > service-orientation IMO - because the notion of provision *by someone > else* is removed. [cue Greg ;-)] That is not to say code mobility is not > useful in some cases - but for me the provision aspect is central to the > concerns that service-orientation seeks to address. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
