On Wed, Jun 3, 2009 at 1:00 PM, Christopher L Merrill
<[email protected]> wrote:
>
> RMI would probably have been our (my) first choice, but is out due to
> firewall issues.
> Spring with the HTTP invoker was considered as well as some other more
> efficient
> HTTP and/or light-XML options. There are some organizational reasons to
> favor
> SOAP vs something simpler and there are plans to extend the service at some
> point to other organizations. We certainly _could_ do that later, but
> maintaining
> a 3rd interface down the road is not attractive in terms of maintenance
> cost.
> We would have to content with an installed user base - and therefore could
> not
> easily deprecate an unused interface.
Understood, however "maintaining" the interface isn't really an issue
with Spring remoting or directly calling the API (standard
refactorings would fix these situations). The only time you would get
into having to really work on the interface is if you do introduce the
SOAP/XML support. Then, you've got to worry about making sure your
XSD stays in synch with everyone. If you add that to your system now,
you're biting off the maintenance at a time when you don't know for
sure if you're going to need it ("at some point" may never come). I'd
go with the YAGNI principle, here.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
