axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srinath Perera <hemap...@gmail.com>
Subject Re: [Axis2]Conserns on method signature on InOutMEPClient invokeXX()
Date Tue, 06 Dec 2005 02:44:28 GMT
What I thought is something like this

1. Call keep a instance of a MEPClient inside it and call the methods
providing a nicer interface (e.g. OMElement instead of MessageContext)

2. Call have a new Call(MEPClient){ ..} constructer that allow the
user to create a Call (have a nicer interface) that wrap his MEP
Client. Plus Call has old constructors which will create a MEPClient
inside it.

Problem I try to solve with this is following

1) I want to create a configured MEPClient out of a WSDL. Since I have
detail like AxisService..operations ect I like to use MEPClient
interface and create a *configured* MEPClient.

2) But with existing thingy .. now I am stuck to MEPClient interface
..I want to give users an easy to use interface. What I purpose is a
new Call(mepclient); method that allow to have a nicer interface to
the MEPClient.

If we can not do that .. I can write a wrapper classes to wrap
InOnlyMEPClient and InOutMEPClient to provide a nicer interfaces
..That would add ugly two classes to Client classes.

In anycase I consider forcing dynamic invocation (WSDL based builder)
users to use the complex MEPClient interfaces as unaccetable.
Thanks
Srinath



On 12/5/05, Eran Chinthaka <chinthaka@opensource.lk> wrote:
>
>
>  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
>
>
>
>
>
>

Mime
View raw message