Holy wars are fought and won one developer at a time...
join us for a trip through the trenches. There are no atheists in the
foxholes...
http://theserverside.com/discussion/thread.jsp?thread_id=3456
SOAPnXML vs EJB
Posted By: Emad Benjamin on January 15, 2001
Well!
Anyone out there has been following up on the the next tech leap ahead of
"Web Services" and how they are facilitated through some XMLish transport
mechanism, must be thinking, well what about all these years that we have
been forging ahead from half decent middle tier object transport protocols
to some thing mature as EJB container implementration, where does
SOAP/XML/XAML, etc. leaves EJB?
Do you really need EJB in two years time if XML by then will provide you
with almost all the functionality of a mature container, remeber how EJB
edged IIOP out, although it started from behind in the race, are we
witnessing this all over agin with XML marshalling of Objects. Where will it
all stop, anyone with thoughts on this, and how to startegically position
company architecture to reap in the benefits of "Werb Service", please write
back I'd like to hear your thoughts on this.
Thanks,
Emad J. Benjamin.
7 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Dave Wolf on January 15, 2001 in response to this message.
1) EJB has not edged IIOP or CORBA out. Actually the newest version of EJB
are very very CORBA like and include the use of IIOP
2) XML a file format not a framework for distributed computing. Its is also
IMHO a very heavily overused format. The biggest benefit to XML is that it
is self describing so it is easy to use as a data exchange format for things
like EDI where neither side uses identical data formats. How many
applications really need this?
3) I think there is alot of room for the growth of design pattenrs in how we
effectively marshall information over networks.
Dave Wolf
Internet Applications Division
Sybase
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Robert McIntosh on January 16, 2001 in response to this message.
I agree with Dave on this one. XML/SOAP/etc is not a replacement for EJB. I
think there will be more integration between the two as time goes on. XML is
a way for different systems to share data, meaning you could have an EJB
sever talking to a BizTalk server, talking to a CORBA based server, etc.
SOAP is one really slick way of having these systems' objects talk to each
other and send data without having to know what the other side is developed
as.
XML is a good way to marshall objects between these systems, since they can
all read XML. As long as the format of the XML (via Schemas perhaps) is
agreed upon between the systems, you have object system talking to another
one and knowing none of the details of each other's implementation.
Robert
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Emad Benjamin on January 16, 2001 in response to this message.
I agree with point one but that is because Sun had decided, roughly about
two years ago to support IDL, in waking up to what Visigenic had already
been doing through their Caffeine product. Had they not done that, it would
have been a completely different story here, I know sun is so focused on
J2ee that they are missing the larger picture focus for XML, although they
have included XML as a component in the stack, they havent embraced it like
the other big guns. So, what will Sun do to reap in the next leap ahead of
"Web Service" architecture, the big guns are talking about XML Beans for
persiteance, XML/XSL for presentation, XAML/SOAP for transportation, that
sounds like a lot of duties for what seems to be a simple/sophisticated
markup language.
Sun will do something about this in a big way more than what they have so
far, and they will do it through their EJB architecure, just like it
introduced JMS EJBs to reap into the publish/subscribe architecture markets.
So what will it be, when, and how?
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Lee Fuller on January 17, 2001 in response to this message.
I think the original posters point is this:
1. EJB is used for portability reasons. There is an accepted performance
cost to this, which is evident by the lack of TPC entries for EJB-based
architectures. Native application servers (e.g. CORBA, COM+...) provide a
much more performance orientated system.
2. SOAP and web services (incl UDDI) provide an open way of providing
interfaces to all systems. Given the non-EJB versions of the same
application servers provide higher performance levels, then will a
"native-app-server + SOAP" pattern sideline the reason for EJB existing?
Personally, I think the web service pattern makes a lot of sense and
performance cannot be ignored within a server-centric architecture.
Lee.
2 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Emad Benjamin on January 17, 2001 in response to this message.
In response to Lee Fuller's comment on performance.
I think you have touched on exactly what I was saying in my original message
with your second point, about if "XMLish/SOAP base web service architecture"
will EJB be just as valid? But of course we know that the current XML based
system performance is very sluggish, and this where technilgies like fast
XSLT/XPath, or intelligent XML Parsers will have to forge ahead and imporve
on XML's current state of runtime performance. If peformance improves in
XML, and Sun doesnt do anyhting to reap this "Web Services" leap ahead, then
yes EJB will be edged out. But as I said earlier Sun will act to save its
day.
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Dave Wolf on January 17, 2001 in response to this message.
Sorry I disagree. I dont see how XML a data transport format, can edge out
EJB, a distributed computing model. They are even in competition. If
anything, XML file formats may be used as heterogenous data format for data
exchange across systems, but it will never fill the shoes of a distributed
computing model. What about tx management, business rules implementatin,
etc. Its like saying that cars will replace oranges. They arent even in
competitiion, although you can fill a car with oranges.
Dave Wolf
Internet Applications Division
Sybase
3 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Pranab Ghosh on January 17, 2001 in response to this message.
I agree. The two technologies will complement each other.
SOAP and XML will connect the enterprises across internet,
whereas ejb will be used for building distributed apps running inside the
enterprise. SOAP and XML will connect the islands of ejb apps to provide the
the so called
Web Services.
Pranab Ghosh
Independent Consultant
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: sridhar visvanath on January 18, 2001 in response to this
message.
I think you have not got the point that Benjamin is trying to drive at . You
are just taking one side of the argument .
He says that XML/SOAP with some other model (say COM) can replace EJB in the
near future ,
I feel that there are possibilities for that .
COM + XML/SOAP > = EJB
is the question and I feel that this equation is possible
But , SUN will definitely wake up to this , towards that
Sridhar Visvanath
Consultant
Netacross Ltd
2 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Robert McIntosh on January 18, 2001 in response to this message.
I like Dave's comment about cars and oranges.. I hope you mean to say that
EJBs are the cars, and XML is the oranges :-)
As for other comments on performance, to a point I can agree, but for most
applications, such as messaging, or 'lite' data transfer, the performance
hit isn't that big, at least not in what I've seen used. When you get into
really large xml structures, sure you take can take a big hit, but you have
to have a pretty good size XML document to really notice, especially on
todays hardware. I've seen serialization of object graphs that were up to 5
levels deep and several hundred objects in the graph and you would barely
notice it, and that was with DOM.
Robert McIntosh
Trainer/Consultant
The Middleware Company
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Emad Benjamin on January 19, 2001 in response to this message.
WRT Robert McIntosh's comment on Performance.
The way in which XML is being promoted as THE language/format of data
exchange, I recently worked (not to mention company names) on a project
where XML was used in a market feed situation, for almost realtime data
feeds, and the system was taking a big hit due to XML, of course I will not
go into the solution that helped the company speed up the XML translation,
as it is proprietary to them. But be aware of using XML everywhere. This is
not to say that I dont believe in the future of XML, actually I do, we just
need to see a little more performance from it, could be 6months to a year
from now.
Again peformance enhancements are just a matter of community support, all of
the big technolgies went through it, like Java, C++,etc. they all take time
to mature, and what XML has going for it is the community support, and this
is why I'm betting on it, but with caution in terms of where it is used in
current real business applications.
Thanks.
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Miroslav Samoilenko on January 19, 2001 in response to this
message.
The point of Emad's original message is really that XML/SOAP like languages
(protocols?) actually substitute RMI and hence kill EJB as the model for
distributed applications. You can easily use regular JavaBeans to build an
application, and if you need to call a method from another bean, just send a
SOAP message and work out the response.
As Sridhar rightly pointed, with his formula is that EJB is no longer *the*
choice for distributed computing, but *a* choice. You might use COM, DCOM,
EJB, or JB and rely the distibution part of the application on SOAP.
Miroslav
Principal Consultant
Oracle Corp.
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Dave Wolf on January 20, 2001 in response to this message.
But what your missing is that RMI is not EJB. Its the container that makes
EJB not the protocol. Whos gonna grab that SOAP message, instantiate the
bean, handle its lifecycle, cache connections, handle security, manage the
transaction, etc. So when you just apss this SOAP message to some simple
JavaBean, whos gonna make this all work? You wanna write all that?
EJB is a framework, SOAP is a protocol. A protocol does not compete with a
framework.
Dave Wolf
Internet Applications Division
Sybase
2 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Dag Blakstad on January 20, 2001 in response to this message.
SOAP is not a replacement for any component standards, but will facilitate
integration between different systems. The platform and programming
languages used in each system will not be important in this respect.
This means that each party participating in an integration or web-service
implementation can use the best suited architecure inside their environment.
SOAP will also provide a way of passing messages through a firewall, with
all the benefits and security issues this implies. It is great for
integration, but bad for security. RMI/IIOP/COM communication is not allowed
through most firewalls today. SOAP will therefore enable implementation of
many applications/interactions not possible today.
There are also some alternatives to SOAP, but these are not implemented or
in a state that, so that they can be used in production applications:
http://www.sun.com/research/brazil/
http://www.xmethods.com/
Dag Blakstad
TietoEnator Consulting AS
http://www.tietoenator.com
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Billy Newport on January 20, 2001 in response to this message.
Dave is right,
EJB is an infrastructure for developing server side components. EJB 2.0
containers will be able to support both synchronous and asynchronous
protocols to access these components. We've seen several protocols bridges
to these components so far: RMI, T3 from WebLogic, RMI/IIOP and now JMS
(Message Beans). You can expect to see SOAP being added to this list by
vendor implementors. I don't see why Sun need to be involved at all.
The container provides several advantages to its developers, transaction
management, security, resource management (pooling, throttling) and (very
importantly) it provides a standard that tooling developers (read IDEs) can
use so that we get nice tools to write and develop the applications.
It also provides an interface to the underlying infrastructure that should
allow other middleware products such as message brokers, workflow systems to
be built on top. This one advantage is a very important one for me and is
probably how vendors will charge premium prices as EJB servers become more
'vanilla'.
SOAP is basically the equivalent of GIOP in the Corba world. HTTP/SOAP is
comparable to IIOP or RMI over IIOP. SOAP and GIOP specify how to marshall a
method invocation/service request into a binary representation. GIOP has
mainly performance advantages over SOAP here. SOAP is more flexible in terms
of interface brittleness. Remember, you could transport GIOP over HTTP if
you wanted. HTTP/SOAP and IIOP just specify how SOAP or GIOP is transmitted
over a specific transport.
IIOP has extensions like OTS that also allow distributed transactions. This
aspect doesn't seem to be address by SOAP currently.
HTTP/SOAP should really be compared solely against RMI/IIOP or just IIOP.
But anyway, I hope the point is clear. You still need a component model and
a runtime environment that allows runtime loads to be managed/throttled and
allows a tooling market to develop supporting it and this is what an EJB
container (or for that matter, COM+) runtime gives you today.
2 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Dave Wolf on January 20, 2001 in response to this message.
Great clarification Billy. I agree irt SOAP vs IIOP as a more fair
discussion point. BTW, as an aside, in Sybase EAServer we do indeed support
not only straigh IIOP but also marshalling IIOP right over HTTP as you
mention. Well, you might say tunneled within HTTP but thats all from your
point of view :)
Dave Wolf
Internet Applications Division
Sybase
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: david olivares on January 22, 2001 in response to this message.
I had a dream about SOAP servers becoming more and more popular and XML
evolving from a self-contained data trasnport "protocol" to a language able
to contain data as well as behaviors. XML msgs evolved to agents. Microsoft
had also integrated SOAP servers in everyday's desktop computers. EJB server
were nicely integrated with all this.
is XML being used for what it was really ment to be used?
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Emad Benjamin on January 23, 2001 in response to this message.
General reply to add to all comments.
I know that EJB Container is an implementation of all the middle tier
services for the runtime environment of distributed object, very much like
IIOP with Corba services prebuilt and implemented. I am not trying to
compare EJB to a protocol, in fact what I am trying to highglight is that
almost every mechanism begins with a protocol, then it grows into what they
call them these days, Application Servers. Just look at how this XML beast
is growing in Persisteance, Presentation, and Marshalling, it has some
serious coverage of technolgy domains.
Just picture this that in 1yrs time MATURE AppServers will appear that are
SAOPnXML complient, what will happen to enterprise development then? why do
I have to carry EJB and SOAPnXML? I think alot of NEW developments will look
at SOAP/XML as a solution, especially if the XML performance improves, then
you will be measuring EJB vs SOAP/XML performance, and I think it wont be
long before you see SOAP/XML peformance approach that of EJBish based
architectures. I mean we all know EJB is sluggish on peformance, any true
middleware engineer knows that. Having an alternative to EJB, is in a way
reducing EJBs market share. That is my point.
Cheers! and more later.
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Stu Charlton on January 30, 2001 in response to this message.
"Any true middleware engineer knows that EJB is slow on performance."
Depends on the application server. Most EJB implementations have
traditionally been poor, though lately they've been better. The spec
certainly has problems in some areas, but generally this is a reflection of
the difficulty in designing a scalable distributed object system.
In short: EJB's are only slow if you don't know how to design a system to be
fast.
Furthermore, I really would like to see what you think will replace EJB. I
personally enjoy competition and would like to see an alternative. The
problem, however is the following:
- Replacements aren't standards. EJB and the J2EE is a standard across
vendors. EJB goes beyond "communication protocols" -- it goes into how one
trains & hires developers, what design patterns are used, etc.
The biggest benefit of EJB isn't that you can interoperate with CORBA --
it's that IT shops don't have to suffer vendor lock in or deal with a dearth
of skilled developers on a particular app server. The market becomes less
fragmented this way.
- XML/SOAP/UDDI/WSDL are all great protocols to make things interoperable,
but it remains to be seen if there will be a new breed of application server
standards behind this. On the face of it, it makes little sense -- we
already have two: .NET and EJB.
So, in short, if XML/SOAP app servers will make EJB obsolete, it will mean
that either
A) the industry en masse embraces .NET and ditches their UNIX and mainframes
for Windows 2000 PC's
B) .NET is ported to UNIX by late 2002 and corporations adopt it by mid
2003.
C) The industry en masse adopts proprietary application servers, eschewing
the benefits of a standardized API / skill set.
A & B are unlikely. C is likely only if some *very innovative* and highly
marketed application servers come out within the next 2 years, that support
the integration XML/SOAP. I'd love this. But as a realist, I'm pretty
skeptical this will happen.. and inertia may kill any innovation anyway.
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Jay Zou on January 30, 2001 in response to this message.
The XML will not roll over EJB and EJB is not and will not roll over IIOP.
EJB will be based on the IIOP (default setting of EJB 2.0 spec). XML will be
used for inter-enterprise applications or web services while EJB will be
used for internal enterprise applications or intranet services. This is due
to the fact of the different ways to manage the security, performance and
interoperability.
Jay Zou
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: MANISH LOHAR on February 1, 2001 in response to this message.
Reading all this great discussion you guys have going,one thing comes to my
mind.XML started as a platform independent data format and Java being the
plat' independent prog'ing language with EJBs( the sophisticated
transactional,scalable and what other adjectives have you) there was a sort
of completeness.
But XML has already made rapid strides into all the tiers of a typical
application.XML/XSL/XML-FO on presentation,XML/RPC/SOAP on middle tier and
XML/RDF/XMI and databases which store and serve XML directly ond XML
supported databases.
But given the state of today's net environment and diverse software and
hardware,it is more challenging to integrate, connect and enhance and
performance tune applications then to build applications from scratch alone.
There are whole set of different issues of
connectivity,performance,distributed transactions,security etc. It becomes
all the more important to loosely couple applications when they talk to each
other so that a tremor( change) on one is not felt by another. I think
XML-SOAP or RPC can do a great job at that. EJBs I think can still benefit
by using XML serialization/marshalling as an alternative.That way they can
still remain compatible with IIOP talkers and newer XML apps.
XML, I don't think presents a threat to EJBs existence in near future unless
every one decides to go top gear on XML and use it blindly everywhere
(including modelling business rules in XML,persisting business data in
XML,making XML messages transactional,modelling enterprise security in XML
etc) and phase out EJBs and that is very unlikely.
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Steven Cockerill on February 2, 2001 in response to this message.
Billy,
I think the other thing we also need to consider is that the reason why SOAP
is being used is because it runs on HTTP. We should consider that in the not
too distant future there will be/are other protocols more suited to
Broadband use other than HTTP and that firewalls will allow "trusted" non
HTTP protocols to go through them such as those used in conjunction with
EJBs. Where will that leave SOAP when other programming paradigms can, do
and will use other protocols.
Steven
2 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Billy Newport on February 2, 2001 in response to this message.
Absolutely, thats the point. SOAP is merely a transport. You still need a
runtime infrastructure to process the requests arriving and J2EE and .net
are currently your two alternatives for implementing this infrastructure.
Does anyone know if any company has implemented the OMG Corba component
model yet?
2 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Dave Wolf on February 2, 2001 in response to this message.
Billy,
As far as I have understood the OMG component model is not yet complete. We
would consider implementing it upon its completion. Do do intend to fully
support EJB 2.0 and J2EE 1.3 interoperability however.
Dave Wolf
Internet Applications Division
Sybase
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Michael Brown on February 6, 2001 in response to this message.
SOAP/XML/EBXML/XMLRPC and EJBs can coexist for this very simple reason.
SOAP(et al.) is a messaging protocol. EJB is an application architecture.
Think of SOAP as HTTP, TCP, EDI or what have you and think of your EJB
Server as a web server.
In regards to the comment about Java/EJB giving a performance hit, I have a
few points to make. When Java first came out, the high-end desktop was a
Pentium 100 with 16 Megs of RAM. Today's high-end desktop is more powerful
than the high-end server of five years ago. Consider this, in 1995, my
high-end computer would take about an hour to create an image using POV-Ray.
My 866 AMD Athlon can create a five minute animated scene in the same time
today. Five years ago, I would have agreed with you about Java's performance
hit on the server side. Today the performance hit is negligible. As a matter
of fact, the bottleneck for a web application today is the webserver (of all
things).
So to sum it up, no SOAP/XML will not replace EJBs/J2EE, they are actually
quite complementary together. And no, Java does not create a noticeable
performance loss as opposed to a native application. (Consider that today's
high-end server is a Dual Pentium 4 1.5ghz with 2+gb of ram and [name your
amount] of storage.)
J2EE and SOAP will be the vanguard in providing B2B digital communication.
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Michael Brown on February 6, 2001 in response to this message.
Here is another funny matter regarding performance. Microsoft's .NET
platform will run on a virtual machine (a la Java). Microsoft is actually
following Sun's(Java's) lead in this case. Java's advantage is the "Write
once, run anywhere" motto. Java allows a corporation to choose its own OS,
its own hardware. MS does not...currently. MS is promising to port the .NET
virtual machine to other OSes. But as it stands, MS is behind the race.
Currently the two competitors for Enterprise applications line up like this
<table><tr><td><td><b>Java</b><td><b>MS</b>
<tr><td>Operating System<td>Pick an OS<td>Windows NT
<tr><td>Programming Language<td>Java<td>Pick a language
<tr><td>Framework<td>EJB<td>COM+/.NET
<tr><td>App Server<td>Pick one<td>MTS
<tr><td>Database<td>Pick one<td>Pick One (SQL Server preferred)
<tr><td>Web Server<td>Pick one<td>IIS
<tr><td>Web Script<td>JSP<td>ASP
<tr><td>Web Components<td>Servlets/Applets<td>ISAPI/COM/Activex
So as you see, Java's advantage is the number of choices it allows. Of
course most companies tie themselves to a particular platform anyway. But at
least you're not forced into one.
MS has a big advantage in that it allows any language for programming. But
Java has a head start. You choose.
Michael
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Michael Brown on February 6, 2001 in response to this message.
As a final side note: I recently finished a project for a very large
company. They were gung ho about soap, java, and EAI. We built a development
kit that provides a SOAP interface to legacy apps with minimal programming
required.
The company wanted to support using SOAP over multiple protocols (not just
HTTP). One of the protocols they wanted to support happened to be RMI. Now
if anyone knows about RMI (which I hope is the case for most of you) you
will see the irony of it all. We transformed a full-featured RPC protocol,
into a transport for another RPC protocol. (The interesting thing to note is
that it is very fast and robust even in production.) It gives hope for using
SOAP within the J2EE platform. Would someone go ahead and make that SOAP
EJB? I'm too lazy to do it myself ;)
Michael
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Michael Brown on February 6, 2001 in response to this message.
HTTP tunnelling of EJB calls is up to the App Server vendor. Weblogic 6 does
allow HTTP tunnelling (IIRC). By the way, EJBs can be RMI or CORBA based,
it's up to the vendor. Also, RMI does currently support IIOP...so really the
only oddball is COM as far as Server Side Components go.
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Nick Minutello on February 8, 2001 in response to this message.
WHAT'S IT ALL ABOUT ?????
There seems to be a bit of confusion as to what XML, SOAP, RMI, IIOP, EJB
and DCOM are all about (although some people have pointed out the facts)
(Apart from that, I have a few SERIOUS QUESTIONS on the validity of SOAP's
fanfared "benefits" .... if you want to go straight to that, scroll towards
the bottom of the message...)
Firstly, COM, RMI and CORBA are distributed object models. They neither
define a PROTOCOL or DATA FORMAT nor do they define an application
framework.
It just so happens that CORBA is done over IIOP and Java RMI can be done
over JRMP and IIOP. Equally, either of these could be implemented over SOAP.
(look around the omg site for SCOAP).
EJB (which incidentally is a subset of CORBA3's Component Model) as well as
Microsoft MTS is an application framework. While this framework *may* not be
as performant as raw Java/C++ applications, they are very quick to develop
business applications on because the services (distribution, lifecycle,
persistance .... etc) is all done for you. The theory is that you just write
busines logic.
Just to clarify the oft confused associations between the above
technologies:
RMI-IIOP is part of the framework of EJB is which is used for the
distribution of objects (Microsoft use DCOM for MTS).
So, in summary, if SOAP is in competition then it is with DCOM, JRMP and
IIOP. Anything else is comparing cars with oranges (as was mention above)
NOW. SOAP!!!!
SOAP stands for Simple Object Access Protocol. I know that everyone probably
knows that BUT, the first word is the key one that everyone seems to forget
when comparing it to the likes of DCOM and IIOP.
Firstly, SOAP is a great lightweight RPC or messaging protocol. It has low
overhead and is infinitely flexible.
However, what happens when you want some sort of propagation of security
context or transactional context? What happens (as in the case of DCOM and
JRMP only) that you want to have some sort of distributed lifecycle
management (distributed garbage collection)? Pretty soon, SOAP becomes COAP
(complicated OAP). Once you want (and you will want it) start having to
marshall and unmarshall similar amounts of *native* data, then SOAP becomes
very expensive on the processor (as marshalling is inherantly more expensive
to parse/marshall) and on the network (the ascii format can only ever amount
to more data down the pipe).
Basically, once your message payload reaches a certain size the
"lightweight" nature of SOAP is lost as it is now more expensive on the
processor and the network as its "rivals".
What are some of the other "benefits" of SOAP?
1) Platform independant ?
The one big thing going for SOAP is the fact that Microsoft
happen to be embracing it and therefore it *could* be a bridge between the
Microsoft world and the J2EE world (as well as the rest of the world!).
HOWEVER, beware of microsoft's method of standards adoption. The track
record on Java & LDAP is evidant and it is likely that XML/SOAP will go the
same way.
2) Language independance?
IIOP is pretty language independant, as is DCOM. SOAP is arguably more so (I
realise that) but for how long? (refer to point 1)
3) HTTP, hence no firewall issues ?
One of the nice features of SOAP is that it is over HTTP and therefore it is
easily encrypted (SSL) and it passes through the HTTP port on almost every
firewall in existance with no extra effort.....
All this is true - but now, in a similar way that JRMP, DCOM and IIOP are
frowned upon by IT Security, so too will SOAP. Allowing SOAP, or in fact any
RPC or messaging protocol unhindered through a firewall will become a
serious security risk and a big hole in the firewall.
Therefore, will security on our favourite HTTP port be clamped down as it is
for DCOM and IIOP ?
My firm belief is that JRMP, IIOP and DCOM(well, ok, DCOM is a little nasty)
should have an equal status in importance when it comes to firewalls.
Designing your entire distributed object model (and hence, your e-business)
around a firewall seems a little like the tail wagging the dog to me...
4) No need for proxies ?
All the distributed object models pivot upon the same implementation. There
are client-proxies that communicate with server-skeletons (over either
IIOP,DCOM or JRMP) in order to hide the distributed nature of the objects
from the developer. The developer just calls the methods on the proxy
object.
Well, if we use SOAP, where do we gain? We have an XML parser/formatter for
the payload (just like IIOP marshalling) and unless we implement the
RPC/messaging ourselves, we will have "helper" classes that convert method
calls into XML...... er, isnt that a proxy?
Dont get me wrong, I think that SOAP has a place for lightweight messaging
and rpc. However, IIOP is a distributed computing protocol that has evolved
over some considerable time and encapsulates lots of inputin the form of
collective knowledge and experience gained from all quarters of industry.
Protocols like IIOP are around for a reason .. and will continue to be so.
All that said, I am no expert on XML. There may be something - some key
concept - that I have missed. If so, I would be happy for that to be pointed
out to me.
Cheers.
Nick Minutello
No-one in particular
2 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Nick Minutello on February 8, 2001 in response to this message.
Errata
When I said:
"as marshalling is inherantly more expensive to parse/marshall"
what I *meant* was:
"as **XML** is inherantly more expensive to parse/marshall"
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Justin Grant on February 8, 2001 in response to this message.
"the ascii format can only ever amount to more data down the pipe"
SOAP payloads can be compressed and ascii compresses VERY nicely. In fact on
a recent project this was used and was very successfull in improving the
performance of the application.
The compression had no significant impact on the performance.
my 0.02c worth, anyway
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Nick Minutello on February 10, 2001 in response to this message.
What you say is true.
However, compression/decompression adds even more cpu expense to the the
already high cost of the XML parsing/formatting.
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Colin Geis on February 12, 2001 in response to this message.
Thank you Michael!
I fail to see why people are so set on pitting SOAP/XML against
J2EE/EJB/Java. That is, unless there are alterior motives behind some of
these responses. For example, how many of these responses are by those who
stand to gain from the adaptation of SOAP.
SOAP and XML are simply additional technologies to add to a software
developers "bag of tricks" (along with HTTP, Java, EJB, etc.) to help solve
software development problems. There will always be more and newer
technologies. The only distinction is who is backing them.
If I am a Microsoft/COM developer and EJB/Java offers the best solution then
I would be doing my employer a dis-service by not proposing EJB/Java as a
solution. Likewise if I am a Java developer and SOAP/COM offers the best
solution I would be doing the same dis-service. Then again some combination
of SOAP, COM, Java and EJB might offer the best solution. Of course, there
are other reasons why particular technolgies are chosen but lets continue to
keep this discussion focused on the technolgies themselves.
Colin Geis
SUMmedia
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Nick Minutello on February 13, 2001 in response to this message.
I agree with you that there is some confusion about where SOAP lies in
relation to other technologies. However, I think this has largely been
explained away by the end of this thread.
Moreover, I dont see SOAP as a Microsoft/COM issue either (however, they
have backed it very heavily to the exclusion of all else).
My main question is why SOAP seems to be such a flavour of the month
compared to other established RPC/messaging systems. My primary question
(see 4 posts above) revolves around whether XML is suitable for the
marshalling format of RPC or messaging.
My argument is that it is fine for *simple* message/rpc calls - however,
rarely does anyone have simple requirements. As soon as you have any one of
the following: large payloads, requirements for transactional context,
authorisation, security then SOAP's trumpetted advantages dissapear. ... and
none of these requirements are all that exotic - they are everyday
requirements.
The other issue, which I have struggled to find much discussion on are the
security implications of letting SOAP flow unhindered through the HTTP port
on firewalls. One of SOAP over HTTP's much trumpeted advantages is that it
is meant to work seamlessly with almost all firewalls known to man. However,
how SOAP is going to be secured (at the firewall) is a big question I havent
seen asked a lot - let alone answered.
Nick Minutello
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Alberto Gomez-Corona on February 14, 2001 in response to this
message.
I beg you pardon for talking at a different level but I think it is
necessary to start from fundamental concepts:
XML and the XML DOM, As well as the XSLT ara about list and tree habdling,
the best know example of a previous technology is the LISP language, which
handles s-expressions. I wanted to see the Web as a repository of structured
knowledge in the form of s-expression to be managed by lisp like languages.
Now this is being done by XML and the XML handling languages.In fact this
description is according with the Semantic Web initiative, from the Web
creator, Tim Barners Lee.
XML permits message passing, which permits streamed processing (which is
indeed importand for scalability). XML also have class publication(trough
DTDs and XML schema), which ideed facilitates standardization. It is also
easily extensible by its own nature, without affecting the XML handling
logic. A XML document can be verified against his DTD or XML schema, so the
standardization is less prone to human interpretations.
SOAP, on the other side, is function call oriented, and as such, is API
oriented , as is any Object oriented framework, like EJB. The
standardization of a growing quantity of APIīs is a serious concern, since
there are no standar to describe APIīs, no automatic verification of object
definition against the standard and so on. the standardization problem grows
when the boundary to be stadardized is stateful.
Function call oriented interfaces have no streaming capabilities, since the
called function starts upon the complete list of parameters arrive. -Unless
one of the paramenters points to a stream (hopefully,a XML stream), which
reverts inded to a message passing interpretation of the stream-.
My bet is that the inherent superior flexibility, expresivity and ubiquity,
accesibility and standardization of XML will lead to more and more
processing to be done in the streamed document side, rather than into the
function calling side, with less APIīs and more document definitions. (a la
MS Biztalk server)
Of course, even, transaction management, load balancing services and so on
are needed.
So object frameworks, plumbing services and even OSīs and computers will
survive.
(sorry for my bad english)
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Wojciech Ozimek on February 14, 2001 in response to this message.
I do agree with Dave. EJB specification is not about components or
protocols, but it's about container - the server side mechanism for handling
concurrency, persistency, sessions etc. It's the whole framework. This
framework services can be used using any kind of protocol (it may be SOAP
for example).
Regards
Wojtek
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Alberto Gomez-Corona on February 15, 2001 in response to this
message.
I see XML processing usage to gain growing extension from presentation and
inter service communication to storage, inter process , and finally, to the
core of the bussines processes, the middle tier.
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Kevin Buhr on February 22, 2001 in response to this message.
Always enjoy Dave's comments. I was confused about the comparison between
XML and EJB. I can see comparing EJB to stuff like CORBA/COM/RMI or at least
talking about them in the same context. Guess I am still learning about XML
but it seems to me that XML is just a way for people/computer systems in
diff. companies to send info. to each other over the internet. Once the
info.(XML) has been sent the receiving end would then use servlets/jsp with
EJB(s) to handle the data. I know that XML is used in the deployment
descriptor. But again the XML is just info. not logic.
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Luc Peerdeman on February 23, 2001 in response to this message.
I seem to remember SOAP may also be run over other transports than HTTP. The
docs with the IBM implementation on Alphaworks at least talked about for
example email transport.
So I think it will be no problem adapting SOAP to new protocols in the
future, it can be done.
Luc.
0 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Alberto Gomez-Corona on February 23, 2001 in response to this
message.
Let me explain please the disadvantages of function call oriented network
data interchange approach, such is RMI, CORBA and SOAP compared with pure
XML message interchange:
1 once you add a new parameter, you have to communicate it and recopile the
IDL, the code to manage it (on both sides).
2 no streaming possible. in case of very long messages, the hack is to split
the message, to create a protocol to send record by record and so on.
none of these problems are present in a XML document exchange:
1 once you have all the parameters embedded in the XML document , and the
handling logic in both sides, the addition of a new parameter element in one
side does not break the other side, if both sides uses the XML DOM. It is
possible to interface the new service with older client versions. What
communication protocol does that?
2 streaming comes naturally in message based interchange methods.
streamed processing is also a very good feature. (for how long have you been
using Unix pipes, before the object oriented invasion?)
XML solve all the problems of message passing communications, and keep the
advantages. To encapsulate the power of structured document interchange in
the strech methaphor of a matematical funcion invocation is a forced way to
understand computer communications.
what is seen in both points are applicable to any data interchange and any
data definition.
Iīm sorry if I am taking a radically different approach, but it is for me
necessary to express that the object orientation paradigm, as now is
understood, is not the better approach to solve every computation problen .
Alberto Gomez Corona. Ibermatica.
1 replies in this thread Reply
SOAPnXML vs EJB
Posted By: Alberto Gomez-Corona on March 2, 2001 in response to this
message.
I wonder if my previous messages have been the cause to justify this
silence.
May be because I express some ideas far away from the programming context in
which you used to be involved.
To concile messages, streaming and object orientation, I can say that in the
original object orientation methapor definition, as was defined in the Xerox
laboratories in which the Smalltalk language was born, the objects
communicate between themselves by interchanging __messages__.
May be these interchanged messages based on XML?, May these messages be
streamed, optionally, at least ?.
My response is: it would be better that way. it whould be a better way to
communicate computers processes. It whould be a better object oriented
framework.
The next point is to define the objects themselves as XML descriptions , or,
to be short, as XML documents. Why? Because XML has better tools for
standardization and checking the conformance with the definition, XML has
better extensibility too.
Thatīs part of what I call distributed document computing.
I hope to contribute with that to make think on what for me is the true
problem: the wrong idea to extend a _particular_ vision of object
orientation to network communications programming.
Such vision is based, and promoted, by the OO implementation of the
mainstream languages, such is C++, Java etc, which assimilates message
interchage to function calls whcich are implemented in the context of a
single machine, with a shared, fast memory stack which store the call
parameters.
In the network, there is no shared memory stacks, so, we need a paradigm
shift (whatever this means).
Iīm looking at lisp and prolog based languages, which promotes a different
taste of object programming. (and, of course, to XSLT)
Sorry If I have been too categoric.
I want to hear about some of this stuff, just to check if my arguments
areīnt crazy enough to make sense for you.
---- Adam@KnowNow.ComVibeology. Now you ask, what does it mean? Why, it's the study of the chemistry between you and me! -- Paula Abdul, "Vibeology"
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:13:20 PDT