Srinath Perera wrote:
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 .. :)
Never do things which are not inline with your thoughts :-)
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
"lookup ServiceContext" or "look in ServiceContext". I think even the
QName is fair enough, IFF we allow nulls to be passed in.
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
enough.
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)
..you can pass it to a Call and create a Call Object that has nice
interface .. but well configured.
hmm, you are not gonna do the right thing here, it seems. If Call is
for IN-OUT and InOutMEPClient is also for that, you should either
extend one from the other of should collapse both of them to one. I
can't still see a reason to do delegation.
Problem with the current approch is once you choose to configure
(using ServiceContext) you lose the nice interface.
Can you explain a bit more on this, please.
Chinthaka
Thanks
Srinath
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
|
