Hi,
Firstly, because mailing lists are largely populated with problems,
I'd just like to say, the CXF APIs are really flexible, and I've got
some cool things going with very little code.
So, I don't see it as being so complicated as long as you throw out
the client/server paradigm that WS (or message-orientation) was
supposed to get beyond. So there is Source and Sink, rather than
server/client. Both play both roles of client and server.
What I've just got going is:
1. Source has an out-only operation.
2. An interested Sink generates an inversion of that interface, i.e.
all the outs are turned to ins and vise versa, and publishes a service
with that interface (a org.apache.cxf.endpoint.Server)
3. The Source creates a org.apache.cxf.endpoint.Client with a similar
inversion, and sends messages to the Sink when it feels like it,
behaving like a client.
Works a treat (with a very simple case :-)).
cheers,
Andrew
On 23 Sep 2009, at 21:01, Daniel Kulp wrote:
On Wed September 23 2009 12:07:10 pm Andrew Harrison wrote:
Ah - interesting... I did try to find a JAX-WS @Notification
annotation but to no avail.
The wsdl2java tools blow up as well if there isn't an operation
input.
I understand why now :-)
Ok...
It might be nice to support notification and solicit response. I
guess
this is on the JAX-WS roadmap.
Actually, I don't think it is. It's never come up on the working
group, at
least not in the last couple years. In general, JAX-WS really uses
more of a
registered callback mechanism with WS-A type references to have a
service send
a notice back (via request/response) to the client. Thus, anything
we would
do around it would be proprietary, which isn't a bad thing, BTW.
Kind of comes down to how would it look in the generated code?
Something like:
public String event();
isn't really good as the client would "block" until an event came.
Thus,
something more like:
public void registerEventHandler(AsyncHandler<Response<String>>
reponse)
or similar to register some sort of callback thing is probably more
appropriate.
Server side is even more complex. Some sort of handler or
something would
need to be injected/registered with the server impl that could then
call those
to produce the events.
There are also the more complex issues like "what does this look
like when
using http?" and similar issues which is basically why jax-ws punted
on it.
In any case, this is definitely an "interesting" project, but it's
also not
exactly a small project.
Dan
Thanks,
Andrew
On 23 Sep 2009, at 16:52, Daniel Kulp wrote:
Not a bug, this mapping is correct. JAX-WS doesn't support
notification
style stuff. All methods are either request/response or one-way.
If this is needed, we'd need to create new non-standard annotations
and such
to mark this. (doable pretty easily on 2.3/trunk, not as easy on
2.2)
Dan
On Wed September 23 2009 7:54:51 am Andrew Harrison wrote:
Hi,
If I have a SEI with a method that returns a value, but takes in no
parameters, i.e. a notification style message, the WSDL generated
still contains an input message.
I have something like:
@WebMethod(operationName = "Event")
@WebResult(name = "Text")
public String event();
Which produces:
<wsdl:message name="EventResponse">
<wsdl:part element="tns:Text" name="Text"></wsdl:part>
</wsdl:message>
<wsdl:message name="Event"></wsdl:message>
<wsdl:operation name="Event">
<wsdl:input message="tns:Event" name="Event"></wsdl:input>
<wsdl:output message="tns:EventResponse" name="EventResponse"></
wsdl:output>
</wsdl:operation>
If this is considered a bug, I can create a JIRA issue with a
patch.
cheers,
Andrew
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
