The synchronization and rebuilding issue is no different from what you
have now.  How much of an overhead EJBs impose depends on the EJB.

As I wrote before, exchanging XML messages over HTTP in order to request
an action (and optionally receive a response) _is_ web services, whether
you do it according to one of the [somewhat] established web services
protocols or whether you roll your own.

In any case, how can you _not_ know the URL for a local service
interface?  If the applications don't already know then *tell them*, by
means of configuration settings if nothing else.

You are looking at some maintenance overhead any way around, whether you
go for EJBs or for web services.

RPC is a distributed application paradigm, not a communications
protocol.  XMLRPC over HTTP is, again, web services.  Changing the
protocol is unlikely to change the relevant characteristics much.

SOAP is a protocol-independent message exchange mechanism.  When you use
it over HTTP to request action or data from a separate process it is
called "web services".  Changing the underlying protocol is unlikely to
alter the relevant characteristics very much.

Any way around, the easiest way for your applications to locate the
relevant service is for you to configure them with its location.  All
solutions are more or less equivalent to that: if you don't give the
applications the location itself then you have to tell them who to ask
for it and how.  The additional flexibility of a layer of indirection is
not of much value to the application suite you describe.

To this point you have asked which should be preferred among EJB, web
services, web services, web services, and web services.  If this were an
election then it appears web services would win with 80% of the vote.  I
am not in a position to judge your technical requirements, but I do note
that a well-written EJB-based solution making use of local component
interfaces is likely to have lower overhead than any solution involving
significant production and consumption of XML (i.e. web services).  A
solution based on Java RMI, such as EJB over remote component
interfaces, is likely to have communication overhead comparable to that
of a web services solution to the same problem.  If the use pattern of
the shared component involves many fine-grained requests then web
services and similar approaches are unlikely to work well, but EJB over
local interfaces might still be OK.  If the use pattern involves fewer,
coarser-grained requests then either approach might work acceptably.

Also, have you considered the possibility of sharing component code
instead of component implementation?  You can factor out the code for
the data access functionality into a common component for maintenance
purposes, but still let each application create and use its own local
instance.  That would probably be a useful first step even if you plan
ultimately to move to a shared instance along the lines you originally
described.

John Bollinger
jobollin@indiana.edu