Yes and no, Rob. If only interface and contract/description matter, then anything and everything is the service. Would you agree with this?
I mean that in addition to interface +contract there should be preservation of SO principles. If I take an old monolithic app written Lotus Domino Java and wrap it with RMI interface, I'm supposed to get a service. Well, this service is single-threaded, has to be rebooted every night, exposes its internal errors, and so on, i.e. it dictates consumer what and how to do. Even if I put all these conditions into Service Description, I do not think there will be many consumers that wanted to set the Service Contract with such service. IMO, in Erl's books, service contract plays the role of service interface. BTW, I do not believe that placing an additional interface on a system makes it service (even if the interface name contains word 'service'). - Michael ________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Friday, January 16, 2009 10:42:26 PM Subject: [service-orientated-architecture] Re: Vaughan reviews Erl's Tome --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3pou...@.. .> wrote: > Can anybody explain me how a legacy system wrapped with "non- > standard contracts " or even "standard contracts ", i.e. > interfaces, can become a Service while the legacy system itself > does not demonstrate any implementaion of SO principles? Because in SO, the interface and the service contract are all that matter. How the service is implemented is of no concern, as long as it does what the service description says that it will when invoked. If the legacy system provides the needed functionality defined in the service description, then it doesn't matter how ugly, convoluted, nasty, spaghetti-code, etc., that the implementation might be. Service implementation has an architecture of its own. -Rob
