EJB vs SOAP
hussein Badakhchani
SOAP and EJB's are can be used in a complimentary fashion rather than
selecting one over the other. Here is a patteren that we use to provide web
services.
All services are defined using SOAP or WSDL thus making it possible for
thired parties to access your services via open standards (SOAP, XML) over
HTTP (rather than a propriatry protocol), this is typically implemented by
installing a SOAP enabled WEB-APP on a J2EE container which acts a client to
your middle teir ejbs, which access and manipulates your data base or legacy
systems. The above patteren exploits the security, transaction handling and
scalability offered by J2EE architecture and makes your services more
attractive to thired parties because they won't be locked in to using
propritatory standards to access them.
Regards Hussein
I have
"Public <Anonymous_Account>" <rema...@anon.xg.nu> wrote in message
news:dc7593315aa3714f...@anon.xg.nu...
> Hi,
> being new to EJB and SOAP, I was wondering if someone could enlighten me
on why one would chose SOAP over EJB, and vice versa. Seems to me like both
do the same thing.
> THanks
>
>
Steffen Ramlow
"hussein Badakhchani" <hus...@badakhchani.fsnet.co.uk> wrote in message
news:9l6ic2$21v$1...@news6.svr.pol.co.uk...
walpj
The following whitepaper comes to the same conculsion after surveying all
available technologies.
http://www.orchestranetworks.com/us/solutions/0105_whitepaper.cfm
Samuel Fink
> [...]
> The following whitepaper comes to the same conculsion after surveying all
> available technologies.
> http://www.orchestranetworks.com/us/solutions/0105_whitepaper.cfm
After reading the paper, I believe that, on the contrary, they don't
see EJB and SOAP as very complementary technologies.
1) They state that SOAP can't be used as a native communication
protocol for EJB, because semantics of SOAP can't support semantic of
the EJB distributed model. To me, this seems to be in total
contradiction with what Tor wrote earlier in this thread.
1) I believe they advise to manage security and authentication at the
SOAP listener level (web server/Servlet engine), not at the EJB level.
They strongly advise to not use EJB for business object modeling and
persistence. Instead they advise to use other Java technologies like
JDO.
I believe SOAP and EJB compete at the "distributed" level. And I tend
to agree that if you choose SOAP, then there is little interest in
using EJB, because much of the EJB benefits are already provided at
the SOAP layer (naming and discovery, distributed access, security,
authentication etc.) and the rest is mainly object persistence in
transactional stores, which is one of the weakest feature of EJB.
Comments anyone ?
-- Samuel
Cuplan
wrote:
>1) They state that SOAP can't be used as a native communication
>protocol for EJB, because semantics of SOAP can't support semantic of
>the EJB distributed model. To me, this seems to be in total
>contradiction with what Tor wrote earlier in this thread.
Well, to me, the synergy is in SOAP services communicating to one
another. EJB should work fine as a backend, I would think. Then
again, this is something I'm fairly new to. As soon as I roll out my
new project to alpha testing and have the new website done and have a
moment to catch my breath, I've a planned week or two to investigate
this very topic.
>1) I believe they advise to manage security and authentication at the
>SOAP listener level (web server/Servlet engine), not at the EJB level.
>They strongly advise to not use EJB for business object modeling and
>persistence. Instead they advise to use other Java technologies like
>JDO.
That's interesting. Isn't EJB there for business object modeling and
persistence? Did I miss the whole point of EJB?
--
Cuplan (the great AMMM Acting Froup Lord).
"I was younger once, and I created a lie
And though my body was strong,
I was self-deluded, confident, and blind"
-Swans, "Blind"
walpj
> walpj <joe...@yahoo.com> wrote in message
> > [...]
> > The following whitepaper comes to the same conculsion after surveying all
> > available technologies.
> > http://www.orchestranetworks.com/us/solutions/0105_whitepaper.cfm
>
> After reading the paper, I believe that, on the contrary, they don't
> see EJB and SOAP as very complementary technologies.
>
> 1) They state that SOAP can't be used as a native communication
> protocol for EJB, because semantics of SOAP can't support semantic of
> the EJB distributed model. To me, this seems to be in total
> contradiction with what Tor wrote earlier in this thread.
>
> SOAP listener level (web server/Servlet engine), not at the EJB level.
> They strongly advise to not use EJB for business object modeling and
> persistence. Instead they advise to use other Java technologies like
> JDO.
>
Both of these statements are consistent with the paper. It suggests that
only some components of the J2EE platform are suitable for web services.
And as you note, they advise against inflicting on your project the
complexity and overhead of bean-managed persistence. However, that
decision depends strongly on the complexity of your business processes
and the sophistication of your development team.
> I believe SOAP and EJB compete at the "distributed" level. And I tend
> to agree that if you choose SOAP, then there is little interest in
> using EJB, because much of the EJB benefits are already provided at
> the SOAP layer (naming and discovery, distributed access, security,
> authentication etc.) and the rest is mainly object persistence in
> transactional stores, which is one of the weakest feature of EJB.
>
> Comments anyone ?
>
Yes, EJB w/ RMI fails (for the same reasons as CORBA) as an architecture
for distributed computing *between business entities* (i.e. the realm of
Web Services). However, for distributed computing within the enterprise,
message queues, CORBA and EJB w/ RMI will continue to provide better
efficiency and/or better business logic reuse. You know what they say;
use the right tool for the job.
That's the theme of OMG's new umbrella initiative.
http://www.omg.org/mda
Cuplan
>Both of these statements are consistent with the paper. It suggests that
>only some components of the J2EE platform are suitable for web services.
>And as you note, they advise against inflicting on your project the
>complexity and overhead of bean-managed persistence. However, that
>decision depends strongly on the complexity of your business processes
>and the sophistication of your development team.
Yes. Wouldn't container-manager persistence actually be a good help
up in a situation like this by lifting the weight of persistence off
the developer's shoulders? Again, I know this is prolly a real
"rookie question," but I'm still getting my feet wet.
>Yes, EJB w/ RMI fails (for the same reasons as CORBA) as an architecture
>for distributed computing *between business entities* (i.e. the realm of
>Web Services). However, for distributed computing within the enterprise,
>message queues, CORBA and EJB w/ RMI will continue to provide better
>efficiency and/or better business logic reuse. You know what they say;
>use the right tool for the job.
I'm sure the answer is in the whitepaper, but I don't suppose you
could explain why EJB fails as an architecture between business
entities. Also, when you say EJB w/RMI, is there another alternative?
EJB w/something else?
walpj
> On Mon, 13 Aug 2001 22:32:49 -0500, walpj <joe...@yahoo.com> wrote:
>
> >Both of these statements are consistent with the paper. It suggests that
> >only some components of the J2EE platform are suitable for web services.
> >And as you note, they advise against inflicting on your project the
> >complexity and overhead of bean-managed persistence. However, that
> >decision depends strongly on the complexity of your business processes
> >and the sophistication of your development team.
>
> Yes. Wouldn't container-manager persistence actually be a good help
> up in a situation like this by lifting the weight of persistence off
> the developer's shoulders? Again, I know this is prolly a real
> "rookie question," but I'm still getting my feet wet.
Container-manageded persistence has large conceptual weight. One reason
is that two transaction mechanisms exist. The developer must decide when
each each is appropriate and must know the syntax for each.
Container-managed persistence using entitiy beans can create extremely
large overhead if used unjudiciously. For instance, sending an object
from one physical machine to another using serialization extract a huge
penalty. Also, consider batch processes. An end-of-year program could
touch thousands of records. The cost is absolutely immense if an object
must, as an intermediate step, be created to represent each record.
>
> >Yes, EJB w/ RMI fails (for the same reasons as CORBA) as an architecture
> >for distributed computing *between business entities* (i.e. the realm of
> >Web Services). However, for distributed computing within the enterprise,
> >message queues, CORBA and EJB w/ RMI will continue to provide better
> >efficiency and/or better business logic reuse. You know what they say;
> >use the right tool for the job.
>
> I'm sure the answer is in the whitepaper, but I don't suppose you
> could explain why EJB fails as an architecture between business
> entities.
(a) firewalls (b) detailed interface contract must be negotiated by two
beurecracies
> Also, when you say EJB w/RMI, is there another alternative?
> EJB w/something else?
Sure. For instance, you can always use sockets and make up your own
protocol.
Cuplan
>Container-manageded persistence has large conceptual weight. One reason
>is that two transaction mechanisms exist. The developer must decide when
>each each is appropriate and must know the syntax for each.
>
>Container-managed persistence using entitiy beans can create extremely
>large overhead if used unjudiciously. For instance, sending an object
>from one physical machine to another using serialization extract a huge
>penalty. Also, consider batch processes. An end-of-year program could
>touch thousands of records. The cost is absolutely immense if an object
>must, as an intermediate step, be created to represent each record.
Again, prolly another rookie question here, but given what you've
said, what's the point of container-managed persistence? I thought
part of the point of EJB wasn't having to re-invent the wheel when it
came to database connectivity.
>> Also, when you say EJB w/RMI, is there another alternative?
>> EJB w/something else?
>
>Sure. For instance, you can always use sockets and make up your own
>protocol.
Wouldn't the development of some kind of standard be preferable?
walpj
> walpj <joe...@yahoo.com> wrote in message
> > [...]
> > The following whitepaper comes to the same conculsion after surveying all
> > available technologies.
> > http://www.orchestranetworks.com/us/solutions/0105_whitepaper.cfm
>
> After reading the paper, I believe that, on the contrary, they don't
> see EJB and SOAP as very complementary technologies.
>
> 1) They state that SOAP can't be used as a native communication
> protocol for EJB, because semantics of SOAP can't support semantic of
> the EJB distributed model. To me, this seems to be in total
> contradiction with what Tor wrote earlier in this thread.
The alternative to RMI that Tor mention will be built on top of SOAP
just as .NET calling semantics are built on top of SOAP.
Unfortunately, the two probably will not interoperate.
Incidentally, one difference between the two is likely to be the
inclusion of security context metadata only in the .NET semantics.
Tor Iver Wilhelmsen
> 1) They state that SOAP can't be used as a native communication
> protocol for EJB, because semantics of SOAP can't support semantic
> of the EJB distributed model. To me, this seems to be in total
> contradiction with what Tor wrote earlier in this thread.
It also contradicts the announcements from various EJB vendors and
technologists at this year's JavaOne conference. SOAP is an RPC
protocol, JRMP, IIOP, CIOP etc. are about the same thing.
> I believe SOAP and EJB compete at the "distributed" level. And I
> tend to agree that if you choose SOAP, then there is little interest
> in using EJB, because much of the EJB benefits are already provided
> at the SOAP layer (naming and discovery, distributed access,
> security, authentication etc.) and the rest is mainly object
> persistence in transactional stores, which is one of the weakest
> feature of EJB.
No, you're dismissing EJB as a programming model, where you treat
objects anywhere in the same manner as local objects except for the
purpose of creating them.
--
Tor Iver Wilhelmsen <to...@chello.no>
Shit happens. Everything else is illusion.
walpj
> >each each is appropriate and must know the syntax for each.
> >
> >touch thousands of records. The cost is absolutely immense if an object
> >must, as an intermediate step, be created to represent each record.
>
> Again, prolly another rookie question here, but given what you've
> said, what's the point of container-managed persistence? I thought
> part of the point of EJB wasn't having to re-invent the wheel when it
> came to database connectivity.
It's very useful for third-party beans that must encapsulate their
persistence requirements and scale transparently.
It's OK for enterprise business implementations as long as your
architects have a clue.
And it's great for systems with modest efficiency requirements. For
instance, maybe you don't *care* whether end-of-year takes three hours
or twelve hours to run. Or maybe you've reached resource nirvana by
choosing to work at a large bank. :-)
>
> >> Also, when you say EJB w/RMI, is there another alternative?
> >> EJB w/something else?
> >
> >Sure. For instance, you can always use sockets and make up your own
> >protocol.
>
> Wouldn't the development of some kind of standard be preferable?
Yes, but exceptional circumstances do arise. For instance, say that
one was writing a J2SE client that allowed a *dialup* user to browse
semi-real-time order info. In order to get beautiful response time,
the best way to pipe data to the client would be to stream it through
port 80, delimited using your own protocol. (One of my collegues
implemented this. It's pretty quick, but the code is extremely
fragile.)
Other possible alternatives to EJB w/ RMI include EJB w/ CORBA and EJB
w/ JavaSpaces. (Yes, these use RMI, but it's hidden.)
walpj
> samue...@hotmail.com (Samuel Fink) writes:
>
> > 1) They state that SOAP can't be used as a native communication
> > protocol for EJB, because semantics of SOAP can't support semantic
> > of the EJB distributed model. To me, this seems to be in total
> > contradiction with what Tor wrote earlier in this thread.
>
> It also contradicts the announcements from various EJB vendors and
> technologists at this year's JavaOne conference. SOAP is an RPC
> protocol, JRMP, IIOP, CIOP etc. are about the same thing.
>
To be fair to the paper, it really doesn't say that SOAP can't support
the semantic. Realize that the paper is analyzing web services. In
order to decrease the coupling between client and server, easy-to-use
web services won't expose object references and will limit data
structures to XML documents. The seeming incompatibility comes from
the fact that there's nothing built into the SOAP spec that enforces
or facilitates object references or application-level security.
<sarcasm>Therefore</sarcasm>, Microsoft and Java will implement
incompatible object reference semantics on top of SOAP.
Samuel Fink
Ok, after re-reading the paper and doing some research I think I see
where we are. I now understand that there is the standard SOAP, which
is interoperable among many implementations and that can't support the
semantic of the distributed method invocation of EJB for various
reasons, including the important one you gave: no support for object
reference. Then, it is possible for a vendor, using the SOAP extension
mechanism to produce "extended SOAP" messages, that can take care of a
more advanced semantic, but it will no more interoperate with the
standard SOAP.
I haven't yet found any announce from EJB vendor about using this
mechanism for doing EJB communication over HTTP. However, it seems
that it can be used by the ".NET Remoting" thing for communication
between two .NET distributed components. What I've found is BEA and
CapeClear providing standard SOAP wrappers for EJBs. But this works in
degraded mode: only works for stateless session bean and there are
many restrictions (obviously, passing object references like remote
interfaces is not supported).
-- samuel
walpj
> where we are. I now understand that there is the standard SOAP, which
> is interoperable among many implementations and that can't support the
> semantic of the distributed method invocation of EJB for various
> reasons, including the important one you gave: no support for object
> reference. Then, it is possible for a vendor, using the SOAP extension
> mechanism to produce "extended SOAP" messages, that can take care of a
> more advanced semantic, but it will no more interoperate with the
> standard SOAP.
>
> I haven't yet found any announce from EJB vendor about using this
> mechanism for doing EJB communication over HTTP. However, it seems
> that it can be used by the ".NET Remoting" thing for communication
> between two .NET distributed components. What I've found is BEA and
> CapeClear providing standard SOAP wrappers for EJBs. But this works in
> degraded mode: only works for stateless session bean and there are
> many restrictions (obviously, passing object references like remote
> interfaces is not supported).
>
See JSR-101.
http://www.jcp.org/jsr/detail/101.jsp
walpj
> where we are. I now understand that there is the standard SOAP, which
> is interoperable among many implementations and that can't support the
> semantic of the distributed method invocation of EJB for various
> reasons, including the important one you gave: no support for object
> reference. Then, it is possible for a vendor, using the SOAP extension
> mechanism to produce "extended SOAP" messages, that can take care of a
> more advanced semantic, but it will no more interoperate with the
> standard SOAP.
>
> I haven't yet found any announce from EJB vendor about using this
> mechanism for doing EJB communication over HTTP. However, it seems
> that it can be used by the ".NET Remoting" thing for communication
> between two .NET distributed components. What I've found is BEA and
> CapeClear providing standard SOAP wrappers for EJBs. But this works in
> degraded mode: only works for stateless session bean and there are
> many restrictions (obviously, passing object references like remote
> interfaces is not supported).
>
> -- samuel
See also this Java Live session.
http://developer.java.sun.com/developer/community/chat/JavaLive/2001/jl0821.html