Hi All; 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 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? 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
