Re: SOAP vs. J2EE

[George I Matkovits <ma...@qwest.net>]

JMS has a 'free' implementation over HTTP. Also a JMS wrapper for MQSeries is
also available from IBM (MQSeries can be bridged to MSMQ, only within a LAN).
SOAP is great for Java/MS inter operation. For 'reliable'  and 'scalable'
Enterprise messaging I would use JMS over HTTP and I am a true 'SOAP' bigot! :-)

I also use J2EE. I am an engineer and IMHO NOBODY invented the universal
programming unswer to all and everything, yet! (42?)
Regards - George

Peter Glynn wrote:

> I definintly agree with Anne
> - if your looking for an enterprise scalable performance minded system go
> for ejb's (Enterprise Java Beans) because of the lovely features that Anne
> has described. If your looking for a book I recommend "Java Server
> Programming" which covers all of J2EE or even Java Enterprise in a Nutshell.
>
> - it is a matter of SOAP and J2EE not SOAP Vs J2EE.
> Although a ejb server can be use as a distribution technology locally - ie
> on the same LAN which is far more efficient to use then SOAP. So if you what
> to implement a distributed system maybe use the approach of anything local
> (on same LAN) use ejb server / RMI (J2EE) and anything global (on the
> Internet) use SOAP. Would people agree.
>
> ----- Original Message -----
> From: "Anne Thomas Manes" <at...@sun.com>
> To: <so...@xml.apache.org>
> Sent: Wednesday, March 28, 2001 3:10 AM
> Subject: RE: SOAP vs. J2EE
>
> > It's not a question of one versus the other. Since you need a cross
> platform
> > solution, I'd recommend that you use Java. So the answer is: use both SOAP
> > and J2EE.
> >
> > SOAP is simply an XML messaging protocol. The code that implements the
> SOAP
> > service has to run somewhere -- for example, in a J2EE application server.
> > Most Java-based SOAP implementations are based on J2EE (Apache, IBM, Cape
> > Clear, etc.)
> >
> > The question you want to ask yourself is what type of an application
> server
> > do you need. Will a JSP/servlet engine suffice? Or do you need a
> full-blown
> > EJB-based application server.
> >
> > Both servlet and EJB application servers manage resources for you, such as
> > database connection pooling, session management, and some degree of load
> > balancing. JSP/servlet engines are great for moderate-sized applications,
> > but they often don't provide super-high-scale features such as
> > multithreading, sophisticated load balancing, and bullet-proof fault
> > tolerance. An EJB application server provides these services as well as
> > automatic transaction management, state management, security, and
> > (optionally) persistence management.
> >
> > Anne
> >
> > -----Original Message-----
> > From: Aleksandar Milanovic [mailto:amilanovic@galdosinc.com]
> > Sent: Tuesday, March 27, 2001 4:45 PM
> > To: Soap-User
> > Subject: SOAP vs. J2EE
> >
> >
> > Hi SOAPers,
> >
> > I have to make a decision whether to use J2EE or SOAP for a distributed
> > software system. I have more knowledge about SOAP than J2EE, but the
> > principles of the latter are known to me. Still, I am having hard time
> > picking the favourite technology.
> >
> > For example, J2EE facilitates transaction control, which may be useful,
> but
> > it's not obvious to me whether this is so useful as to make it mandatory.
> >
> > The software system in question is XML-centric, but may also deal with
> > non-XML data (e.g. images, voice), which will be somehow encoded in XML
> > (probably Base64). It will accept updates from distributed clients and
> will
> > communicate with other systems via an unspecified protocol (CORBA, RMI or
> > something else, maybe even SOAP). SOAP, if used, would serve for traffic
> > between the server and the clients.
> >
> > It is expected that most of the time this system will have low traffic
> > volume, but occasionally it will increase sharply, and then, more than one
> > client will want to read and update data belonging to the same "object".
> > Scalability is potentially a factor. The system will most likely have
> dozens
> > or hundreds of clients, but the choice of technology should not restrict
> > this number from growing to thousands (more than that is very unlikely).
> > Data integrity is perhaps a less important factor because most data
> updates
> > will consist of inserting new data (appending) rather than modifying the
> > existing.
> >
> > The system should be cross-platform, easy to develop and extensible.
> > Performance is of secondary priority.
> >
> > Any opinions are welcome.
> >
> > thx
> > Alex
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org