On Tue, 2006-10-10 at 17:54 -0500, Deepal Jayasinghe wrote:
> Why do we need operation client ?........
??? You gotta be kidding.
We have it because that's the client API for a generic MEP.
> As Dennis suggested , having annon name as public static seems not that
> good , so we need to remove them I mean we need to make the private.
Sorry I don't understand what you're referring to. If its the constants
we used to make the simple API work then I don't agree there's any
problem.
> Rather than giving two client API to client cant we have one API , we
> can have all the methods in serviceClient then no one need to know about
> the operationClient (service client will use that internally ). So our
> proposal is to add few more methods into ServiceCleint;
>
> public MessageContext sendReceive(MessageContext req){}
> public void sendReceiveNonBlocking(MessageContext req){}
> public fireAndForget(MessageContext req){}
> public sendRobust(MessageContext req){}
This only works for the 4 built-in MEPs. Have we decided to narrow Axis2
down to the built in MEPs? If so half of the machinery in Axis2 can be
removed.
> if we introduce these methods into ServiceClient then we do not too much
> worry about how to create operationClient etc...
>
> I am +1 on adding these four methods in to serviceClient.
Sorry, I'm -1 to this change. No way. It fundamentally breaks the client
API!!!!
If you want to do this then in the minimum it has to be after 1.1. No
way we're going to change the client API after RC1 has been cut!
> =======
> How do we reflect service group concept in to client , and manage
> session using that. Well I do understand if we use Axis2 client <->
> Axis2 service this will work , but what if we use .Net client <-> Axis2
> Service. Is there any kind of specification sending session related data
> in SOAP message ? , if there is such a thing then we need to use them.
You're forgetting a design decision we made a while ago: to make the
service group concept not visible to the outside. That's why we said
services withing group become top level services. I was against it but
that's what we decided. As such there's no need to expose it to the
client.
What will be useful is for one service in a group to be able to get the
EPR of another service in a group. Something like
ServiceGroupContext.getEPRForService ("serviceName"). That can propagate
the contextID etc. so that they share the same interaction session.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
