On 9/10/10 4:30 PM, Christian Schneider wrote:
Hi Glen,
I think we can leave the wiki page this way. But honestly I do not
understand why it makes a difference if someone is listening. The idea
behind messaging is that you decouple the Client and the Server. So I
think there is no difference between sending a message and making a
call. What exactly would jax ws do different? If you use an http
endpoint instead of a jms endpoint the route will behave exactly like a
jax ws implementation in one way mode.
It's OK for the oneway mode, but for the http there are some different.
Even service doesn't send back the response message, it has to send the
http state code 200 if the service take the request.
If there is no service provide at end of the transport, it's to make me
believe the request is send to a service endpoint.
For the request/reply message, the client always expect a response
message :)
The SOAP dataformat of course only creates messages but together with a
transport endpoint like jms or http it can really be considered a
(partial) jax ws implementation. I think it is even a very good idea to
strongly decouple the message generation from the transport.
Yeah, we can let the user leverage other transport component that camel
provides in this way.
Willem
Best Regards
Christian
Am 10.09.2010 01:51, schrieb Glen Mazza:
I reworded it--see if you find it acceptable. We may need to
compromise with you giving your interpretation in German and me giving
mine in English. :)
As for "you could also say that sending a message that contains soap
content is a one way soap call even if no one listens for it", no, I
wouldn't say you could say that. Placing an XML message on a queue is
not a SOAP call, it has to be listened to by a web service provider
for that to be a SOAP call. Further: "As the call is asnychronous the
caller will not know if anyone listens to the call anyway", true, but
I don't think that's the point, one-way SOAP calls are still intended
to be processed.
When I first read the SOAP DataFormat, I thought it made actual SOAP
calls, perhaps just using the JAX-WS RI instead of CXF. Then I
realized it just creates SOAP messages, it's really an enhanced
version of the JAXB DataFormat. To limit confusion, I think it would
be good to disabuse the reader early on of the notion that it is
making SOAP calls.
Glen
Christian Schneider wrote:
Hi Glen,
you can see it this way. On the other hand you could also say that
sending a message that contains soap content is a one way soap call
even if no one listens for it. As the call is asnychronous the caller
will not know if anyone listens to the call anyway ;-)
Regards
Christian
Am 09.09.2010 09:46, schrieb Glen Mazza:
It is only a SOAP call if a web service is listening on that queue,
correct? And if no web service is listening there, then it's just a
simple matter of an XML message (that just happens to be a SOAP
call) being sent to the queue, correct again? OK, I'll update the
SOAP page (or you may do so) later on today.
Thanks,
Glen
Christian Schneider wrote:
Hi Glen,
at my employer we are hosting the complete web services using jms
instead of http. So if you have a webservice listening on the jms
queue you can make soap calls using the soap dataformat.
CXF also provides SOAP / JMS. We even have services running on
tibco business works that can be directly called on jms. If your
service method is one way then the simple route below will implement
a complete sop call. For request reply you of course need the more
complicated route shown in the other examples of the soap dataformat.
Regards
Christian
Am 09.09.2010 02:54, schrieb Glen Mazza:
Hello, another question on the SOAP DataFormat text. In the "Using
the Java DSL" section[1], the example given is as follows:
SoapJaxbDataFormat soap = new
SoapJaxbDataFormat("com.example.customerservice", new
ServiceInterfaceStrategy(CustomerService.class));
from("direct:start")
.marshal(soap)
.to("jms:myQueue");
I'm not sure what the above route is doing. Is it:
1.) Making a SOAP over JMS call (i.e., jms:myQueue will need to be
a web service provider that will return a response)
or
2.) Just marshalling the Java object holding the SOAP call data
into an XML SOAP Envelope and placing the latter on a queue (for
perhaps a later feed to the actual web service call, but it does
not have to be).
Thanks,
Glen
[1]
https://cwiki.apache.org/confluence/display/CAMEL/SOAP#SOAP-UsingtheJavaDSL
