You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Budi Wiyono <bu...@idola.net.id> on 2000/09/20 13:24:34 UTC
Re: More Info..... Install/set-up SOAP in a N-tier environment
Hi ...
How about helping Michele to build SOAP to xmlBlaster as 'MQ or MSMQ like
transport' ?
http://www.messageq.com/communications_middleware/tucker_2.html
>>>>
Date: Wed, 06 Sep 2000 10:39:29 -0500
From: Michele Laghi
X-Accept-Language: en
To: xmlBlaster Developer, xmlBlaster@server.xmlBlaster.org
Subject: Implementation of SOAP
Sender: owner-xmlblaster@xmlBlaster.org
Reply-To: xmlblaster@xmlBlaster.org
Hi everybody,
I am currently starting to write the SOAP implementation for xmlBlaster. It
will be done in a similar way to XML-RPC.
The following will be added to the xmlBlaster tree (subject to change):
protocol --- soap -+- I_XmlBlaster.java (interface)
|
+- CallbackSoapDriver.java
|
+- XmlBlasterImpl.java
|
+- SoapDriver.java
|
+- SoapConnectionResource.java
|
+- SoapServerPool.java
client --- protocol --- soap --- XmlBlasterProxy.java
Besides that, additional conversion utility methods will be put into
util---protocol---ProtoConverter.
Greetings
Michele
At 11:44 19/09/00 -0500, George I Matkovits wrote:
>It all depends. For a very large Web-Farm you would use a scalable
configuration
>with 'auto-rollover' for reliability. A servlet container itself is not
>transactional. J2EE Application Servers are. Servlets/JSPs are good for User
>Interface Work but for Business Critical Processing (e.g. Data Base
Access) IMHO
>an AppServer is required with its transactional attributes. In a real Web
>Services B2B environment Soap would be used over an MQ or MSMQ like
transport
>talking to an Application Server (We would not want to loose an order for
a 747
>would we?) A 'real' MQ Series Soap client would be programmatically
notified by
>its 'pear' soap-server-object when its request has made it into a
>'transactionally safe' container. PLEASE do not start now redesigning the
>Apache Soap Implementation to do load balancing, talk transactionally to
EJBs
>and try to do everything for everyone all the time. IMHO creating scalable
and
>reliable large scale systems is in the J2EE architecture's realm and NOT
Soaps.
>That is why there is room for RMI (over IIOP) and CORBA protocols in
addition to
>Soap. To my biased engineer mind Soap is just a 'firewall' piercing protocol
>(and currently the only good one) for fancy 'universal' ASCII data: called
XML.
>Regards - George
>
Re: More Info..... Install/set-up SOAP in a N-tier environment
Posted by George I Matkovits <ma...@uswest.net>.
I do not have MQ Series but IMHO IBM is busily extending it for SOAP.
Someone form IBM might be able to help you.
Regards - George
Budi Wiyono wrote:
> Hi ...
>
> How about helping Michele to build SOAP to xmlBlaster as 'MQ or MSMQ like
> transport' ?
> http://www.messageq.com/communications_middleware/tucker_2.html
>
> >>>>
> Date: Wed, 06 Sep 2000 10:39:29 -0500
> From: Michele Laghi
> X-Accept-Language: en
> To: xmlBlaster Developer, xmlBlaster@server.xmlBlaster.org
> Subject: Implementation of SOAP
> Sender: owner-xmlblaster@xmlBlaster.org
> Reply-To: xmlblaster@xmlBlaster.org
>
> Hi everybody,
> I am currently starting to write the SOAP implementation for xmlBlaster. It
> will be done in a similar way to XML-RPC.
> The following will be added to the xmlBlaster tree (subject to change):
>
> protocol --- soap -+- I_XmlBlaster.java (interface)
> |
> +- CallbackSoapDriver.java
> |
> +- XmlBlasterImpl.java
> |
> +- SoapDriver.java
> |
> +- SoapConnectionResource.java
> |
> +- SoapServerPool.java
>
> client --- protocol --- soap --- XmlBlasterProxy.java
>
> Besides that, additional conversion utility methods will be put into
> util---protocol---ProtoConverter.
>
> Greetings
> Michele
>
> At 11:44 19/09/00 -0500, George I Matkovits wrote:
> >It all depends. For a very large Web-Farm you would use a scalable
> configuration
> >with 'auto-rollover' for reliability. A servlet container itself is not
> >transactional. J2EE Application Servers are. Servlets/JSPs are good for User
> >Interface Work but for Business Critical Processing (e.g. Data Base
> Access) IMHO
> >an AppServer is required with its transactional attributes. In a real Web
> >Services B2B environment Soap would be used over an MQ or MSMQ like
> transport
> >talking to an Application Server (We would not want to loose an order for
> a 747
> >would we?) A 'real' MQ Series Soap client would be programmatically
> notified by
> >its 'pear' soap-server-object when its request has made it into a
> >'transactionally safe' container. PLEASE do not start now redesigning the
> >Apache Soap Implementation to do load balancing, talk transactionally to
> EJBs
> >and try to do everything for everyone all the time. IMHO creating scalable
> and
> >reliable large scale systems is in the J2EE architecture's realm and NOT
> Soaps.
> >That is why there is room for RMI (over IIOP) and CORBA protocols in
> addition to
> >Soap. To my biased engineer mind Soap is just a 'firewall' piercing protocol
> >(and currently the only good one) for fancy 'universal' ASCII data: called
> XML.
> >Regards - George
> >
Re: More Info..... Install/set-up SOAP in a N-tier environment
Posted by George I Matkovits <ma...@uswest.net>.
I do not have MQ Series but IMHO IBM is busily extending it for SOAP.
Someone form IBM might be able to help you.
Regards - George
Budi Wiyono wrote:
> Hi ...
>
> How about helping Michele to build SOAP to xmlBlaster as 'MQ or MSMQ like
> transport' ?
> http://www.messageq.com/communications_middleware/tucker_2.html
>
> >>>>
> Date: Wed, 06 Sep 2000 10:39:29 -0500
> From: Michele Laghi
> X-Accept-Language: en
> To: xmlBlaster Developer, xmlBlaster@server.xmlBlaster.org
> Subject: Implementation of SOAP
> Sender: owner-xmlblaster@xmlBlaster.org
> Reply-To: xmlblaster@xmlBlaster.org
>
> Hi everybody,
> I am currently starting to write the SOAP implementation for xmlBlaster. It
> will be done in a similar way to XML-RPC.
> The following will be added to the xmlBlaster tree (subject to change):
>
> protocol --- soap -+- I_XmlBlaster.java (interface)
> |
> +- CallbackSoapDriver.java
> |
> +- XmlBlasterImpl.java
> |
> +- SoapDriver.java
> |
> +- SoapConnectionResource.java
> |
> +- SoapServerPool.java
>
> client --- protocol --- soap --- XmlBlasterProxy.java
>
> Besides that, additional conversion utility methods will be put into
> util---protocol---ProtoConverter.
>
> Greetings
> Michele
>
> At 11:44 19/09/00 -0500, George I Matkovits wrote:
> >It all depends. For a very large Web-Farm you would use a scalable
> configuration
> >with 'auto-rollover' for reliability. A servlet container itself is not
> >transactional. J2EE Application Servers are. Servlets/JSPs are good for User
> >Interface Work but for Business Critical Processing (e.g. Data Base
> Access) IMHO
> >an AppServer is required with its transactional attributes. In a real Web
> >Services B2B environment Soap would be used over an MQ or MSMQ like
> transport
> >talking to an Application Server (We would not want to loose an order for
> a 747
> >would we?) A 'real' MQ Series Soap client would be programmatically
> notified by
> >its 'pear' soap-server-object when its request has made it into a
> >'transactionally safe' container. PLEASE do not start now redesigning the
> >Apache Soap Implementation to do load balancing, talk transactionally to
> EJBs
> >and try to do everything for everyone all the time. IMHO creating scalable
> and
> >reliable large scale systems is in the J2EE architecture's realm and NOT
> Soaps.
> >That is why there is room for RMI (over IIOP) and CORBA protocols in
> addition to
> >Soap. To my biased engineer mind Soap is just a 'firewall' piercing protocol
> >(and currently the only good one) for fancy 'universal' ASCII data: called
> XML.
> >Regards - George
> >