Hi Gregg, Robin, Note that I never said that code mobility is not useful - nor that you cannot achieve some interesting technical solutions with it to promote location transperancy.
Basically it boils down to the fact that I have a much more restrictive definition of "service-orientation" than it appears either of you do. I also do not propose that SOx is a one-size-fits all approach. Horses for courses and all that. But if my definition of "service-orientation" turns out to be not the industry accepted one then I guess I'll just have to think of a new label for it. On this note I will just sum up by saying it appears that I have not explained adequately my point about "provision" and why I think code mobility violates this "tennant" of SOA. When I have more time maybe I have another go at this. Cheers, Murray > -----Original Message----- > From: [email protected] > [mailto:[EMAIL PROTECTED] On > Behalf Of Gregg Wonderly > Sent: Tuesday, 07 February 2006 10:35 PM > To: [email protected] > Subject: Re: [service-orientated-architecture] Re: Radovan on > why services are not components > > Robin wrote: > > Hi Murray, I do not agree with you. > > I do not think code mobility violates service-orientation. > > > --- In [email protected], "Spork, > > Murray" <[EMAIL PROTECTED]> wrote: > > > 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. > > I was just going to let this one be, but Robin's response > drove me to a position > of supporting his response with an example. This is an > interesting issue. > > With Jini, it's ConfigurationFile mechanism, and the Exporter > mechanism, you > could actually package the use of a smart proxy into a > "deployment time" use > decision independent of the service implementation and without vendor > development support. > > The technique is fairly simple. You would create the smart > proxy that > implements the service interface in the way that you want to > provide as an > optional deployment. The constructor of that smart proxy > would accept an > instance of the service (implementation of the service > interfaces) as the > argument. The custom Exporter would then accept the original > service as its > argument, export the service, create a new instance of the > smart proxy, passing > in the exported service's proxy and then return the smart > proxy. This is the > delegate pattern. > > I'll skip out on providing the the actual code/configuration > since this isn't a > coding forum, but it's a trivial bit of stuff. > > This technique, through the use of Class.forName(), could be > generalized into a > reusable mechanism for any smartproxy substitution into any > service in your SOA. > You could then create deployment tools specific to this > mechanism and allow > the deployers free reign over the configuration processes at > deployment. > > It's really not a big deal to do this with Jini/Java. > > Gregg Wonderly > > > > > > > Yahoo! Groups Links > > > > > > > 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/
