[Axis2] wsdl2java support for notification and solicit-response MEPs

[Andreas Bobek <an...@uni-rostock.de>]

Hi all,

I read this thread in which you discussed about
wsdl2java support for out-only MEPs (or out-in):

http://marc.theaimsgroup.com/?l=axis-user&m=113397248515948&w=2

As a workaround you suggested to rewrite (to invert) the WSDL.
I understand this approach, but my question is, do you intend to
support notification MEPs in wsdl2java in one of the next version or not at
all?
I think it is a MUST ;-)
Currently, I do some WS-Eventing stuff and I heavily miss this feature.
I myself could imagine services which only have notification operations,
and not a single "usual" request-response operation.

Regards, Andreas Bobek.

AW: [Axis2] wsdl2java support for notification and solicit-response MEPs

[Andreas Bobek <an...@uni-rostock.de>]

Hi Chathura,

> I haven't tried WS-Eventing but i have done some basic work on
> WS-Notification(Brokered) and to me using a complicated MEP 
> is yet another complication that won't give you much in 
> return. Basically the broker is a web service which has 
> WS-Resource associate with it, which is the list of subscribers.
> So this is how i have modelled the Notification delivery. 
> Broker will de couple the  Notification Producer and the 
> Notification consumer. So the publishing would be a In-Only 
> Operation for the broker.
> Then Broker will create client connections to the consumer 
> EPRs and Notify them in the push delivery mode.

I think WS-Eventing is similar to WS-Notification (which I don't know).
EventSources (server) accept subscriptions from and send notifications to
EventSinks (client). Notification messages can be both OUT and OUT-IN MEPs,
although WS-Eventing defines OUT as the default mode (push delivery mode).
To tell the truth I have no scenarios for OUT-IN (maybe ACK responses?), but
OUT only MEPs will be needed.

> It is not had to invent a programming model for Out-IN MEPed 
> service and there was some effort sometime back, but it 
> cannot be generalized sufficiently and i guess it didn't have 
> any use case. Further what is achieved by Out-In kind of 
> service can be achieved using a client API.

Right :-) !!! This is what I wanted to say with my last post. WSDL describes
the operations of a service and I think a good WSDL to Java tool should
generate code for all four different kinds of MEPs. OUT and OUT-IN from the
service view is the same like IN and IN-OUT from the client view and
therefore I can use the client API. And I want to use the client API, but I
don't want to code it manually and I don't want to use an "inverted" WSDL
file to generate a Stub that I can use within my service as explained here:

http://marc.theaimsgroup.com/?l=axis-user&m=113397248515948&w=2

My suggestion is to generate a further class, called xxxxSkeletonStub or
something like that, which contains methods for the OUT and OUT-IN
operations which in turn use the client API. This class should have the same
content as the stub class which would be generated if I would feed the
generator with a inverted WSDL file.

This approach is independent of WS-Eventing and WS-Notification.

Thank you, Andreas.



> On 1/24/06, Andreas Bobek <an...@uni-rostock.de> wrote:
> > Hi all,
> >
> > I read this thread in which you discussed about wsdl2java 
> support for 
> > out-only MEPs (or out-in):
> >
> > http://marc.theaimsgroup.com/?l=axis-user&m=113397248515948&w=2
> >
> > As a workaround you suggested to rewrite (to invert) the WSDL.
> > I understand this approach, but my question is, do you intend to 
> > support notification MEPs in wsdl2java in one of the next 
> version or 
> > not at all?
> > I think it is a MUST ;-)
> > Currently, I do some WS-Eventing stuff and I heavily miss 
> this feature.
> > I myself could imagine services which only have notification 
> > operations, and not a single "usual" request-response operation.
> >
> > Regards, Andreas Bobek.
> >
> >
> 
> 
> --
> Chathura Herath
> http://chathurah.blogspot.com/

Re: [Axis2] wsdl2java support for notification and solicit-response MEPs

[Chathura Herath <ch...@gmail.com>]

Hi,
Could you please explain the semantic meaning that you anticipate from
Out-In MEPed service. Reason why i am asking this is, I am personally
confused as to how the Out-In Service should work.
Is it service that is just running in the Axis2 Engine and depending
on some external event do a Out-In operation??
If so what would be that external event??? Is it the
publish/Notification message??
Notification is a Out-Only MEP. Strictly speaking its a
"In-Multiple-Out MEP". In message is the Notification Message by the
publisher to the Broker and the Multiple-Outs are the Broker to all
the Consumers.
sorry for using WS-Notification jargon, rather than Eventing.

I haven't tried WS-Eventing but i have done some basic work on
WS-Notification(Brokered) and to me using a complicated MEP is yet
another complication that won't give you much in return. Basically the
broker is a web service which has WS-Resource associate with it, which
is the list of subscribers.
So this is how i have modelled the Notification delivery. Broker will
de couple the  Notification Producer and the Notification consumer. So
the publishing would be a In-Only Operation for the broker.
Then Broker will create client connections to the consumer EPRs and
Notify them in the push delivery mode.

It is not had to invent a programming model for Out-IN MEPed service
and there was some effort sometime back, but it cannot be generalized
sufficiently and i guess it didn't have any use case. Further what is
achieved by Out-In kind of service can be achieved using a client API.

Thanks
Chathura


On 1/24/06, Andreas Bobek <an...@uni-rostock.de> wrote:
> Hi all,
>
> I read this thread in which you discussed about
> wsdl2java support for out-only MEPs (or out-in):
>
> http://marc.theaimsgroup.com/?l=axis-user&m=113397248515948&w=2
>
> As a workaround you suggested to rewrite (to invert) the WSDL.
> I understand this approach, but my question is, do you intend to
> support notification MEPs in wsdl2java in one of the next version or not at
> all?
> I think it is a MUST ;-)
> Currently, I do some WS-Eventing stuff and I heavily miss this feature.
> I myself could imagine services which only have notification operations,
> and not a single "usual" request-response operation.
>
> Regards, Andreas Bobek.
>
>


--
Chathura Herath
http://chathurah.blogspot.com/