Mark Baker wrote:
> Organizations should certainly be prepared to change their services;
> I'm totally with you there. But IMO, they should do it by changing
> implementations, as changing interfaces is hugely expensive,
> especially to their customers/partners who've written code that uses
> those interfaces. I think interface changes should be avoided
> wherever possible. And I think generic interfaces best support this
> objective, as previously discussed (and which you appeared to agree
> with - kudos).
Generic interfaces are qualified by the technologies involved.
If all I have are wires and voltages with analog signals (the POTS telephone
for
example), I can only utilize the features of that transport. We got caller ID
in the US by having the quite period between the 1st and second rings be
replaced by low voltage signaling that would not assert the 70v ring voltage.
We got digital communications by using a modulation/demodulation scheme to
encode data. But, we couldn't get past the bandwidth limitations. POTs is a
very simple, lightweight implementation of amplitude modulation over wires.
To get to higher speed digital subscriber services, we had to change the signal
sent over the wire to an RF based signal modulated with a very complex
signaling
strategy (lookup DSL and ADSL). That signaling can go across the wires, but,
interferes with the use of a POTS telephone. So, a filter has to be attached
to
the line to keep that ugly buzzing noise from being mistaken for an AM sound
that I'm actually interested in hearing. The signal is much higher in
frequency, than audible tones, but the lower harmonics allow our ears to hear
the hash.
This is an example of how an existing system can be modified in a backward
compatible way.
Generic interfaces using extremes such as
public Object doIt( Object val ) throws Exception...
provide mechanisms for dealing with certain limitations. However, if you then
go ahead and provide interpretation of 'val' on the called side and the return
value on the calling side, you are simply moving the normal invocation layer of
a native transport system into your application. The question is whether this
is adding value, complexity, cost or what.
In JERI, an invocation layer factory has access to the calling parameters and
the called return value at a centralized point which provides this same
interface to genericizing the transport of the "message". The difference is
that this is a plugable part of the system architecture that is already in
place. You don't have to engineer it into each application. You don't have to
standardize something else to allow other users of similarly scoped systems to
take advantage of a particular mapping between invocation layers that you've
provided.
It's commonly said in the Jini world, you may not be using Jini yet, but some
day, you'll rewrite enough of it that you'll finally understand why you should
have been using it all along so that you could of focused on your application,
instead of on rolling your own infrastructure.
Gregg Wonderly
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/
