axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srinath Perera <>
Subject Re: [Axis2]Conserns on method signature on InOutMEPClient invokeXX()
Date Mon, 05 Dec 2005 19:45:38 GMT
> >Got two comments on the Client API (I am afraid I too involve in
> >designing them, but got doubts)
> >
> >At the MEPClient API, does is there a special reason to have the following two
> >
> >1) Have the OperationDescription as a input in the invokeXX()?
> >I think this do not make sense at all, we have already given the
> >ServiceContext at the constructor and we can look up the operation, it
> >is sufficent for user to just give a QName. Sometime users are force
> >to create a operation to invoke
> >
> >
> Well, we should ask this question from you, as AFAIK, you are the one
> who did that. Was it ?
I worte it .. but that was added at a meeting .. :)

> Anyway, how can you know from the service context, the operation you
> gonna invoke. You have to explicitly give the name of the operation. I
> agree that you it should not be a must to give the operation description.
> And at the same time, as once suggested by Paul, there should be a way
> to invoke a web service, without giving the name of the operation. I
> hope this is not weird.
shall we make it QName then? .. We can do the lookup ServiceContext
inside the invocation to and found the OperationDesc

> >2) Have the MessageContext as input
> >Are we gain anything with this that we can not have with options, how
> >about the SOAPEnvelope? Becouse MessageContext is vague .. and users
> >do not decide from the API what properties should be st or not.
> >
> >I am curious How many of you have EVER used the MEPClient API e.g.
> >InOutMEPCleint instead of Call. I have done it in few occasions, and
> >it was possible because I know what exactly going inside. Otherwise it
> >is not that easy to use that layer due to above method signatures. How
> >many of us developers use it?
> >
> >
> Its called flexibility man. If you know enough of Axis2, Call is not
> enough for you. There will be lot of people like that in the future, who
> will populate all the required information in to message context and
> give to AxisEngine.
> I do not want MessageContext to be removed from the methods. Having
> convenience methods is fine, but those do not necessitate to remove the
> low level methods.
Is there anything you can not done if MessageContext is removed? (we
have options ..).  If yes ..ok lets leave it as it is. If we can
remove the OperationDesc and put a QName .. then I feel it is fair

I thought of a  litte trick to have the both ends .. rather than Make
Call extends  InOutMEPCleint ..we can use delegation (keep a copy of
InOutMEPClient ..As long as java is concerned both has same overhead
.. extension keep copy of the super class anyway). This way if you
have a MEPClient you configured as you wish (Using ServiceContext) can pass it to a Call and create a Call Object that has nice
interface .. but well configured.

Problem with the current approch is once you choose to configure
(using ServiceContext) you lose the nice interface.

> Chinthaka
> >Thanks
> >Srinath
> >
> >p.s. Real reason for my Q is trouble I get while I implement the WSDL
> >based dynamic invoker. I get serious misgiving while trying to do it.
> >See below
> >
> >Problem with Dynamic Invocation
> >========================
> >I think I should be creating Call and MessageSender Objects rather
> >than InOutMEPClient and InOnlyMEPCleint as the latter accept message
> >contexts and  AxisOperations, as a result not very user friendly .
> >right?
> >
> >But if I choose the first I can not use the information available to me
> >via the WSDL (like AxisOperation) as Call and MessageSender assume
> >certain things (e.g. create a Dummy Operation by the name)
> >
> >What do you think and recommend? I am not sure which way to go
> >
> >
> >

View raw message