You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Jacques TALBOT <tj...@teamlog.com> on 2002/10/14 10:25:20 UTC
SOAP on JMS, a solution to which problem?
So we all agree we need asynchronous, reliable, standard web services.
Reliability is because applications, being pretty dumb, cannot cope,
like human beings with http rather erratic semantics.
Asynchronous because we know from EAI times that it is better.
Standard because this is what Web Services are all about.
So is SOAP on JMS the solution?
Partly yes because it is indeed asynchronous and
with guaranteed once&onlyonce semantics
Partly no because of 2 problems, one small (semantics mismatch)
and one big (standard protocol)
The small problem:
the semantics problem is related to the fact that JMS embeds a model
with queues (one to one messaging) and topics (publish and subscribe)
This does not map so obviouly on SOAP+WSDL
IMHO, it is very difficult to imagine that the programmer ignore he/she
is using a queue or a topic, or defer that decision to deployment time
as some seem to hope.
As a consequence, there will be many ways to do the semantic mapping
and they will not interoperate.
The big problem
JMS is only an API, not a protocol, and protocol implementations are
proprietary
So it is limited to the intranet. This is rather contradictory with the Web
model
where the same protocols are used inside and outside the firewall,
with the nice lowering of costs attached to this standardisation.
Looking now at Sonic's contribution:
http://www.oetrends.com/cgi-bin/page_display.cgi?109
what exactly is Sonic/Apache proposing to solve this dilemna?
and BTW what is delivered in Axis 1.0? is it only a client
"SOAP/WSDL to JMS" binding or also the JMS MOM engine? If no engine,
do you have to buy one, considering that open source JMS engines are not
so popular, even if they exist (JORAM, SwiftMQ, activeJMS...)?
Furthermore, it is pretty easy to design a quick and dirty JMS provider
with none of the reliability of MQseries (or Sonic BTW :-)
Now if we count SOAP on JMS out for B2B, what is proposed?
Holt Adams from IBM proposes 4 patterns in:
http://www-106.ibm.com/developerworks/webservices/library/ws-asynch1.html?dw
zone=webservices
Patterns 3 and 4 which can run on http are sort of toys IMHO
I am not criticizing the proposal, but I do believe that any web service
going beyond "get a quote" needs some semantic guarantees from the transport
because it is VERY different to deal with a transport loosing one message
out of 1000 and another one loosing one message out of 1 million;
Pattern 3 is polling: back to 1960 ;-) can you imagine your mobile phone
polling the network?
Pattern 4 is "build your own MOM at the application level"
which is TOO DIFFICULT for the "average programmer".
So we are back to Patterns 1 and 2 which, unfortunately, have only
one possible transport outside the firewall, httpr
(unless of course you do no want reliability, back to toy applications)
But httpr is only an IBM proposal, nothing like a standard for the time
being
Running into circles!
Looks like we have no solution ...
Now, some techno politic fiction .. what I believe is really happening
behind the curtains:
All the IBM and Microsoft technical luminaries have understood all of the
above
since at least one year. So they probably meet monthly in
a nice wooden hotel in a Colorado ski resort to try to come up with a
solution for the world.
IBM is pushing a solution at transport level, httpr.
Microsoft is pushing a WS-RM (reliable messaging) at the SOAP level.
The problem is: how come the white smoke is not out already, is it so
difficult
to find a technical solution, are there more political issues that I cannot
even imagine?
Why is it that they managed to converge on WS-T and WS-C, which, IMHO, is
something
which is not really needed for the next 2 years, and that the more useful
and better
understood WS-RM convergence is not happening?
There is no irony above, I do believe this duopolistic process is quite
acceptable
to move things forward, considering that W3C is going forward at a pretty
low speed.
Your opinion is welcome on the fictional aspect of the above ...
Disclaimer: It is entirely possible that, from my remote french location, I
cannot really
see behind the curtains and as a consequence, my fairy tale can be entirely
wrong,
or I may have missed some key aspect ...
The bottom line is that as a consultant, I would like to be able to tell
my customers to use WS for serious business, but I honestly cannot.
If we collectively do not solve the WS-RM issue in the next 12 months, WS
will go down the Gartner hype curve at a very dangerous speed and our
customers
will label it as yet another techno fad.
If you are still reading at this point, I can only thank you for yor
patience :-)
and hope for the best
--
Jacques Talbot - Architecture Consultant - Teamlog 10 rue Lavoisier - 38330
Montbonnot
Tél: +33 4 76 61 37 12 Mél: jacques.talbot@teamlog.com
Tél. mobile +33 6 07 83 42 00
Re: SOAP on JMS, a solution to which problem?
Posted by Ricky Ho <ri...@cisco.com>.
I agree that SOAP over JMS over the intranet (to Dave's definition) is a
very practical approach today. although we still need to be aware of other
conflicting approaches as well ....
Without knowing the Sonic contribution, I', not sure if the message
correlation id is an explicit field similar to JMS approach. If so, this
is different from the philosophy of the Orchestration camp who believes
correlation should be done via the business message itself rather than an
explicit id.
The SOAP/HTTP at the edge is where the end-to-end reliability breaks. The
request message may have been lost before even getting into your JMS queue.
Does using BTP with SOAP/HTTP can achieve reliability today ??
Best regards,
Ricky
Response embedded
>The biggest benefit is having a common set of API's and surrounding
>infrastructure that abstracts away the details of whether you are using
>HTTP, reliable messaging, or some other transport. JMS is just another
>protocol from that point of view...one that provides reliable delivery
>of data across your enterprise. JMS is not just a client API. It also
>prescribes a set of required behavioral semantics-like
>once-and-only-once delivery of data. What we're saying here is that the
>behavioral semantics is more important than the JMS API. We have
>embedded the JMS API inside of a layer that takes care of some of its
>deficiencies, and have chosen to expose the Axis API as the only thing
>that the client application uses.
>
>Your observation about using JMS as a solution for the Intranet is a
>great discussion point. The real question to consider is how does one
>characterize the "Intranet" these days, and where is the "edge" of the
>network anyhow? For lack of a better word, I would characterize the
>"Intranet" as the realm of networking and IT infrastructure that is
>under your corporate control, where you have the ability to install and
>maintain the software of your choice (like a JMS provider). The "edge"
>of the network is that place where that level of control ceases to
>exist. What we (Sonic) are seeing repeatedly in real deployment
>scenarios is the desire to use SOAP over reliable messaging across the
>enterprise, and use SOAP over HTTP to bridge the boundaries at the
>"edge" of the network. This "Intranet" can be very large as well,
>covering global deployments between headquarters, field offices,
>warehouses etc.
>
>Even for the "edge" situations -- there are JMS providers that are
>capable of traversing firewalls in a secure and reliable fashion. It
>may also be possible to ask your business partner to use the Axis client
>in conjunction with the JMS client of your choice, in order to
>communicate with you.
>
>In the "edge" of the network cases where SOAP over HTTP is the desirable
>option, then that's great, do it. If a SOAP-over-HTTP message arrives
>at your door, then gets placed on a JMS queue, it is now safe within a
>reliable communications infrastructure throughout its entire tour
>through you business processes. If an outbound request needs to be made
>from one of your systems across the Internet using SOAP-over-HTTP, and
>that request fails, then that's OK too, because the message that caused
>the request to be made is still sitting in the queue.
>
>A truly interoperable, reliable SOAP communication is an area that can
>always be improved, and I'm real excited about seeing that happen. We
>are also real interested in exploring things like WS-Txn, HTTPR, and all
>of the evolving proposals that can help solidify the SOAP-over-HTTP
>communication to make it more reliable. I think the widespread
>adoption, of whatever that winds up being, is a few years away. For the
>time being, enterprise messaging is here-and-now, and has widespread
>adoption already. In the Axis submission we are providing a nice and
>easy way of blending together these two worlds using a common SOAP
>stack. We look forward to addressing other reliable protocols as they
>evolve, and providing ways of bridging the gaps.
>Dave
>
>
>Jacques TALBOT wrote:
> >
> > So we all agree we need asynchronous, reliable, standard web services.
> > Reliability is because applications, being pretty dumb, cannot cope,
> > like human beings with http rather erratic semantics.
> > Asynchronous because we know from EAI times that it is better.
> > Standard because this is what Web Services are all about.
> >
> > So is SOAP on JMS the solution?
> > Partly yes because it is indeed asynchronous and
> > with guaranteed once&onlyonce semantics
> > Partly no because of 2 problems, one small (semantics mismatch)
> > and one big (standard protocol)
> >
> > The small problem:
> > the semantics problem is related to the fact that JMS embeds a model
> > with queues (one to one messaging) and topics (publish and subscribe)
> > This does not map so obviouly on SOAP+WSDL
> > IMHO, it is very difficult to imagine that the programmer ignore he/she
> > is using a queue or a topic, or defer that decision to deployment time
> > as some seem to hope.
> > As a consequence, there will be many ways to do the semantic mapping
> > and they will not interoperate.
> >
> > The big problem
> > JMS is only an API, not a protocol, and protocol implementations are
> > proprietary
> > So it is limited to the intranet. This is rather contradictory with the Web
> > model
> > where the same protocols are used inside and outside the firewall,
> > with the nice lowering of costs attached to this standardisation.
> >
> > Looking now at Sonic's contribution:
> > http://www.oetrends.com/cgi-bin/page_display.cgi?109
> > what exactly is Sonic/Apache proposing to solve this dilemna?
> > and BTW what is delivered in Axis 1.0? is it only a client
> > "SOAP/WSDL to JMS" binding or also the JMS MOM engine? If no engine,
> > do you have to buy one, considering that open source JMS engines are not
> > so popular, even if they exist (JORAM, SwiftMQ, activeJMS...)?
> > Furthermore, it is pretty easy to design a quick and dirty JMS provider
> > with none of the reliability of MQseries (or Sonic BTW :-)
> >
> > Now if we count SOAP on JMS out for B2B, what is proposed?
> > Holt Adams from IBM proposes 4 patterns in:
> >
> http://www-106.ibm.com/developerworks/webservices/library/ws-asynch1.html?dw
> > zone=webservices
> > Patterns 3 and 4 which can run on http are sort of toys IMHO
> > I am not criticizing the proposal, but I do believe that any web service
> > going beyond "get a quote" needs some semantic guarantees from the
> transport
> > because it is VERY different to deal with a transport loosing one message
> > out of 1000 and another one loosing one message out of 1 million;
> > Pattern 3 is polling: back to 1960 ;-) can you imagine your mobile phone
> > polling the network?
> > Pattern 4 is "build your own MOM at the application level"
> > which is TOO DIFFICULT for the "average programmer".
> > So we are back to Patterns 1 and 2 which, unfortunately, have only
> > one possible transport outside the firewall, httpr
> > (unless of course you do no want reliability, back to toy applications)
> > But httpr is only an IBM proposal, nothing like a standard for the time
> > being
> > Running into circles!
> >
> > Looks like we have no solution ...
> >
> > Now, some techno politic fiction .. what I believe is really happening
> > behind the curtains:
> > All the IBM and Microsoft technical luminaries have understood all of the
> > above
> > since at least one year. So they probably meet monthly in
> > a nice wooden hotel in a Colorado ski resort to try to come up with a
> > solution for the world.
> > IBM is pushing a solution at transport level, httpr.
> > Microsoft is pushing a WS-RM (reliable messaging) at the SOAP level.
> > The problem is: how come the white smoke is not out already, is it so
> > difficult
> > to find a technical solution, are there more political issues that I cannot
> > even imagine?
> > Why is it that they managed to converge on WS-T and WS-C, which, IMHO, is
> > something
> > which is not really needed for the next 2 years, and that the more useful
> > and better
> > understood WS-RM convergence is not happening?
> >
> > There is no irony above, I do believe this duopolistic process is quite
> > acceptable
> > to move things forward, considering that W3C is going forward at a pretty
> > low speed.
> >
> > Your opinion is welcome on the fictional aspect of the above ...
> >
> > Disclaimer: It is entirely possible that, from my remote french location, I
> > cannot really
> > see behind the curtains and as a consequence, my fairy tale can be entirely
> > wrong,
> > or I may have missed some key aspect ...
> >
> > The bottom line is that as a consultant, I would like to be able to tell
> > my customers to use WS for serious business, but I honestly cannot.
> > If we collectively do not solve the WS-RM issue in the next 12 months, WS
> > will go down the Gartner hype curve at a very dangerous speed and our
> > customers
> > will label it as yet another techno fad.
> >
> > If you are still reading at this point, I can only thank you for yor
> > patience :-)
> > and hope for the best
> >
> > --
> > Jacques Talbot - Architecture Consultant - Teamlog 10 rue Lavoisier - 38330
> > Montbonnot
> > Tél: +33 4 76 61 37 12 Mél: jacques.talbot@teamlog.com
> > Tél. mobile +33 6 07 83 42 00
>
>--
>Sonic Software - Backbone of the Extended Enterprise
>--
>David Chappell <ch...@sonicsoftware.com> Office: (781)999-7099
>Mobile: (617)510-6566
>Vice President and Chief Technology Evangelist, Sonic Software
>co-author,"Java Web Services", (O'Reilly 2002)
>"The Java Message Service", (O'Reilly 2000)
>"Professional ebXML Foundations", (Wrox 2001)
>--
Re: SOAP on JMS, a solution to which problem?
Posted by David Chappell <ch...@sonicsoftware.com>.
Hello Jacques,
These are all great discussion points. There is never one correct
answer. I can't speak for all of the Axis developers, but I will try
and explain Sonic's point of view for doing this.
The biggest benefit is having a common set of API's and surrounding
infrastructure that abstracts away the details of whether you are using
HTTP, reliable messaging, or some other transport. JMS is just another
protocol from that point of view...one that provides reliable delivery
of data across your enterprise. JMS is not just a client API. It also
prescribes a set of required behavioral semantics-like
once-and-only-once delivery of data. What we're saying here is that the
behavioral semantics is more important than the JMS API. We have
embedded the JMS API inside of a layer that takes care of some of its
deficiencies, and have chosen to expose the Axis API as the only thing
that the client application uses.
Your observation about using JMS as a solution for the Intranet is a
great discussion point. The real question to consider is how does one
characterize the "Intranet" these days, and where is the "edge" of the
network anyhow? For lack of a better word, I would characterize the
"Intranet" as the realm of networking and IT infrastructure that is
under your corporate control, where you have the ability to install and
maintain the software of your choice (like a JMS provider). The "edge"
of the network is that place where that level of control ceases to
exist. What we (Sonic) are seeing repeatedly in real deployment
scenarios is the desire to use SOAP over reliable messaging across the
enterprise, and use SOAP over HTTP to bridge the boundaries at the
"edge" of the network. This "Intranet" can be very large as well,
covering global deployments between headquarters, field offices,
warehouses etc.
Even for the "edge" situations -- there are JMS providers that are
capable of traversing firewalls in a secure and reliable fashion. It
may also be possible to ask your business partner to use the Axis client
in conjunction with the JMS client of your choice, in order to
communicate with you.
In the "edge" of the network cases where SOAP over HTTP is the desirable
option, then that's great, do it. If a SOAP-over-HTTP message arrives
at your door, then gets placed on a JMS queue, it is now safe within a
reliable communications infrastructure throughout its entire tour
through you business processes. If an outbound request needs to be made
from one of your systems across the Internet using SOAP-over-HTTP, and
that request fails, then that's OK too, because the message that caused
the request to be made is still sitting in the queue.
A truly interoperable, reliable SOAP communication is an area that can
always be improved, and I'm real excited about seeing that happen. We
are also real interested in exploring things like WS-Txn, HTTPR, and all
of the evolving proposals that can help solidify the SOAP-over-HTTP
communication to make it more reliable. I think the widespread
adoption, of whatever that winds up being, is a few years away. For the
time being, enterprise messaging is here-and-now, and has widespread
adoption already. In the Axis submission we are providing a nice and
easy way of blending together these two worlds using a common SOAP
stack. We look forward to addressing other reliable protocols as they
evolve, and providing ways of bridging the gaps.
Dave
Jacques TALBOT wrote:
>
> So we all agree we need asynchronous, reliable, standard web services.
> Reliability is because applications, being pretty dumb, cannot cope,
> like human beings with http rather erratic semantics.
> Asynchronous because we know from EAI times that it is better.
> Standard because this is what Web Services are all about.
>
> So is SOAP on JMS the solution?
> Partly yes because it is indeed asynchronous and
> with guaranteed once&onlyonce semantics
> Partly no because of 2 problems, one small (semantics mismatch)
> and one big (standard protocol)
>
> The small problem:
> the semantics problem is related to the fact that JMS embeds a model
> with queues (one to one messaging) and topics (publish and subscribe)
> This does not map so obviouly on SOAP+WSDL
> IMHO, it is very difficult to imagine that the programmer ignore he/she
> is using a queue or a topic, or defer that decision to deployment time
> as some seem to hope.
> As a consequence, there will be many ways to do the semantic mapping
> and they will not interoperate.
>
> The big problem
> JMS is only an API, not a protocol, and protocol implementations are
> proprietary
> So it is limited to the intranet. This is rather contradictory with the Web
> model
> where the same protocols are used inside and outside the firewall,
> with the nice lowering of costs attached to this standardisation.
>
> Looking now at Sonic's contribution:
> http://www.oetrends.com/cgi-bin/page_display.cgi?109
> what exactly is Sonic/Apache proposing to solve this dilemna?
> and BTW what is delivered in Axis 1.0? is it only a client
> "SOAP/WSDL to JMS" binding or also the JMS MOM engine? If no engine,
> do you have to buy one, considering that open source JMS engines are not
> so popular, even if they exist (JORAM, SwiftMQ, activeJMS...)?
> Furthermore, it is pretty easy to design a quick and dirty JMS provider
> with none of the reliability of MQseries (or Sonic BTW :-)
>
> Now if we count SOAP on JMS out for B2B, what is proposed?
> Holt Adams from IBM proposes 4 patterns in:
> http://www-106.ibm.com/developerworks/webservices/library/ws-asynch1.html?dw
> zone=webservices
> Patterns 3 and 4 which can run on http are sort of toys IMHO
> I am not criticizing the proposal, but I do believe that any web service
> going beyond "get a quote" needs some semantic guarantees from the transport
> because it is VERY different to deal with a transport loosing one message
> out of 1000 and another one loosing one message out of 1 million;
> Pattern 3 is polling: back to 1960 ;-) can you imagine your mobile phone
> polling the network?
> Pattern 4 is "build your own MOM at the application level"
> which is TOO DIFFICULT for the "average programmer".
> So we are back to Patterns 1 and 2 which, unfortunately, have only
> one possible transport outside the firewall, httpr
> (unless of course you do no want reliability, back to toy applications)
> But httpr is only an IBM proposal, nothing like a standard for the time
> being
> Running into circles!
>
> Looks like we have no solution ...
>
> Now, some techno politic fiction .. what I believe is really happening
> behind the curtains:
> All the IBM and Microsoft technical luminaries have understood all of the
> above
> since at least one year. So they probably meet monthly in
> a nice wooden hotel in a Colorado ski resort to try to come up with a
> solution for the world.
> IBM is pushing a solution at transport level, httpr.
> Microsoft is pushing a WS-RM (reliable messaging) at the SOAP level.
> The problem is: how come the white smoke is not out already, is it so
> difficult
> to find a technical solution, are there more political issues that I cannot
> even imagine?
> Why is it that they managed to converge on WS-T and WS-C, which, IMHO, is
> something
> which is not really needed for the next 2 years, and that the more useful
> and better
> understood WS-RM convergence is not happening?
>
> There is no irony above, I do believe this duopolistic process is quite
> acceptable
> to move things forward, considering that W3C is going forward at a pretty
> low speed.
>
> Your opinion is welcome on the fictional aspect of the above ...
>
> Disclaimer: It is entirely possible that, from my remote french location, I
> cannot really
> see behind the curtains and as a consequence, my fairy tale can be entirely
> wrong,
> or I may have missed some key aspect ...
>
> The bottom line is that as a consultant, I would like to be able to tell
> my customers to use WS for serious business, but I honestly cannot.
> If we collectively do not solve the WS-RM issue in the next 12 months, WS
> will go down the Gartner hype curve at a very dangerous speed and our
> customers
> will label it as yet another techno fad.
>
> If you are still reading at this point, I can only thank you for yor
> patience :-)
> and hope for the best
>
> --
> Jacques Talbot - Architecture Consultant - Teamlog 10 rue Lavoisier - 38330
> Montbonnot
> Tél: +33 4 76 61 37 12 Mél: jacques.talbot@teamlog.com
> Tél. mobile +33 6 07 83 42 00
--
Sonic Software - Backbone of the Extended Enterprise
--
David Chappell <ch...@sonicsoftware.com> Office: (781)999-7099
Mobile: (617)510-6566
Vice President and Chief Technology Evangelist, Sonic Software
co-author,"Java Web Services", (O'Reilly 2002)
"The Java Message Service", (O'Reilly 2000)
"Professional ebXML Foundations", (Wrox 2001)
--
Re: SOAP on JMS, a solution to which problem?
Posted by Simon Hargreaves <si...@openthought.com>.
A very good summary of the state of the asynchronous web services
applications.
I think that a standard reliable transport may be covered by the
ebxml-msg and JAXM specifications. It appears that some of the JAXM
implementations use JMS internally for queuing and reliable semantics.
http://www.oasis-open.org/committees/ebxml-msg/
http://java.sun.com/xml/jaxm/
But open implementations are practically non-existant, there are some
"toy" implementations but nothing that I would use in the enterprise
apart from maybe GLUE, but I haven't used that in anger yet.
I do agree that more energy needs to be put into this disorganised area,
as we seem to be far from anything for B2B enterprise level applications.
Simon...
Jacques TALBOT wrote:
>So we all agree we need asynchronous, reliable, standard web services.
>Reliability is because applications, being pretty dumb, cannot cope,
>like human beings with http rather erratic semantics.
>Asynchronous because we know from EAI times that it is better.
>Standard because this is what Web Services are all about.
>
>So is SOAP on JMS the solution?
>Partly yes because it is indeed asynchronous and
>with guaranteed once&onlyonce semantics
>Partly no because of 2 problems, one small (semantics mismatch)
>and one big (standard protocol)
>
>The small problem:
>the semantics problem is related to the fact that JMS embeds a model
>with queues (one to one messaging) and topics (publish and subscribe)
>This does not map so obviouly on SOAP+WSDL
>IMHO, it is very difficult to imagine that the programmer ignore he/she
>is using a queue or a topic, or defer that decision to deployment time
>as some seem to hope.
>As a consequence, there will be many ways to do the semantic mapping
>and they will not interoperate.
>
>The big problem
>JMS is only an API, not a protocol, and protocol implementations are
>proprietary
>So it is limited to the intranet. This is rather contradictory with the Web
>model
>where the same protocols are used inside and outside the firewall,
>with the nice lowering of costs attached to this standardisation.
>
>Looking now at Sonic's contribution:
>http://www.oetrends.com/cgi-bin/page_display.cgi?109
>what exactly is Sonic/Apache proposing to solve this dilemna?
>and BTW what is delivered in Axis 1.0? is it only a client
>"SOAP/WSDL to JMS" binding or also the JMS MOM engine? If no engine,
>do you have to buy one, considering that open source JMS engines are not
>so popular, even if they exist (JORAM, SwiftMQ, activeJMS...)?
>Furthermore, it is pretty easy to design a quick and dirty JMS provider
>with none of the reliability of MQseries (or Sonic BTW :-)
>
>Now if we count SOAP on JMS out for B2B, what is proposed?
>Holt Adams from IBM proposes 4 patterns in:
>http://www-106.ibm.com/developerworks/webservices/library/ws-asynch1.html?dw
>zone=webservices
>Patterns 3 and 4 which can run on http are sort of toys IMHO
>I am not criticizing the proposal, but I do believe that any web service
>going beyond "get a quote" needs some semantic guarantees from the transport
>because it is VERY different to deal with a transport loosing one message
>out of 1000 and another one loosing one message out of 1 million;
>Pattern 3 is polling: back to 1960 ;-) can you imagine your mobile phone
>polling the network?
>Pattern 4 is "build your own MOM at the application level"
>which is TOO DIFFICULT for the "average programmer".
>So we are back to Patterns 1 and 2 which, unfortunately, have only
>one possible transport outside the firewall, httpr
>(unless of course you do no want reliability, back to toy applications)
>But httpr is only an IBM proposal, nothing like a standard for the time
>being
>Running into circles!
>
>Looks like we have no solution ...
>
>Now, some techno politic fiction .. what I believe is really happening
>behind the curtains:
>All the IBM and Microsoft technical luminaries have understood all of the
>above
>since at least one year. So they probably meet monthly in
>a nice wooden hotel in a Colorado ski resort to try to come up with a
>solution for the world.
>IBM is pushing a solution at transport level, httpr.
>Microsoft is pushing a WS-RM (reliable messaging) at the SOAP level.
>The problem is: how come the white smoke is not out already, is it so
>difficult
>to find a technical solution, are there more political issues that I cannot
>even imagine?
>Why is it that they managed to converge on WS-T and WS-C, which, IMHO, is
>something
>which is not really needed for the next 2 years, and that the more useful
>and better
>understood WS-RM convergence is not happening?
>
>There is no irony above, I do believe this duopolistic process is quite
>acceptable
>to move things forward, considering that W3C is going forward at a pretty
>low speed.
>
>Your opinion is welcome on the fictional aspect of the above ...
>
>Disclaimer: It is entirely possible that, from my remote french location, I
>cannot really
>see behind the curtains and as a consequence, my fairy tale can be entirely
>wrong,
>or I may have missed some key aspect ...
>
>The bottom line is that as a consultant, I would like to be able to tell
>my customers to use WS for serious business, but I honestly cannot.
>If we collectively do not solve the WS-RM issue in the next 12 months, WS
>will go down the Gartner hype curve at a very dangerous speed and our
>customers
>will label it as yet another techno fad.
>
>If you are still reading at this point, I can only thank you for yor
>patience :-)
>and hope for the best
>
>
>--
>Jacques Talbot - Architecture Consultant - Teamlog 10 rue Lavoisier - 38330
>Montbonnot
>Tél: +33 4 76 61 37 12 Mél: jacques.talbot@teamlog.com
>Tél. mobile +33 6 07 83 42 00
>
>
>
>
Re: SOAP on JMS, a solution to which problem?
Posted by Ricky Ho <ri...@cisco.com>.
An excellent summary !!
Another BIG thing about the Web Service and JMS semantic mismatch is about
the way they look at TRANSACTION (although there is not a widely-accepted
one at this moment, so I'm talking about the model behind "BTP" and
"WS-Transaction").
In JMS, it is NOT possible to send an async request and get back its
response (asynchronously) within a single transaction. Your request
message will not be possible to reach the server before the transaction
commit successfully.
In WS-Transaction (and BTP) model, the request message can reach the server
with an associated context. And there is a 2-phase co-ordinating protocol
at transaction termination time so that the effect on the server side can
be back off in case the client abort his transaction.
This semantic mismatch is another BIG thing to me.
I think the challenge to establish a reliability delivery standard now is
there is no consensus in whether this should be done at the "TRANSPORT"
level or the "SOAP MESSAGE EXCHANGE" level, and both camp have very good
reasons on that.
So there is NO solution today that is inter-operable, but if you have
control in both the client and server side (which is a very common
deployment scenario when people test our web services in their intranet),
then there are at least a couple solution that I can think of ....
1) Implement a handshaking protocol (ack / retry) at the client handler and
service handler -- (both sides need to be AXIS that has these handlers
installed)
2) Use JMS as your underlying transport -- (of course, you are using the
same JMS vendor on both side)
3) Use HTTPR -- (I haven't tried this yet)
4) Do the handshaking at the application level
Would love to hear other people's suggestion ....
Rgds, Ricky
At 10:25 AM 10/14/2002 +0200, Jacques TALBOT wrote:
>So we all agree we need asynchronous, reliable, standard web services.
>Reliability is because applications, being pretty dumb, cannot cope,
>like human beings with http rather erratic semantics.
>Asynchronous because we know from EAI times that it is better.
>Standard because this is what Web Services are all about.
>
>So is SOAP on JMS the solution?
>Partly yes because it is indeed asynchronous and
>with guaranteed once&onlyonce semantics
>Partly no because of 2 problems, one small (semantics mismatch)
>and one big (standard protocol)
>
>The small problem:
>the semantics problem is related to the fact that JMS embeds a model
>with queues (one to one messaging) and topics (publish and subscribe)
>This does not map so obviouly on SOAP+WSDL
>IMHO, it is very difficult to imagine that the programmer ignore he/she
>is using a queue or a topic, or defer that decision to deployment time
>as some seem to hope.
>As a consequence, there will be many ways to do the semantic mapping
>and they will not interoperate.
>
>The big problem
>JMS is only an API, not a protocol, and protocol implementations are
>proprietary
>So it is limited to the intranet. This is rather contradictory with the Web
>model
>where the same protocols are used inside and outside the firewall,
>with the nice lowering of costs attached to this standardisation.
>
>Looking now at Sonic's contribution:
>http://www.oetrends.com/cgi-bin/page_display.cgi?109
>what exactly is Sonic/Apache proposing to solve this dilemna?
>and BTW what is delivered in Axis 1.0? is it only a client
>"SOAP/WSDL to JMS" binding or also the JMS MOM engine? If no engine,
>do you have to buy one, considering that open source JMS engines are not
>so popular, even if they exist (JORAM, SwiftMQ, activeJMS...)?
>Furthermore, it is pretty easy to design a quick and dirty JMS provider
>with none of the reliability of MQseries (or Sonic BTW :-)
>
>Now if we count SOAP on JMS out for B2B, what is proposed?
>Holt Adams from IBM proposes 4 patterns in:
>http://www-106.ibm.com/developerworks/webservices/library/ws-asynch1.html?dw
>zone=webservices
>Patterns 3 and 4 which can run on http are sort of toys IMHO
>I am not criticizing the proposal, but I do believe that any web service
>going beyond "get a quote" needs some semantic guarantees from the transport
>because it is VERY different to deal with a transport loosing one message
>out of 1000 and another one loosing one message out of 1 million;
>Pattern 3 is polling: back to 1960 ;-) can you imagine your mobile phone
>polling the network?
>Pattern 4 is "build your own MOM at the application level"
>which is TOO DIFFICULT for the "average programmer".
>So we are back to Patterns 1 and 2 which, unfortunately, have only
>one possible transport outside the firewall, httpr
>(unless of course you do no want reliability, back to toy applications)
>But httpr is only an IBM proposal, nothing like a standard for the time
>being
>Running into circles!
>
>Looks like we have no solution ...
>
>Now, some techno politic fiction .. what I believe is really happening
>behind the curtains:
>All the IBM and Microsoft technical luminaries have understood all of the
>above
>since at least one year. So they probably meet monthly in
>a nice wooden hotel in a Colorado ski resort to try to come up with a
>solution for the world.
>IBM is pushing a solution at transport level, httpr.
>Microsoft is pushing a WS-RM (reliable messaging) at the SOAP level.
>The problem is: how come the white smoke is not out already, is it so
>difficult
>to find a technical solution, are there more political issues that I cannot
>even imagine?
>Why is it that they managed to converge on WS-T and WS-C, which, IMHO, is
>something
>which is not really needed for the next 2 years, and that the more useful
>and better
>understood WS-RM convergence is not happening?
>
>There is no irony above, I do believe this duopolistic process is quite
>acceptable
>to move things forward, considering that W3C is going forward at a pretty
>low speed.
>
>Your opinion is welcome on the fictional aspect of the above ...
>
>Disclaimer: It is entirely possible that, from my remote french location, I
>cannot really
>see behind the curtains and as a consequence, my fairy tale can be entirely
>wrong,
>or I may have missed some key aspect ...
>
>The bottom line is that as a consultant, I would like to be able to tell
>my customers to use WS for serious business, but I honestly cannot.
>If we collectively do not solve the WS-RM issue in the next 12 months, WS
>will go down the Gartner hype curve at a very dangerous speed and our
>customers
>will label it as yet another techno fad.
>
>If you are still reading at this point, I can only thank you for yor
>patience :-)
>and hope for the best
>
>
>--
>Jacques Talbot - Architecture Consultant - Teamlog 10 rue Lavoisier - 38330
>Montbonnot
>Tél: +33 4 76 61 37 12 Mél: jacques.talbot@teamlog.com
>Tél. mobile +33 6 07 83 42 00