axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From HaoRan Zheng <>
Subject Re: [AXIS2] Questions about MEP
Date Wed, 17 Aug 2005 02:11:12 GMT
Thank you Chathura and Sanjiva:)
I think I got the meaning of MEP. The operations in WSDL2.0 world are
quite different from the operations in any normal programming
language. The former is an arbitrary MEP provider and the latter can
only be mapped into a simple MEP style like in-only and in-out etc.

So that's why the provider and MEP is interwinded in Axis2's design?
In Axis2, a service.xml is like this:
<operation name=... messageReceiver="RawXMLInOutMessageReceiver" />
In fact, I was thinking of seperating the provider from the MEP, like this:
<service provider="RawXMLProvider">
<operation name=... mep="in-out" />
The benefit of this seperation is that when we need to implement a new
provider, we don't have to implement a series of message receivers.
However, the question of this seperation is that it cannot support
custom MEPs, um...

On 8/17/05, Sanjiva Weerawarana <> wrote:
> On Tue, 2005-08-16 at 18:36 -0400, wrote:
> > You are absolutel right on that. To my knowledge such mapping is not
> > defined. We did some attempt to do a mapping and there are quite a few
> > ways we came up with. Idae was like if say MEP is In-Out-Out the methods
> > would be
> >
> > public void operation1OnMessagearrival1(<data bound arg1>);
> >
> > public <data bound return type> operation2OnMessageArrival(<data
> > boundobject>);
> >
> >
> >
> >
> >
> > So two methods for a single operation..
> >
> > But the discussions didnt go far because people didnt come up with valid
> > use case worth the effort and it bolied downed to do the mapping by
> > breaking the complex operation to simpler MEPs.
> +1 .. the Java programming language (or any other normal language for
> that matter) does not provide an intrinsic programming idiom to which an
> arbitrary MEP can be mapped. So one needs to come up with something as
> Chathura notes above.
> Because of the lack of a real arbitrary MEP, we have left that
> unaddressed in Axis2. However, the approach of delivering the message to
> a message receiver (the current arch) has ALL the support you need to
> implement any kind of programming idiom for supporting arbitrary MEPs.
> In particular, I note that BPEL can handle this just fine .. so when we
> build a BPEL impl tied to Axis2, it will indeed be able to support
> arbitrary MEPs and they will be delivered via a message receiver into
> the BPEL runtime directly.
> Sanjiva.

View raw message