[Axis2] Client side problem

[Deepal Jayasinghe <de...@opensource.lk>]

Hi all;

 

I started client side deployment (Client side configuration) and there I found number of things to be clarifies and I have listed them below;

  a.. In client side I think we need to create handler chains for each out going message. There we have to consider what are the module that the client is going to use (WS-RM, WS-S etc) so depending on that handler chain has to be created for that particular request.  So who is going to do that? Is it inside the call? 
  b.. And where is the client going to keep his resources and how can he specify that , I tried to use AXIS2_HOME classpath variable and there I found , to get its value I have to use native API so I think there should bed some other way that user can specify repository location to the Deployment.
 

 

Thanks and regards

Deepal

 

[Axis2] peers vs client/server: messages vs RPC Re: [Axis2] Client side problem

[Aleksander Slominski <as...@cs.indiana.edu>]

Deepal Jayasinghe wrote:

> I started client side deployment (Client side configuration) and there 
> I found number of things to be clarifies and I have listed them below;
>
>     * In client side I think we need to create handler chains for each
>       out going message. There we have to consider what are the module
>       that the client is going to use (WS-RM, WS-S etc) so depending
>       on that handler chain has to be created for that particular
>       request.  So who is going to do that? Is it inside the call?
>     * And where is the client going to keep his resources and how can
>       he specify that , I tried to use AXIS2_HOME classpath variable
>       and there I found , to get its value I have to use native API so
>       I think there should bed some other way that user can specify
>       repository location to the Deployment.
>
as AXIS2 supports WS-Addressing in its core i think that distinction 
between client and server is no longer.

instead i would think about peers - one is an initiator of the message 
exchange (conversation, session ...) and that could be called "client" 
for convenience.

of course we may have peers that have limited network access 
capabilities in particular that can not create listening socket 
(applets) or that they are not accessible (behind NAT or firewall).

fortunately with WS-Addressing it is possible to have a very elegant 
solution to this problem by having third party to provide network 
accessible endpoint. this endpoint address (EPR) is used by the limited 
peer as its own. the third party collects messages and client calls it 
to collect messages (only outgoing connections so no problem with 
NAT/Firewall).

we have implemented such third party as its activities are similiar to 
P.O. mailbox so we called it WS-MsgBox find more details in:
http://www.extreme.indiana.edu/xgws/msgbox/
and in paper describing it and more general intermediary/dispatcher that 
makes services available and can enforce policies so no longer SOAP is 
used to "workaround" firewalls:
http://www.extreme.indiana.edu/labpubs.html#aslom:wsDispatcher:ipdps2005

in my opinion AXIS2 should provide similar capabilities and i can help 
to make it work with WS-MsgBox.

thanks,

alek

-- 
The best way to predict the future is to invent it - Alan Kay