EJB or web service

We have to make a component available to three applications. All the
applications and services have to be deployed on the same clustered
server. Now I know EJB is one of the options available to us and it
will work well.
However I am very much interested to make it a web service. Now I have
following questions -
1. Will the web service be slower than EJB. If yes then why?
2. Is there any way to speed up the web service, if it is on the same
clustered server as its clients?
3. Do i have any other option except web service? Few persons suggested
to use XML (over http)?

Suggestions please

Thanks

mank wrote:

> We have to make a component available to three applications. All the
> applications and services have to be deployed on the same clustered
> server. Now I know EJB is one of the options available to us and it
> will work well.
> However I am very much interested to make it a web service. Now I have
> following questions -
> 1. Will the web service be slower than EJB. If yes then why?
> 2. Is there any way to speed up the web service, if it is on the same
> clustered server as its clients?
> 3. Do i have any other option except web service? Few persons suggested
> to use XML (over http)?
>
> Suggestions please

If there is no value in providing for more varied and distributed
clients then web services are the wrong technology for the job.
Moreover, it is generally pretty easy to put a web services interface on
top of an existing service, so you could have it both ways.  Do note,
however, that "web services" is at best a collection of protocols, and
perhaps not even that.  EJB, on the other hand, is a technology; the two
are not directly comparable (but I'll try anyway).

(1) Standard web services protocols involve a fair amount of production
and consumption of XML.  XML is not a compact data representation, and
parsing it is comparatively expensive.  I would expect EJB over local
component interfaces to have a performance advantage in that regard, and
even EJB over remote component interfaces should at worst be on par.
How much effect those considerations might have depends heavily on the
nature of the service.

(2) A web service or EJB-based one will naturally be faster for local
clients because of reduced communication latency.  A web service client
might be able to use a local network address to communicate with the
service (i.e. localhost/127.0.0.1), which on some systems might offer
some additional improvement (but less likely so on a clustered server).
Other than that, not that I can think of.

(3) XML over HTTP more or less _is_ web services.  The details of other
options depend quite a bit on your requirements.  You could probably do
it all with MPI, for instance, but that's quite a different sort of
technology from what you first asked about, and probably not of
interest.  It's rather difficult for me to guess what might be of
interest, however.  An option you should at least consider is a
servlet-based service.  If you do not need the "Enterprise" features of
EJBs, (declarative security, distributed transactions, etc.) then
servlets might be just the thing.  On the other hand, if you _do_ need
the enterprise features then why are web services even in the running?


John Bollinger
jobollin@indiana.edu

Thanks a lot,
We don't need security, transactions. etc.  I just want some services
which can be accessed from different applications.  Can you give me
more ideas about servlet based services, any links/references ?

I don't know if this fits the bill!

The Spring Framework is lighter than EJB's!

http://www.springframework.org/

--
Regards,
Casey

mank wrote:

> Thanks a lot,
> We don't need security, transactions. etc.  I just want some services
> which can be accessed from different applications.  Can you give me
> more ideas about servlet based services, any links/references ?

Generic servlets are computational entities that accept requests over a
network and returns responses.  They are part of J2EE and
protocol-neutral.  J2EE also includes an HTTP-specific implementation,
which is the form in which servlets are most frequently used.  You can
write arbitrary Java code that your servlet(s) will use in the course of
preparing responses to requests, so they can do pretty much anything
Java can do.  You will find them underneath a wide variety of
applications and components, probably including most of the packaged
Java web services products you might investigate.  Servlets run in a
servlet container (all full-blown J2EE application servers include one)
which handles the details of accepting connections, managing threads,
etc.  Servlets are a well-established Java technology, and you can find
a multitude of resources on the web and in print that discuss them.  The
actual specifications are available for download from Sun.


John Bollinger
jobollin@indiana.edu

I think I need to explain more,
We have 3 different applications who have some common
functionalities(fetching the read-only data from backend). So we
decided it to  make a separate component and all the three applications
will invoke this component to get their data.  No need of any security
or transaction in this component.
1. If we make this an EJB, the clients still needs to have all
interface classes and we have to rebuild all client applications when
we change the component interfaces and EJBs are big overhead too.
So we have following options -
2. We were thinking clients will send XML and the reusable component
will process and return the xml. Now if  we use XML over http (i.e.
making the component a servlet ) then how to locate the servlet (we
only know the relative URL, not the absolute URL)   and how to
communicate with them.?
3. We can use web services but will it a big overhead ?
4. Any  better options - like use     XML over RPC        or        XML
over SOAP..   and if yes the how to locate the service and how to
communicate?
Thanks Please help

I think I need to explain more,
We have 3 different applications who have some common
functionalities(fetching the read-only data from backend). So we
decided it to  make a separate component and all the three applications
will invoke this component to get their data.  No need of any security
or transaction in this component.
1. If we make this an EJB, the clients still needs to have all
interface classes and we have to rebuild all client applications when
we change the component interfaces and EJBs are big overhead too.
So we have following options -
2. We were thinking clients will send XML and the reusable component
will process and return the xml. Now if  we use XML over http (i.e.
making the component a servlet ) then how to locate the servlet (we
only know the relative URL, not the absolute URL)   and how to
communicate with them.?
3. We can use web services but will it a big overhead ?
4. Any  better options - like use     XML over RPC        or        XML
over SOAP..   and if yes the how to locate the service and how to
communicate?
Thanks Please help

mank wrote:

> I think I need to explain more,
> We have 3 different applications who have some common
> functionalities(fetching the read-only data from backend). So we
> decided it to  make a separate component and all the three applications
> will invoke this component to get their data.  No need of any security
> or transaction in this component.
> 1. If we make this an EJB, the clients still needs to have all
> interface classes and we have to rebuild all client applications when
> we change the component interfaces and EJBs are big overhead too.

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

> So we have following options -
> 2. We were thinking clients will send XML and the reusable component
> will process and return the xml. Now if  we use XML over http (i.e.
> making the component a servlet ) then how to locate the servlet (we
> only know the relative URL, not the absolute URL)   and how to
> communicate with them.?

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.

> 3. We can use web services but will it a big overhead ?

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

> 4. Any  better options - like use     XML over RPC        or        XML
> over SOAP..   and if yes the how to locate the service and how to
> communicate?

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