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/
