Re: [Axis2] Summery of todays Hackathon
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.
I mean we want to make those public variable into private , currently
there are four public static variable with annon name.
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.
I didnt mean it , what I mean was those are the most commonly use MEP so
adding those method into ServiceClinet provide a way to access message
context and SOAPEnvelop w.o creating operation client. Yes , I agree
that adding four methods make service client API bit ugly :)
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
Then forget abt that , I do not really want to break any fundamental design.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Summery of todays Hackathon
Hi All;
Few note from todays Hackathon we had at ApacheCon US.
We are having very ugly name called finalizeInvoke() in service client
with restriction, so we (Glen and I agreed) to remove that method and
move the code into cleanup (well I am doing the changes in current
codebase).
Why do we need operation client ?
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.
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){}
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.
===
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.
Thanks
Deepal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Summery of todays Hackathon
Deepal,
Please create JIRA issue(s) and let's work on them.
thanks,
dims
On 10/10/06, Deepal Jayasinghe [EMAIL PROTECTED] wrote:
Hi All;
Few note from todays Hackathon we had at ApacheCon US.
We are having very ugly name called finalizeInvoke() in service client
with restriction, so we (Glen and I agreed) to remove that method and
move the code into cleanup (well I am doing the changes in current
codebase).
Why do we need operation client ?
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.
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){}
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.
===
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.
Thanks
Deepal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Summery of todays Hackathon
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]
