You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2004/12/15 17:27:17 UTC
Fwd: [axis2] Proposal for Client API
(Forwarding with the proper subject filter.)
----- Original Message -----
From: Jaliya Ekanayake
To: axis-dev@ws.apache.org
Cc: deepal@opensource.lk
Sent: Wednesday, December 15, 2004 7:07 PM
Subject: [Axis 2] Proposal for Client API
Hi All,
It is time to discuss about the Client API for Axis2. Deepal and I have come up with a proposal for it. Please have a look at the wiki
http://wiki.apache.org/ws/FrontPage/Architecture/Client
Please comment. It is better if we can discuss this a bit in the tomorrow's chat.
We need a good name for the "ProviderX" as well J
Jaliya N. Ekanayake
Lanka Software Foundation
(www.opensource.lk)
Fwd: [axis2] Proposal for Client API
Posted by Srinath Perera <he...@gmail.com>.
---------- Forwarded message ----------
From: Srinath Perera <he...@gmail.com>
Date: Thu, 16 Dec 2004 18:16:06 +0600
Subject: Re: [axis2] Proposal for Client API
To: Jaliya Ekanayake <ja...@opensource.lk>
On Thu, 16 Dec 2004 17:47:52 +0600, Jaliya Ekanayake
<ja...@opensource.lk> wrote:
> Srinath,
>
> IMO, there is no direct relation to the WSDL MEP and the client invocation
> by sync/async. As I have mentioned earlier, an operation specified as IN-OUT
> in WSDL can be accessed by the client both in sync and async manner. And
> there are two types of async invocations involved.
+1 yes (to select a reciver we need two kinds of info
1) MEPS
2) is it sync and Async
> 1. Async behavior using a client side API (here still a synchronous
> communication happen at the transport level)
> 2. Async behavior in both the client code and in the transport.
>
> In the second case the response is similar to an input to the engine as it
> now acts as a server. However by deploying a ClientReceiver in this client
> side engine, we can handle the additional complexity involved when using
> callbacks using this receiver.
>
> The existing call class does not support the 2nd type shown.
yes but is can handled easily let me update the call to show the logic
e.g. this is one way to handle it by registrring a new service in the
started simeple axis server (reciver)
public void completeAsyncCall(OMElement in, URL url, final CallBack callback) {
try {
.........
engine.send(msgctx);
EngineRegitry er = engine.getRegistry()
TransportReciverFactory.startReciverIfNotYetStrated(er);
AxisService service =
Utils.createASserviceThatCallCallback(msgID,callback);
er.addService(service);
} catch (OMException e) {
throw AxisFault.makeFault(e);
} catch (IOException e) {
throw AxisFault.makeFault(e);
}
}
Thanks
Srinath
> -----Original Message-----
> From: Srinath Perera [mailto:hemapani@gmail.com]
> Sent: Thursday, December 16, 2004 4:48 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [axis2] Proposal for Client API
>
> > Why we need different way to invoke it. According to the today's chat it
> > will be a Receiver. May be the name will be ClientReceiver or something.
> >
> > Client receiver should have the logic to handle the sync or async cases
> and
> > it may get them by looking at the message context.
> > So the provider will be called by the receiver. (This is also not a must).
>
> > I think it is better if we add an integer field named message type. This
> > can have the values of
> > IN_ONLY
> >
> > IN_OUT_SYNC
> >
> > IN_OUT_ASYNC
> > So we can use them in appropriate locations, sync and async is not that
> > informative.
> > So the message context will have the following methods.
> > void setMessageType(int messageType);
> >
> > int getMessageType();
> 1) At the server side we do not need MessageType attribute as this
> info mation can be get from the WSDL (MEPS ) and from the Service
> deployment parameter
> 2) At the client side we can always decide sync/async logic with in
> the Call. We can do the work without clinet Reciver. Look in the Call
> classwriten, note the execution of the engine do not change in anyway
> due to fact it is sync or async! everything is hanled inside Call.
>
> We can do it without ClinetRecivers or messageType attribute if we need.
> Thanks
> Srinath
>
> > From: Deepal Jayasinghe [mailto:deepal@opensource.lk]
> > Sent: Thursday, December 16, 2004 2:27 PM
> > To: axis-dev@ws.apache.org
> > Subject: Re: [axis2] Proposal for Client API
> >
> >
> >
> >
> >
> > hi all;
> >
> >
> >
> >
> >
> > if you go to the sequence diagram shown in the following link
> >
> >
> >
> >
> >
> > http://wiki.apache.org/ws/FrontPage/Architecture/Client
> >
> >
> >
> >
> >
> > ProviderX should behave different way in invokeInOut() and invokeAsync().
> >
> >
> > in order to do that ProviderX should be know a condition , so I think if
> we
> > can keep a property
> >
> >
> > in msgContxt to handle that it make the implementation easier. so my
> > suggestion is to have
> >
> >
> > two methods in msgContxt
> >
> >
> >
> >
> >
> > void MC.setAsyncMsg(boolean value);
> >
> >
> > boolean MC.isAsyncMsg(): ;
> >
> >
> >
> >
> >
> > thoughts ?
> >
> >
> >
> >
> >
> >
> >
> >
> > Deepal
> >
> >
> >
> >
> >
> >
> > ----- Original Message -----
> >
> >
> > From: Sanjiva Weerawarana
> >
> >
> > To: axis-dev@ws.apache.org
> >
> >
> > Sent: Wednesday, December 15, 2004 10:27 PM
> >
> >
> > Subject: Fwd: [axis2] Proposal for Client API
> >
> >
> >
> >
> >
> > (Forwarding with the proper subject filter.)
> >
> >
> >
> >
> >
> > ----- Original Message -----
> >
> >
> > From: Jaliya Ekanayake
> >
> >
> > To: axis-dev@ws.apache.org
> >
> >
> > Cc: deepal@opensource.lk
> >
> >
> > Sent: Wednesday, December 15, 2004 7:07 PM
> >
> >
> > Subject: [Axis 2] Proposal for Client API
> >
> >
> >
> >
> > Hi All,
> >
> >
> >
> > It is time to discuss about the Client API for Axis2. Deepal and I have
> come
> > up with a proposal for it. Please have a look at the wiki
> >
> > http://wiki.apache.org/ws/FrontPage/Architecture/Client
> >
> >
> >
> > Please comment. It is better if we can discuss this a bit in the
> tomorrow's
> > chat.
> >
> > We need a good name for the "ProviderX" as well J
> >
> >
> >
> > Jaliya N. Ekanayake
> >
> > Lanka Software Foundation
> >
> > (www.opensource.lk)
> >
> >
>
>
RE: [axis2] Proposal for Client API
Posted by Jaliya Ekanayake <ja...@opensource.lk>.
Srinath,
IMO, there is no direct relation to the WSDL MEP and the client invocation
by sync/async. As I have mentioned earlier, an operation specified as IN-OUT
in WSDL can be accessed by the client both in sync and async manner. And
there are two types of async invocations involved.
1. Async behavior using a client side API (here still a synchronous
communication happen at the transport level)
2. Async behavior in both the client code and in the transport.
In the second case the response is similar to an input to the engine as it
now acts as a server. However by deploying a ClientReceiver in this client
side engine, we can handle the additional complexity involved when using
callbacks using this receiver.
The existing call class does not support the 2nd type shown.
Thanks
Jaliya N. Ekanayake
-----Original Message-----
From: Srinath Perera [mailto:hemapani@gmail.com]
Sent: Thursday, December 16, 2004 4:48 PM
To: axis-dev@ws.apache.org
Subject: Re: [axis2] Proposal for Client API
> Why we need different way to invoke it. According to the today's chat it
> will be a Receiver. May be the name will be ClientReceiver or something.
>
> Client receiver should have the logic to handle the sync or async cases
and
> it may get them by looking at the message context.
> So the provider will be called by the receiver. (This is also not a must).
> I think it is better if we add an integer field named message type. This
> can have the values of
> IN_ONLY
>
> IN_OUT_SYNC
>
> IN_OUT_ASYNC
> So we can use them in appropriate locations, sync and async is not that
> informative.
> So the message context will have the following methods.
> void setMessageType(int messageType);
>
> int getMessageType();
1) At the server side we do not need MessageType attribute as this
info mation can be get from the WSDL (MEPS ) and from the Service
deployment parameter
2) At the client side we can always decide sync/async logic with in
the Call. We can do the work without clinet Reciver. Look in the Call
classwriten, note the execution of the engine do not change in anyway
due to fact it is sync or async! everything is hanled inside Call.
We can do it without ClinetRecivers or messageType attribute if we need.
Thanks
Srinath
> From: Deepal Jayasinghe [mailto:deepal@opensource.lk]
> Sent: Thursday, December 16, 2004 2:27 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [axis2] Proposal for Client API
>
>
>
>
>
> hi all;
>
>
>
>
>
> if you go to the sequence diagram shown in the following link
>
>
>
>
>
> http://wiki.apache.org/ws/FrontPage/Architecture/Client
>
>
>
>
>
> ProviderX should behave different way in invokeInOut() and invokeAsync().
>
>
> in order to do that ProviderX should be know a condition , so I think if
we
> can keep a property
>
>
> in msgContxt to handle that it make the implementation easier. so my
> suggestion is to have
>
>
> two methods in msgContxt
>
>
>
>
>
> void MC.setAsyncMsg(boolean value);
>
>
> boolean MC.isAsyncMsg(): ;
>
>
>
>
>
> thoughts ?
>
>
>
>
>
>
>
>
> Deepal
>
>
>
>
>
>
> ----- Original Message -----
>
>
> From: Sanjiva Weerawarana
>
>
> To: axis-dev@ws.apache.org
>
>
> Sent: Wednesday, December 15, 2004 10:27 PM
>
>
> Subject: Fwd: [axis2] Proposal for Client API
>
>
>
>
>
> (Forwarding with the proper subject filter.)
>
>
>
>
>
> ----- Original Message -----
>
>
> From: Jaliya Ekanayake
>
>
> To: axis-dev@ws.apache.org
>
>
> Cc: deepal@opensource.lk
>
>
> Sent: Wednesday, December 15, 2004 7:07 PM
>
>
> Subject: [Axis 2] Proposal for Client API
>
>
>
>
> Hi All,
>
>
>
> It is time to discuss about the Client API for Axis2. Deepal and I have
come
> up with a proposal for it. Please have a look at the wiki
>
> http://wiki.apache.org/ws/FrontPage/Architecture/Client
>
>
>
> Please comment. It is better if we can discuss this a bit in the
tomorrow's
> chat.
>
> We need a good name for the "ProviderX" as well J
>
>
>
> Jaliya N. Ekanayake
>
> Lanka Software Foundation
>
> (www.opensource.lk)
>
>
Re: [axis2] Proposal for Client API
Posted by Srinath Perera <he...@gmail.com>.
> Why we need different way to invoke it. According to the today's chat it
> will be a Receiver. May be the name will be ClientReceiver or something.
>
> Client receiver should have the logic to handle the sync or async cases and
> it may get them by looking at the message context.
> So the provider will be called by the receiver. (This is also not a must).
> I think it is better if we add an integer field named message type. This
> can have the values of
> IN_ONLY
>
> IN_OUT_SYNC
>
> IN_OUT_ASYNC
> So we can use them in appropriate locations, sync and async is not that
> informative.
> So the message context will have the following methods.
> void setMessageType(int messageType);
>
> int getMessageType();
1) At the server side we do not need MessageType attribute as this
info mation can be get from the WSDL (MEPS ) and from the Service
deployment parameter
2) At the client side we can always decide sync/async logic with in
the Call. We can do the work without clinet Reciver. Look in the Call
classwriten, note the execution of the engine do not change in anyway
due to fact it is sync or async! everything is hanled inside Call.
We can do it without ClinetRecivers or messageType attribute if we need.
Thanks
Srinath
> From: Deepal Jayasinghe [mailto:deepal@opensource.lk]
> Sent: Thursday, December 16, 2004 2:27 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [axis2] Proposal for Client API
>
>
>
>
>
> hi all;
>
>
>
>
>
> if you go to the sequence diagram shown in the following link
>
>
>
>
>
> http://wiki.apache.org/ws/FrontPage/Architecture/Client
>
>
>
>
>
> ProviderX should behave different way in invokeInOut() and invokeAsync().
>
>
> in order to do that ProviderX should be know a condition , so I think if we
> can keep a property
>
>
> in msgContxt to handle that it make the implementation easier. so my
> suggestion is to have
>
>
> two methods in msgContxt
>
>
>
>
>
> void MC.setAsyncMsg(boolean value);
>
>
> boolean MC.isAsyncMsg(): ;
>
>
>
>
>
> thoughts ?
>
>
>
>
>
>
>
>
> Deepal
>
>
>
>
>
>
> ----- Original Message -----
>
>
> From: Sanjiva Weerawarana
>
>
> To: axis-dev@ws.apache.org
>
>
> Sent: Wednesday, December 15, 2004 10:27 PM
>
>
> Subject: Fwd: [axis2] Proposal for Client API
>
>
>
>
>
> (Forwarding with the proper subject filter.)
>
>
>
>
>
> ----- Original Message -----
>
>
> From: Jaliya Ekanayake
>
>
> To: axis-dev@ws.apache.org
>
>
> Cc: deepal@opensource.lk
>
>
> Sent: Wednesday, December 15, 2004 7:07 PM
>
>
> Subject: [Axis 2] Proposal for Client API
>
>
>
>
> Hi All,
>
>
>
> It is time to discuss about the Client API for Axis2. Deepal and I have come
> up with a proposal for it. Please have a look at the wiki
>
> http://wiki.apache.org/ws/FrontPage/Architecture/Client
>
>
>
> Please comment. It is better if we can discuss this a bit in the tomorrow's
> chat.
>
> We need a good name for the "ProviderX" as well J
>
>
>
> Jaliya N. Ekanayake
>
> Lanka Software Foundation
>
> (www.opensource.lk)
>
>
Re: [axis2] Proposal for Client API
Posted by Deepal Jayasinghe <de...@opensource.lk>.
+1
sound good.
thanks .
Deepal.
----- Original Message -----
From: Jaliya Ekanayake
To: axis-dev@ws.apache.org
Sent: Thursday, December 16, 2004 2:53 PM
Subject: RE: [axis2] Proposal for Client API
Deepal,
Why we need different way to invoke it. According to the today's chat it will be a Receiver. May be the name will be ClientReceiver or something.
Client receiver should have the logic to handle the sync or async cases and it may get them by looking at the message context.
So the provider will be called by the receiver. (This is also not a must).
I think it is better if we add an integer field named message type. This can have the values of
IN_ONLY
IN_OUT_SYNC
IN_OUT_ASYNC
So we can use them in appropriate locations, sync and async is not that informative.
So the message context will have the following methods.
void setMessageType(int messageType);
int getMessageType();
Thanks,
Jaliya N. Ekanayake
Lanka Software Foundation
(www.opensource.lk)
------------------------------------------------------------------------------
From: Deepal Jayasinghe [mailto:deepal@opensource.lk]
Sent: Thursday, December 16, 2004 2:27 PM
To: axis-dev@ws.apache.org
Subject: Re: [axis2] Proposal for Client API
hi all;
if you go to the sequence diagram shown in the following link
http://wiki.apache.org/ws/FrontPage/Architecture/Client
ProviderX should behave different way in invokeInOut() and invokeAsync().
in order to do that ProviderX should be know a condition , so I think if we can keep a property
in msgContxt to handle that it make the implementation easier. so my suggestion is to have
two methods in msgContxt
void MC.setAsyncMsg(boolean value);
boolean MC.isAsyncMsg(): ;
thoughts ?
Deepal
----- Original Message -----
From: Sanjiva Weerawarana
To: axis-dev@ws.apache.org
Sent: Wednesday, December 15, 2004 10:27 PM
Subject: Fwd: [axis2] Proposal for Client API
(Forwarding with the proper subject filter.)
----- Original Message -----
From: Jaliya Ekanayake
To: axis-dev@ws.apache.org
Cc: deepal@opensource.lk
Sent: Wednesday, December 15, 2004 7:07 PM
Subject: [Axis 2] Proposal for Client API
Hi All,
It is time to discuss about the Client API for Axis2. Deepal and I have come up with a proposal for it. Please have a look at the wiki
http://wiki.apache.org/ws/FrontPage/Architecture/Client
Please comment. It is better if we can discuss this a bit in the tomorrow's chat.
We need a good name for the "ProviderX" as well J
Jaliya N. Ekanayake
Lanka Software Foundation
(www.opensource.lk)
RE: [axis2] Proposal for Client API
Posted by Chathura Herath <ch...@opensource.lk>.
Thanks for getting rid of html junk ;)
> -----Original Message-----
> From: Srinath Perera [mailto:hemapani@gmail.com]
> Sent: Thursday, December 16, 2004 5:41 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [axis2] Proposal for Client API
>
> > IMO we haven't talked about specifically how the client side wsdd
> parsing is going to happen and how those info be eventually be set to the
> message context. Well we promoted concept of symmetry in server side and
> client side. So if that is the case it shouldn't be the registry that
> keeps the wsdd info, because if I remember right server side out path is
> initiated by the sender.
> what ever happens the it is registry that holds the infomation about
> the services but it is Call that parse the server.xml, I think that is
> what you mean :)
Yup. I just looked at the call class and what lies there fits what I had in
mind and it filled some missing parts. In fact I should have mentioned above
the fact that how the parsing happen inside call is by simply reusing the
components that is used at the server side.
Thanks
Chathura
Re: [axis2] Proposal for Client API
Posted by Srinath Perera <he...@gmail.com>.
> IMO we haven't talked about specifically how the client side wsdd parsing is going to happen and how those info be eventually be set to the message context. Well we promoted concept of symmetry in server side and client side. So if that is the case it shouldn't be the registry that keeps the wsdd info, because if I remember right server side out path is initiated by the sender.
what ever happens the it is registry that holds the infomation about
the services but it is Call that parse the server.xml, I think that is
what you mean :)
> Correct me if I'm wrong Think it's the call who should create the Messagecontext. So this wsdd info or a pointer to that should eventually end up in the Call at the time of the Creation of Message Context.
yap have a look at the Call class constructer already there ;)
Thanks
Srinath
>
> Regards
> Chathura
>
> ________________________________________
> From: Jaliya Ekanayake [mailto:jaliya@opensource.lk]
> Sent: Thursday, December 16, 2004 4:36 PM
> To: axis-dev@ws.apache.org
> Subject: RE: [axis2] Proposal for Client API
>
> Hi Chathura,
>
> The requirement is to let the client side handlers to decide the certain factors. If the WSDL says the operation is IN-OUT, the client can invoke it either synchronously or asynchronously. So we need a mechanism to store these properties. It may be possible to take them from the WSDD as well. Then we need to decide where we can keep the WSDD information in the client side. Is it the engine registry?
>
> Please comment
>
> Jaliya
> ________________________________________
> From: Chathura Herath [mailto:chathura@opensource.lk]
> Sent: Thursday, December 16, 2004 3:59 PM
> To: axis-dev@ws.apache.org
> Subject: RE: [axis2] Proposal for Client API
>
> Hi Jaliya, Deepal, all,
>
> Here is my idea.
> We should not introduce a new property for the MC, instead the MEP can be taken out from the Service Desc and it is already there. So not only the MEP's you mentioned, but the concept of MEP in WSDL 2.0 can be brought in keeping open the opportunity for MEP extensions.
>
> Further I believe the deployment will know weather an operation is sync or async at the deployment time. So think that should go in as a new method to the AxisOperation in the service Desc.
>
> Thoughts
>
> Cheers
> Chathura
>
> ________________________________________
> From: Jaliya Ekanayake [mailto:jaliya@opensource.lk]
> Sent: Thursday, December 16, 2004 2:53 PM
> To: axis-dev@ws.apache.org
> Subject: RE: [axis2] Proposal for Client API
>
> Deepal,
>
> Why we need different way to invoke it. According to the today's chat it will be a Receiver. May be the name will be ClientReceiver or something.
> Client receiver should have the logic to handle the sync or async cases and it may get them by looking at the message context.
>
> So the provider will be called by the receiver. (This is also not a must).
>
> I think it is better if we add an integer field named message type. This can have the values of
>
> IN_ONLY
> IN_OUT_SYNC
> IN_OUT_ASYNC
>
> So we can use them in appropriate locations, sync and async is not that informative.
>
> So the message context will have the following methods.
>
> void setMessageType(int messageType);
> int getMessageType();
>
> Thanks,
>
> Jaliya N. Ekanayake
> Lanka Software Foundation
> (www.opensource.lk)
> ________________________________________
> From: Deepal Jayasinghe [mailto:deepal@opensource.lk]
> Sent: Thursday, December 16, 2004 2:27 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [axis2] Proposal for Client API
>
> hi all;
>
> if you go to the sequence diagram shown in the following link
>
> http://wiki.apache.org/ws/FrontPage/Architecture/Client
>
> ProviderX should behave different way in invokeInOut() and invokeAsync().
> in order to do that ProviderX should be know a condition , so I think if we can keep a property
> in msgContxt to handle that it make the implementation easier. so my suggestion is to have
> two methods in msgContxt
>
> void MC.setAsyncMsg(boolean value);
> boolean MC.isAsyncMsg(): ;
>
> thoughts ?
>
> Deepal
>
> ----- Original Message -----
> From: Sanjiva Weerawarana
> To: axis-dev@ws.apache.org
> Sent: Wednesday, December 15, 2004 10:27 PM
> Subject: Fwd: [axis2] Proposal for Client API
>
> (Forwarding with the proper subject filter.)
>
> ----- Original Message -----
> From: Jaliya Ekanayake
> To: axis-dev@ws.apache.org
> Cc: deepal@opensource.lk
> Sent: Wednesday, December 15, 2004 7:07 PM
> Subject: [Axis 2] Proposal for Client API
>
> Hi All,
>
> It is time to discuss about the Client API for Axis2. Deepal and I have come up with a proposal for it. Please have a look at the wiki
> http://wiki.apache.org/ws/FrontPage/Architecture/Client
>
> Please comment. It is better if we can discuss this a bit in the tomorrow's chat.
> We need a good name for the "ProviderX" as well ☺
>
> Jaliya N. Ekanayake
> Lanka Software Foundation
> (www.opensource.lk)
>
>
RE: [axis2] Proposal for Client API
Posted by Chathura Herath <ch...@opensource.lk>.
Hi,
IMO we haven’t talked about specifically how the client side wsdd parsing is going to happen and how those info be eventually be set to the message context. Well we promoted concept of symmetry in server side and client side. So if that is the case it shouldn’t be the registry that keeps the wsdd info, because if I remember right server side out path is initiated by the sender.
Correct me if I'm wrong Think it’s the call who should create the Messagecontext. So this wsdd info or a pointer to that should eventually end up in the Call at the time of the Creation of Message Context.
Regards
Chathura
________________________________________
From: Jaliya Ekanayake [mailto:jaliya@opensource.lk]
Sent: Thursday, December 16, 2004 4:36 PM
To: axis-dev@ws.apache.org
Subject: RE: [axis2] Proposal for Client API
Hi Chathura,
The requirement is to let the client side handlers to decide the certain factors. If the WSDL says the operation is IN-OUT, the client can invoke it either synchronously or asynchronously. So we need a mechanism to store these properties. It may be possible to take them from the WSDD as well. Then we need to decide where we can keep the WSDD information in the client side. Is it the engine registry?
Please comment
Jaliya
________________________________________
From: Chathura Herath [mailto:chathura@opensource.lk]
Sent: Thursday, December 16, 2004 3:59 PM
To: axis-dev@ws.apache.org
Subject: RE: [axis2] Proposal for Client API
Hi Jaliya, Deepal, all,
Here is my idea.
We should not introduce a new property for the MC, instead the MEP can be taken out from the Service Desc and it is already there. So not only the MEP’s you mentioned, but the concept of MEP in WSDL 2.0 can be brought in keeping open the opportunity for MEP extensions.
Further I believe the deployment will know weather an operation is sync or async at the deployment time. So think that should go in as a new method to the AxisOperation in the service Desc.
Thoughts
Cheers
Chathura
________________________________________
From: Jaliya Ekanayake [mailto:jaliya@opensource.lk]
Sent: Thursday, December 16, 2004 2:53 PM
To: axis-dev@ws.apache.org
Subject: RE: [axis2] Proposal for Client API
Deepal,
Why we need different way to invoke it. According to the today’s chat it will be a Receiver. May be the name will be ClientReceiver or something.
Client receiver should have the logic to handle the sync or async cases and it may get them by looking at the message context.
So the provider will be called by the receiver. (This is also not a must).
I think it is better if we add an integer field named message type. This can have the values of
IN_ONLY
IN_OUT_SYNC
IN_OUT_ASYNC
So we can use them in appropriate locations, sync and async is not that informative.
So the message context will have the following methods.
void setMessageType(int messageType);
int getMessageType();
Thanks,
Jaliya N. Ekanayake
Lanka Software Foundation
(www.opensource.lk)
________________________________________
From: Deepal Jayasinghe [mailto:deepal@opensource.lk]
Sent: Thursday, December 16, 2004 2:27 PM
To: axis-dev@ws.apache.org
Subject: Re: [axis2] Proposal for Client API
hi all;
if you go to the sequence diagram shown in the following link
http://wiki.apache.org/ws/FrontPage/Architecture/Client
ProviderX should behave different way in invokeInOut() and invokeAsync().
in order to do that ProviderX should be know a condition , so I think if we can keep a property
in msgContxt to handle that it make the implementation easier. so my suggestion is to have
two methods in msgContxt
void MC.setAsyncMsg(boolean value);
boolean MC.isAsyncMsg(): ;
thoughts ?
Deepal
----- Original Message -----
From: Sanjiva Weerawarana
To: axis-dev@ws.apache.org
Sent: Wednesday, December 15, 2004 10:27 PM
Subject: Fwd: [axis2] Proposal for Client API
(Forwarding with the proper subject filter.)
----- Original Message -----
From: Jaliya Ekanayake
To: axis-dev@ws.apache.org
Cc: deepal@opensource.lk
Sent: Wednesday, December 15, 2004 7:07 PM
Subject: [Axis 2] Proposal for Client API
Hi All,
It is time to discuss about the Client API for Axis2. Deepal and I have come up with a proposal for it. Please have a look at the wiki
http://wiki.apache.org/ws/FrontPage/Architecture/Client
Please comment. It is better if we can discuss this a bit in the tomorrow’s chat.
We need a good name for the “ProviderX” as well ☺
Jaliya N. Ekanayake
Lanka Software Foundation
(www.opensource.lk)
RE: [axis2] Proposal for Client API
Posted by Jaliya Ekanayake <ja...@opensource.lk>.
Hi Chathura,
The requirement is to let the client side handlers to decide the certain
factors. If the WSDL says the operation is IN-OUT, the client can invoke it
either synchronously or asynchronously. So we need a mechanism to store
these properties. It may be possible to take them from the WSDD as well.
Then we need to decide where we can keep the WSDD information in the client
side. Is it the engine registry?
Please comment
Jaliya
_____
From: Chathura Herath [mailto:chathura@opensource.lk]
Sent: Thursday, December 16, 2004 3:59 PM
To: axis-dev@ws.apache.org
Subject: RE: [axis2] Proposal for Client API
Hi Jaliya, Deepal, all,
Here is my idea.
We should not introduce a new property for the MC, instead the MEP can be
taken out from the Service Desc and it is already there. So not only the
MEP's you mentioned, but the concept of MEP in WSDL 2.0 can be brought in
keeping open the opportunity for MEP extensions.
Further I believe the deployment will know weather an operation is sync or
async at the deployment time. So think that should go in as a new method to
the AxisOperation in the service Desc.
Thoughts
Cheers
Chathura
_____
From: Jaliya Ekanayake [mailto:jaliya@opensource.lk]
Sent: Thursday, December 16, 2004 2:53 PM
To: axis-dev@ws.apache.org
Subject: RE: [axis2] Proposal for Client API
Deepal,
Why we need different way to invoke it. According to the today's chat it
will be a Receiver. May be the name will be ClientReceiver or something.
Client receiver should have the logic to handle the sync or async cases and
it may get them by looking at the message context.
So the provider will be called by the receiver. (This is also not a must).
I think it is better if we add an integer field named message type. This
can have the values of
IN_ONLY
IN_OUT_SYNC
IN_OUT_ASYNC
So we can use them in appropriate locations, sync and async is not that
informative.
So the message context will have the following methods.
void setMessageType(int messageType);
int getMessageType();
Thanks,
Jaliya N. Ekanayake
Lanka Software Foundation
( <http://www.opensource.lk> www.opensource.lk)
_____
From: Deepal Jayasinghe [mailto:deepal@opensource.lk]
Sent: Thursday, December 16, 2004 2:27 PM
To: axis-dev@ws.apache.org
Subject: Re: [axis2] Proposal for Client API
hi all;
if you go to the sequence diagram shown in the following link
http://wiki.apache.org/ws/FrontPage/Architecture/Client
ProviderX should behave different way in invokeInOut() and invokeAsync().
in order to do that ProviderX should be know a condition , so I think if we
can keep a property
in msgContxt to handle that it make the implementation easier. so my
suggestion is to have
two methods in msgContxt
void MC.setAsyncMsg(boolean value);
boolean MC.isAsyncMsg(): ;
thoughts ?
Deepal
----- Original Message -----
From: Sanjiva <ma...@opensource.lk> Weerawarana
To: axis-dev@ws.apache.org
Sent: Wednesday, December 15, 2004 10:27 PM
Subject: Fwd: [axis2] Proposal for Client API
(Forwarding with the proper subject filter.)
----- Original Message -----
From: Jaliya <ma...@opensource.lk> Ekanayake
To: axis-dev@ws.apache.org
Cc: deepal@opensource.lk
Sent: Wednesday, December 15, 2004 7:07 PM
Subject: [Axis 2] Proposal for Client API
Hi All,
It is time to discuss about the Client API for Axis2. Deepal and I have come
up with a proposal for it. Please have a look at the wiki
http://wiki.apache.org/ws/FrontPage/Architecture/Client
Please comment. It is better if we can discuss this a bit in the tomorrow's
chat.
We need a good name for the "ProviderX" as well :-)
Jaliya N. Ekanayake
Lanka Software Foundation
( <http://www.opensource.lk> www.opensource.lk)
RE: [axis2] Proposal for Client API
Posted by Chathura Herath <ch...@opensource.lk>.
Hi Jaliya, Deepal, all,
Here is my idea.
We should not introduce a new property for the MC, instead the MEP can be
taken out from the Service Desc and it is already there. So not only the
MEP's you mentioned, but the concept of MEP in WSDL 2.0 can be brought in
keeping open the opportunity for MEP extensions.
Further I believe the deployment will know weather an operation is sync or
async at the deployment time. So think that should go in as a new method to
the AxisOperation in the service Desc.
Thoughts
Cheers
Chathura
_____
From: Jaliya Ekanayake [mailto:jaliya@opensource.lk]
Sent: Thursday, December 16, 2004 2:53 PM
To: axis-dev@ws.apache.org
Subject: RE: [axis2] Proposal for Client API
Deepal,
Why we need different way to invoke it. According to the today's chat it
will be a Receiver. May be the name will be ClientReceiver or something.
Client receiver should have the logic to handle the sync or async cases and
it may get them by looking at the message context.
So the provider will be called by the receiver. (This is also not a must).
I think it is better if we add an integer field named message type. This
can have the values of
IN_ONLY
IN_OUT_SYNC
IN_OUT_ASYNC
So we can use them in appropriate locations, sync and async is not that
informative.
So the message context will have the following methods.
void setMessageType(int messageType);
int getMessageType();
Thanks,
Jaliya N. Ekanayake
Lanka Software Foundation
( <http://www.opensource.lk> www.opensource.lk)
_____
From: Deepal Jayasinghe [mailto:deepal@opensource.lk]
Sent: Thursday, December 16, 2004 2:27 PM
To: axis-dev@ws.apache.org
Subject: Re: [axis2] Proposal for Client API
hi all;
if you go to the sequence diagram shown in the following link
http://wiki.apache.org/ws/FrontPage/Architecture/Client
ProviderX should behave different way in invokeInOut() and invokeAsync().
in order to do that ProviderX should be know a condition , so I think if we
can keep a property
in msgContxt to handle that it make the implementation easier. so my
suggestion is to have
two methods in msgContxt
void MC.setAsyncMsg(boolean value);
boolean MC.isAsyncMsg(): ;
thoughts ?
Deepal
----- Original Message -----
From: Sanjiva <ma...@opensource.lk> Weerawarana
To: axis-dev@ws.apache.org
Sent: Wednesday, December 15, 2004 10:27 PM
Subject: Fwd: [axis2] Proposal for Client API
(Forwarding with the proper subject filter.)
----- Original Message -----
From: Jaliya <ma...@opensource.lk> Ekanayake
To: axis-dev@ws.apache.org
Cc: deepal@opensource.lk
Sent: Wednesday, December 15, 2004 7:07 PM
Subject: [Axis 2] Proposal for Client API
Hi All,
It is time to discuss about the Client API for Axis2. Deepal and I have come
up with a proposal for it. Please have a look at the wiki
http://wiki.apache.org/ws/FrontPage/Architecture/Client
Please comment. It is better if we can discuss this a bit in the tomorrow's
chat.
We need a good name for the "ProviderX" as well :-)
Jaliya N. Ekanayake
Lanka Software Foundation
( <http://www.opensource.lk> www.opensource.lk)
RE: [axis2] Proposal for Client API
Posted by Jaliya Ekanayake <ja...@opensource.lk>.
Deepal,
Why we need different way to invoke it. According to the today's chat it
will be a Receiver. May be the name will be ClientReceiver or something.
Client receiver should have the logic to handle the sync or async cases and
it may get them by looking at the message context.
So the provider will be called by the receiver. (This is also not a must).
I think it is better if we add an integer field named message type. This
can have the values of
IN_ONLY
IN_OUT_SYNC
IN_OUT_ASYNC
So we can use them in appropriate locations, sync and async is not that
informative.
So the message context will have the following methods.
void setMessageType(int messageType);
int getMessageType();
Thanks,
Jaliya N. Ekanayake
Lanka Software Foundation
( <http://www.opensource.lk> www.opensource.lk)
_____
From: Deepal Jayasinghe [mailto:deepal@opensource.lk]
Sent: Thursday, December 16, 2004 2:27 PM
To: axis-dev@ws.apache.org
Subject: Re: [axis2] Proposal for Client API
hi all;
if you go to the sequence diagram shown in the following link
http://wiki.apache.org/ws/FrontPage/Architecture/Client
ProviderX should behave different way in invokeInOut() and invokeAsync().
in order to do that ProviderX should be know a condition , so I think if we
can keep a property
in msgContxt to handle that it make the implementation easier. so my
suggestion is to have
two methods in msgContxt
void MC.setAsyncMsg(boolean value);
boolean MC.isAsyncMsg(): ;
thoughts ?
Deepal
----- Original Message -----
From: Sanjiva <ma...@opensource.lk> Weerawarana
To: axis-dev@ws.apache.org
Sent: Wednesday, December 15, 2004 10:27 PM
Subject: Fwd: [axis2] Proposal for Client API
(Forwarding with the proper subject filter.)
----- Original Message -----
From: Jaliya <ma...@opensource.lk> Ekanayake
To: axis-dev@ws.apache.org
Cc: deepal@opensource.lk
Sent: Wednesday, December 15, 2004 7:07 PM
Subject: [Axis 2] Proposal for Client API
Hi All,
It is time to discuss about the Client API for Axis2. Deepal and I have come
up with a proposal for it. Please have a look at the wiki
http://wiki.apache.org/ws/FrontPage/Architecture/Client
Please comment. It is better if we can discuss this a bit in the tomorrow's
chat.
We need a good name for the "ProviderX" as well :-)
Jaliya N. Ekanayake
Lanka Software Foundation
( <http://www.opensource.lk> www.opensource.lk)
Re: [axis2] Proposal for Client API
Posted by Deepal Jayasinghe <de...@opensource.lk>.
hi all;
if you go to the sequence diagram shown in the following link
http://wiki.apache.org/ws/FrontPage/Architecture/Client
ProviderX should behave different way in invokeInOut() and invokeAsync().
in order to do that ProviderX should be know a condition , so I think if we can keep a property
in msgContxt to handle that it make the implementation easier. so my suggestion is to have
two methods in msgContxt
void MC.setAsyncMsg(boolean value);
boolean MC.isAsyncMsg(): ;
thoughts ?
Deepal
----- Original Message -----
From: Sanjiva Weerawarana
To: axis-dev@ws.apache.org
Sent: Wednesday, December 15, 2004 10:27 PM
Subject: Fwd: [axis2] Proposal for Client API
(Forwarding with the proper subject filter.)
----- Original Message -----
From: Jaliya Ekanayake
To: axis-dev@ws.apache.org
Cc: deepal@opensource.lk
Sent: Wednesday, December 15, 2004 7:07 PM
Subject: [Axis 2] Proposal for Client API
Hi All,
It is time to discuss about the Client API for Axis2. Deepal and I have come up with a proposal for it. Please have a look at the wiki
http://wiki.apache.org/ws/FrontPage/Architecture/Client
Please comment. It is better if we can discuss this a bit in the tomorrow's chat.
We need a good name for the "ProviderX" as well J
Jaliya N. Ekanayake
Lanka Software Foundation
(www.opensource.lk)