You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Srinath Perera <he...@gmail.com> on 2006/03/03 18:41:24 UTC
[Axis2]UnsupportedOperationException on InOut MEP????
What does following error means? Axis2 seem to support OutIn MEP but
not IN-Out !!!!!
java.lang.UnsupportedOperationException: The MEP you are using
(http://www.w3.org/2004/08/wsdl/in-out) has not implemented
createClient().
at org.apache.axis2.description.AxisOperation.createClient(AxisOperation.java:443)
at org.apache.axis2.client.ServiceClient.createClient(ServiceClient.java:500)
at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:448)
at edu.indiana.extreme.lead.ws.Axis2WSDL4JBasedWebServiceInvoker.invoke(Axis2WSDL4JBasedWebServiceInvoker.java:334)
at SecuirtyInvocationTest1.doInvocation(SecuirtyInvocationTest1.java:61)
at SecuirtyInvocationTest1.testsecuirtyCallWithSync(SecuirtyInvocationTest1.java:19)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
--
============================
Srinath Perera:
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani
Re: [Axis2]UnsupportedOperationException on InOut MEP????
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Sat, 2006-03-04 at 07:53 -0500, Srinath Perera wrote:
> I think major point is WSDL have a notion that *everything is
> explained with respect to the Service Provider* in all times. (I think
> both you and glen says a the first F2F this is done to avoid need to
> have a client specific WSDL) .
WSDL is a language to describe the service. We're using AxisService on
the client side to describe the behavior of a client of a WSDL described
(or not) service. That's not the same thing; swapping is the right thing
to do.
> Even though looking the things at the Service Requester's point of
> view from the client can argued to be correct, with this model we are
> using MEP names from WSDL spec but we break *everything is explained
> with respsect to the Service Provider* rule. This will lead to lot of
> confusion. If we are using names from WSDL we must be consistsnt with
> their model.
Not all - we're not breaking everything .. I absolutely refuse to accept
that statement! We're taking the view that WSDL is a language for
describing stuff that's happening at the server.
What we internally need is a meta model saying what messages are going
and in what direction. If I'm on the server side, the pattern for an
operation being invoked from outside is that there's an incoming message
followed by an outgoing message. If I'm on the client the pattern is
opposite. Your position one must be forced to use the server's
description on the client side is forcing me to thing differently from
the actual message flow.
The model we have now is that no matter what side it is, we have an
AxisOperation describing exactly the message exchange involved. Then we
go to that and ask for a client to execute that operation. (BTW we no
longer have InOutMEPClient etc. too; I assume that was a typo!)
> Think for a moment following happens?
>
> Say one of my lab mate come and asked me "Why you guys call
> Request-Response a InOutMEPClient?". Then I explain how we are
> consistent with WSDL spec and explain everything with respect to the
> server ... so on
>
> If he come to me tommrrow and ask me why my service fails saying
> "InOutMep not found"? What am I suppose to say? I have to say my last
> explanation is no longer true .. this is new interpretations ... so
> on.
No there's no new interpretations; you tell him that we're modeling the
messages going back and forth ..
> If we use names from WSDL and break their model of *everything is
> explained with respect to the Service Provider* we are going to have
> lot of confused users and developers
I totally disagree. First of all, these is visible only to DII users.
Seecond, even in that case, the common pattern is:
- create an AxisService from the WSDL of the service
- get the client for the operation I want to invoke
- fill in the MCs
- execute
The user doesn't even deal with this directionality issue directly.
Sanjiva.
Re: [Axis2]UnsupportedOperationException on InOut MEP????
Posted by Srinath Perera <he...@gmail.com>.
I think major point is WSDL have a notion that *everything is
explained with respect to the Service Provider* in all times. (I think
both you and glen says a the first F2F this is done to avoid need to
have a client specific WSDL) .
Even though looking the things at the Service Requester's point of
view from the client can argued to be correct, with this model we are
using MEP names from WSDL spec but we break *everything is explained
with respsect to the Service Provider* rule. This will lead to lot of
confusion. If we are using names from WSDL we must be consistsnt with
their model.
Think for a moment following happens?
Say one of my lab mate come and asked me "Why you guys call
Request-Response a InOutMEPClient?". Then I explain how we are
consistent with WSDL spec and explain everything with respect to the
server ... so on
If he come to me tommrrow and ask me why my service fails saying
"InOutMep not found"? What am I suppose to say? I have to say my last
explanation is no longer true .. this is new interpretations ... so
on.
If we use names from WSDL and break their model of *everything is
explained with respect to the Service Provider* we are going to have
lot of confused users and developers
Thanks
Srinath
On 3/3/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Fri, 2006-03-03 at 20:16 -0500, Srinath Perera wrote:
> > is there a way to name operations in a way it is less confusing and so
> > do away with MEP based names. (e.g. SendRecive Operation ..
> > ReciveSendOperation ) We explained every body saying since MEP is
> > relative to the service provider .. we called request-response InOut
> > based on the argument.
>
> I think the names we have are fine- the names come from the message
> exchange pattern: so a client using an In-Out operation of a service
> executes an Out-In message exchange pattern. That is correct and
> accurate both w.r.t. the actual messages flowing and the WSDL.
>
> > Now if we start look at the things in the service requester's point of
> > view (while still using MEP names) .. it will be confusing. I have
> > mixed feeling on this ..
>
> I don't think its confusing: we're not mixing anything .. we're *always*
> looking at the underlying message exchange. WSDL is a description of
> that message exchange at the service from the point of view of the
> service. In our case, we're not generating WSDLs for the client (but we
> could if necessary) and it'd have reversed operations .. which again is
> the correct behavior.
>
> Sanjiva.
>
>
--
============================
Srinath Perera:
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani
Re: [Axis2]UnsupportedOperationException on InOut MEP????
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-03-03 at 20:16 -0500, Srinath Perera wrote:
> is there a way to name operations in a way it is less confusing and so
> do away with MEP based names. (e.g. SendRecive Operation ..
> ReciveSendOperation ) We explained every body saying since MEP is
> relative to the service provider .. we called request-response InOut
> based on the argument.
I think the names we have are fine- the names come from the message
exchange pattern: so a client using an In-Out operation of a service
executes an Out-In message exchange pattern. That is correct and
accurate both w.r.t. the actual messages flowing and the WSDL.
> Now if we start look at the things in the service requester's point of
> view (while still using MEP names) .. it will be confusing. I have
> mixed feeling on this ..
I don't think its confusing: we're not mixing anything .. we're *always*
looking at the underlying message exchange. WSDL is a description of
that message exchange at the service from the point of view of the
service. In our case, we're not generating WSDLs for the client (but we
could if necessary) and it'd have reversed operations .. which again is
the correct behavior.
Sanjiva.
Re: [Axis2]UnsupportedOperationException on InOut MEP????
Posted by Srinath Perera <he...@gmail.com>.
is there a way to name operations in a way it is less confusing and so
do away with MEP based names. (e.g. SendRecive Operation ..
ReciveSendOperation ) We explained every body saying since MEP is
relative to the service provider .. we called request-response InOut
based on the argument.
Now if we start look at the things in the service requester's point of
view (while still using MEP names) .. it will be confusing. I have
mixed feeling on this ..
Thanks very much
Srinath
On 3/3/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Sat, 2006-03-04 at 05:21 +0600, Sanjiva Weerawarana wrote:
> > > client side normal In-Out is called Out-In? (Which is against notions
> > > of WSDL2.0 AFAIK)
> >
> > No ..
>
> Sorry; my answer above could be confusing: The answer to your question
> above is "yes" .. what I said "no" for was your assertion that its
> against WSDL! WSDL (esp. 2.0) is very clear that its a description of
> the service from the service provider's point of view .. in means the
> message is going into the service provider and out of the service
> client. There's no confusion in WSDL at all; all we're doing is using
> the WSDL MEP concept on the client side and following exactly the same
> pattern.
>
> Sanjiva.
>
>
--
============================
Srinath Perera:
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani
Re: [Axis2]UnsupportedOperationException on InOut MEP????
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Sat, 2006-03-04 at 05:21 +0600, Sanjiva Weerawarana wrote:
> > client side normal In-Out is called Out-In? (Which is against notions
> > of WSDL2.0 AFAIK)
>
> No ..
Sorry; my answer above could be confusing: The answer to your question
above is "yes" .. what I said "no" for was your assertion that its
against WSDL! WSDL (esp. 2.0) is very clear that its a description of
the service from the service provider's point of view .. in means the
message is going into the service provider and out of the service
client. There's no confusion in WSDL at all; all we're doing is using
the WSDL MEP concept on the client side and following exactly the same
pattern.
Sanjiva.
Re: [Axis2]UnsupportedOperationException on InOut MEP????
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Glen,
> Wow, this is a serious -1 for me. We had this discussion, IIRC, at
> least twice (I think even at both F2Fs!), and I thought we'd resolved to
> keep things in terms of the WSDL model and have a "role" switch which
This was done months ago .. way before the ApacheCon F2F even!
> indicates whether the current processor is the client or the server
> (i.e. the message labels stay the same but the sending/receiving roles
> switch).
Actually it works very nicely .. and makes the client stuff work exactly
as a message receiver: the order of messages is crystal clear and
processing is clearer. (IMO, of course.)
> If you go switching the MEP, then you've switched the message names
> ("in" becomes "out", etc), and therefore any policies, extensions, or
> other specs or code that have been written in terms of the message
> labels (or the MEP name) ALSO need to be switched.
No they don't need to be switched: the policies are attached to
something. If they're attached to the WSDL, there's NO confusion
whatsoever. The "switch" occurs when building the AxisService from the
WSDL; hence the need for the switch at that time.
If they're attached to the flows, there's NO confusion whatsoever as one
speaks in terms of "in-flow" and "out-flow" and in means in and out
means out in all cases. Its actually more natural because there's no
idea of "in-flow" meaning actually the out message flow on the client
side.
> This is a nightmare
> - what if some serialized data in a message refers to something by
> message label?
? I don't get the scenario; you want to allow a response coming back
from a service to the client to have some serialized data referring to
the WSDL message label of the outgoing message?? That doesn't seem
sensible to me. Maybe I'm missing something; please clarify.
> Please reconsider - doing it this way (changing the actual model instead
> of simply changing what role you play in USING the model) is very
> confusing and I believe may lead to serious problems down the road.
This was done because the other model was causing serious problems ..
this has cleared up a lot of internals because there's never an issue of
in meaning out or out meaning in any more.
I know its a big jump if this is the first time you are hitting into it.
But it does clear a lot of stuff up and makes it much easier to do the
guts including policy processing.
Sanjiva.
p.s.: I'm going to be in a plane for the next day (and then in meetings
for 3 days followed by 2 days of planes) so responses will be slow.
Re: [Axis2]UnsupportedOperationException on InOut MEP????
Posted by Glen Daniels <gl...@thoughtcraft.com>.
> Please reconsider - doing it this way (changing the actual model instead
> of simply changing what role you play in USING the model) is very
> confusing and I believe may lead to serious problems down the road.
My -1, by the way, was a "yuk this is a bad idea", and not a "pull that
code out now" Apache Process -1. I will give this some more thought and
look at the conversation logs if I get time (I'm in an XMLP meeting
today), but my sense is that the current design will lead to badness....
--G
Re: [Axis2]UnsupportedOperationException on InOut MEP????
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Sanjiva:
Sanjiva Weerawarana wrote:
> Yes you have to do it somewhere .. with the current model the if() is
> done at the point of constructing an AxisService object from the WSDL:
> if its the server side then an in-out in WSDL becomes and In-Out MEP
> operation and if its a client we create an Out-In MEP operation to
> represent the fact that from the point of view of the client, the
> operation is an Out-In.
Wow, this is a serious -1 for me. We had this discussion, IIRC, at
least twice (I think even at both F2Fs!), and I thought we'd resolved to
keep things in terms of the WSDL model and have a "role" switch which
indicates whether the current processor is the client or the server
(i.e. the message labels stay the same but the sending/receiving roles
switch).
If you go switching the MEP, then you've switched the message names
("in" becomes "out", etc), and therefore any policies, extensions, or
other specs or code that have been written in terms of the message
labels (or the MEP name) ALSO need to be switched. This is a nightmare
- what if some serialized data in a message refers to something by
message label?
Please reconsider - doing it this way (changing the actual model instead
of simply changing what role you play in USING the model) is very
confusing and I believe may lead to serious problems down the road.
Thanks,
--Glen
Re: [Axis2]UnsupportedOperationException on InOut MEP????
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-03-03 at 20:02 -0500, Srinath Perera wrote:
> On the other hand now the WSDL should be interpreted knowing it is
> parsed at the server side or client side and interchange the MEP name
> if it is at the client. We are adding another set of if() with new
> model. .. yes we should choosing less evil one
Yes you have to do it somewhere .. with the current model the if() is
done at the point of constructing an AxisService object from the WSDL:
if its the server side then an in-out in WSDL becomes and In-Out MEP
operation and if its a client we create an Out-In MEP operation to
represent the fact that from the point of view of the client, the
operation is an Out-In.
> > Code sharing :(. Maybe that should be refactored to some util stuff.
> Usually if we have a extension hierarchy which is not true in the real
> world (e.g. InOutMepClient is in no way a generalization of the
> OutInMepClient).. that means something is wrong. We should move it to
> a Util .. as it mislead developer
+1.
> > > What is going on? Either I am not seeing something obvious something
> > > terribly wrong? Please let me know what I am suppose to do?
> >
> > The problem is that there's a bug in the new ServiceClient (WSDL) code;
> > its building the wrong kind of AxisOperation objects. Someone else
> > (Fernando?) reported that bug too yesterday IIRC. I believe he created a
> > JIRA.
> At least I understood the argument for the change? (Even though I am
> not convinced yet.. this is a too big change ... thinking :) ) I
> think code that build a service from WSDL need a to have a parameter
> passed in called isServerSide. I will fix it ( I can not continue my
> work without fixing it).
I'd prefer to have two separate methods:
class AxisService {
static createServiceFromWSDL (WSDL)
static createClientFromWSDL (WSDL)
}
(I'm posting a comment on the parallel JIRA discussion.)
> Thanks very much for the explanation :), Please do a big announcement
> when this kind of thing is done (was it there? I missed it if it was).
> I was taken completely off guard
Sorry! There were various announcements but maybe it wasn't big enough!
Sanjiva.
Re: [Axis2]UnsupportedOperationException on InOut MEP????
Posted by Srinath Perera <he...@gmail.com>.
> > That means one can not use the Service build from the WSDL in the
> > client side as operations says wrong MEP. Do we need to do a different
> > WSDL parsing and building AxisOperation for Server and client side?
>
> Yes; the MEP *always* represents the actual direction of message flow.
> That simplifies a lot of stuff and does not force you to keep saying "if
> client out means in and in means out" .. now out always means out and in
> always means in.
On the other hand now the WSDL should be interpreted knowing it is
parsed at the server side or client side and interchange the MEP name
if it is at the client. We are adding another set of if() with new
model. .. yes we should choosing less evil one
> > Why Out-In AxisOperation extends InOutAxisOperation .. which not at
> > all make sense to me?
>
> Code sharing :(. Maybe that should be refactored to some util stuff.
Usually if we have a extension hierarchy which is not true in the real
world (e.g. InOutMepClient is in no way a generalization of the
OutInMepClient).. that means something is wrong. We should move it to
a Util .. as it mislead developer
>
> > What is going on? Either I am not seeing something obvious something
> > terribly wrong? Please let me know what I am suppose to do?
>
> The problem is that there's a bug in the new ServiceClient (WSDL) code;
> its building the wrong kind of AxisOperation objects. Someone else
> (Fernando?) reported that bug too yesterday IIRC. I believe he created a
> JIRA.
At least I understood the argument for the change? (Even though I am
not convinced yet.. this is a too big change ... thinking :) ) I
think code that build a service from WSDL need a to have a parameter
passed in called isServerSide. I will fix it ( I can not continue my
work without fixing it).
Thanks very much for the explanation :), Please do a big announcement
when this kind of thing is done (was it there? I missed it if it was).
I was taken completely off guard
Thanks
Srinath
Re: [Axis2]UnsupportedOperationException on InOut MEP????
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-03-03 at 13:04 -0500, Srinath Perera wrote:
> Team;
> Have we flipped the MEP in the client side? Is it the case that at the
Yes ..
> client side normal In-Out is called Out-In? (Which is against notions
> of WSDL2.0 AFAIK)
No ..
> That means one can not use the Service build from the WSDL in the
> client side as operations says wrong MEP. Do we need to do a different
> WSDL parsing and building AxisOperation for Server and client side?
Yes; the MEP *always* represents the actual direction of message flow.
That simplifies a lot of stuff and does not force you to keep saying "if
client out means in and in means out" .. now out always means out and in
always means in.
> Why Out-In AxisOperation extends InOutAxisOperation .. which not at
> all make sense to me?
Code sharing :(. Maybe that should be refactored to some util stuff.
> What is going on? Either I am not seeing something obvious something
> terribly wrong? Please let me know what I am suppose to do?
The problem is that there's a bug in the new ServiceClient (WSDL) code;
its building the wrong kind of AxisOperation objects. Someone else
(Fernando?) reported that bug too yesterday IIRC. I believe he created a
JIRA.
Sorry for the confusion. Hope this helps!
Sanjiva.
Re: [Axis2]UnsupportedOperationException on InOut MEP????
Posted by Srinath Perera <he...@gmail.com>.
Team;
Have we flipped the MEP in the client side? Is it the case that at the
client side normal In-Out is called Out-In? (Which is against notions
of WSDL2.0 AFAIK)
That means one can not use the Service build from the WSDL in the
client side as operations says wrong MEP. Do we need to do a different
WSDL parsing and building AxisOperation for Server and client side?
Why Out-In AxisOperation extends InOutAxisOperation .. which not at
all make sense to me?
What is going on? Either I am not seeing something obvious something
terribly wrong? Please let me know what I am suppose to do?
Srinath
On 3/3/06, Srinath Perera <he...@gmail.com> wrote:
> What does following error means? Axis2 seem to support OutIn MEP but
> not IN-Out !!!!!
>
> java.lang.UnsupportedOperationException: The MEP you are using
> (http://www.w3.org/2004/08/wsdl/in-out) has not implemented
> createClient().
> at org.apache.axis2.description.AxisOperation.createClient(AxisOperation.java:443)
> at org.apache.axis2.client.ServiceClient.createClient(ServiceClient.java:500)
> at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:448)
> at edu.indiana.extreme.lead.ws.Axis2WSDL4JBasedWebServiceInvoker.invoke(Axis2WSDL4JBasedWebServiceInvoker.java:334)
> at SecuirtyInvocationTest1.doInvocation(SecuirtyInvocationTest1.java:61)
> at SecuirtyInvocationTest1.testsecuirtyCallWithSync(SecuirtyInvocationTest1.java:19)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
>
>
> --
> ============================
> Srinath Perera:
> http://www.cs.indiana.edu/~hperera/
> http://www.bloglines.com/blog/hemapani
>
--
============================
Srinath Perera:
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani