Thanks, Jan for the clarification - I think I see what you mean! Re the assembler comms code example, I only quoted this as an instance of a software "black hole", just like some of those complicated COBOL programs which are Greek to young programmers. I was not suggesting that it would be a suitable candidate to use as a service with SOA or client/server protocols (it was tightly coupled with other assembler code running in the same Z80 box).
Gervas --- In [email protected], Jan Algermissen <[EMAIL PROTECTED]> wrote: > > Hi Gervas, > > hmm..there seemse to me a misunderstanding. Using a genric interface > does not mean to change existing application's interfaces. E.g. it > does not mean messing with that assembler code to provide an HTTP > interface. > > The questions is what interface to expose once you have independent > components talking to each other. If you stick to the assembler > interface for *that* purpose, you'd get all sorts of coupling. > > IMHO there is no dispute about whether or not to hide such legacy > interfaces with a remote facade (aka service), the dispute is only > about the type of interface those facades should expose. > > When you compare > > (1) > class MapService { > public Map getUSAMap(); > public Map getEuropeMap(); > } > > and > > (2) > > class MapService { > public Map getMap(string country); > } > > the latter gives you looser coupling and thus greater evolvability. > > class MapService { > public Message get(); > } > > just takes that too the extreme, moving all non-generic application > semantics into the data formats - where they are IMHO much easier to > manage than at the interface level. > > But I must admit that (despite being pro-REST right from the > beginning) it has taken me at least a year of in-depth study to > perform the shift of mind. Actually, it did not happen before I was > facing distributed systems requirements that had extremely high > organisational cost of upgrading clients once they would have been > deployed. > > What is missing I guess is an explanation of the generic interface > approach that lets one grasp the thing right away; well...let's say > at least as fast as OO. > > Jan > > On Feb 28, 2006, at 5:29 PM, Gervas Douglas wrote: > > > > > I was not suggesting that one should take pain to keep the legacy > > interfaces; in the example I quoted there are probably no interfaces > > to keep apart from 3270 screen feeds. It is however sometimes worth > > conserving the application logic and functionality, or at least a > > significant part of it. If the truth be known, this legacy logic and > > functionality is not always fully understood by the current IT staff. > > > > To give an example outside the sphere of enterprise apps, I knew a > > South African company with some brilliant comms technology written in > > assembler. This stuff had no equal anywhere else at the time. Some > > of this code, the programmers (not even the highly technical managing > > director - brilliant but mad) did not dare touch. Why? Because no one > > understood the algorithms except the brilliant, mad Englishman who had > > written the code. There was enough technical sanity in the firm not > > to meddle where dangerous! > > > > > > > I suspect that as new technologies, not yet envisaged, come online, > > you may well eventually have to change your interfaces everywhere. > > Having built sound SOA structures, many of your application modules > > will live on, albeit in new skins. > > > > Gervas > > > >> Jan > >> > >> > > ______________________________________________________________________ > > __ > >> _______________ > >> Jan Algermissen, Consultant & Programmer > >> http://jalgermissen.com > >> Tugboat Consulting, 'Applying Web technology to enterprise IT' > >> http://www.tugboat.de > >> > > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > ________________________________________________________________________ > _______________ > Jan Algermissen, Consultant & Programmer > http://jalgermissen.com > Tugboat Consulting, 'Applying Web technology to enterprise IT' > http://www.tugboat.de > 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/
