You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Samisa Abeysinghe <sa...@wso2.com> on 2007/05/21 06:42:31 UTC

Service vs. Operation client APIs [was Re: [Axis2] SOAP header elements]

OK, I really do not want to criticize the client API here, specially 
given that it has been around for more than two years.

However, I have a problem when deciding whether to use the service 
client or operation client API for my implementation.
As an example, in operation client, I do not have an API to engage a 
module but with service client I can. However if I want to access the 
SOAP envelope or play around with SOAP level stuff, I have to use 
operation client. Now I am confused as to what I should be using. How 
should I go about making my decision? If you can point me to some docs 
that would be great.

Samisa...

Eran Chinthaka wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Samisa and all,
>
>You have a very good point here, except that you started from the wrong
>class. The complete API for the users to use is the OperationClient API.
>But since most users, yes *most* user's concern is to send and receieve
>XML fragment which is supported in ServiceClient API.
>
>There are lots of things missing in ServiceClient. From the day one
>ServiceClient API was meant to be the simple API for simple work. Most
>of the users do not look at SOAP message. Especially because of J2EE
>containers users even do not look at the XML fragment. That is why we
>gave a convenient API on top of OperationClient.
>
>If you want to look at the SOAP message or if you want to change the
>engine or if you want to change MEP, then we consider that as an
>advanced operation which require him to use OperationClient. One can
>come-up with various use cases which seems simple to them and might
>wonder why it is not included in ServiceClient. The simple answer is
>Axis2 was there for a long time, more than 2 years and ServiceClient
>must have been there at least for 2 years, but we found out that users
>are satisfied with the existing way of only dealing with OMElement in
>and OMElement out.
>
>Again I totally agree with you that users need to face extra bit of
>hassle when they want to add little bit more to what they are using with
>ServiceClient, but that is intentional.
>
>Thanks,
>Chinthaka
>
>Samisa Abeysinghe wrote:
>  
>
>>>>Deepal Jayasinghe wrote:
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>>>>>>Hi Jack ,
>>>>>>If this is in the server side , you can get the message context and
>>>>>>from
>>>>>>that you can get the SOAP envelope and from the soap envelope you can
>>>>>>get the soap headers.
>>>>>>
>>>>>>If it is the in the client side  , the the process is ,
>>>>>> - First you get the last operation context from the service client
>>>>>> - and then follow the above steps.
>>>>>>  
>>>>>>            
>>>>>>
>>>>  
>>>>That looks like too much work for me to get a simple thing done  :(
>>>>Why not have some method like:
>>>>getLastResponseSoapEnvelope()
>>>>to service client API and do all the context access stuff within that
>>>>method ?
>>>>        
>>>>
>>> 
>>>
>>>Idea is cool  I am +1 on doing that , but ...
>>>      
>>>
>>>One of the design goal of service client was to provide a convenient
>>>API  for  simple usage (cater for average users), and the assumption was
>>>that user only trying to send  OM element and trying to get OM element .
>>>If you need to do advanced work like accessing SOAP headers  , then you
>>>can use OperationClient.
>>>      
>>>
>>OK, cool, I forgot about operation client. However, there still remains
>>a minor concern about the usability/maintainability of the stuff. This
>>case is an ideal example - the use writes some code, and gets it working
>>- now wants to do more with the API, and he/she has to switch from one
>>API to the other to get the things done :(
>>
>>Samisa...
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>>    
>>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.3 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFGUQifjON2uBzUhh8RAl3SAJ4uCtbs4pElSKfbr1eOQtvSoExRhgCfb438
>2aPufLx7Sthf8JSgzpf3joQ=
>=6WJN
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Re: Service vs. Operation client APIs [was Re: [Axis2] SOAP header elements]

Posted by Samisa Abeysinghe <sa...@wso2.com>.
Eran Chinthaka wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Samisa Abeysinghe wrote:
>  
>
>>OK, I really do not want to criticize the client API here, specially
>>given that it has been around for more than two years.
>>
>>However, I have a problem when deciding whether to use the service
>>client or operation client API for my implementation.
>>As an example, in operation client, I do not have an API to engage a
>>module but with service client I can. However if I want to access the
>>SOAP envelope or play around with SOAP level stuff, I have to use
>>operation client. 
>>    
>>
>
>See you are not getting the point here. ServiceClient is for users who
>just want to send and receive some XML chunks. In ServiceClient there
>are quite a number of convenient methods to do things, which are not
>available. So are you suggesting to have all the methods that are in
>ServiceClient to be available in OperationClient. No.
>ServiceClient is for simple users and OperationClient is for more
>adventurous users who wanna get some more control.
>  
>
Well the problem here is my non-Java mindset. :(
I am too much dependent on the ServiceClient API, and you guys are too 
much accustomed to this API to understand my mindset ;)
Anyway, thanks to the explanation, I get the point at last :)

>  
>
>>Now I am confused as to what I should be using. How
>>should I go about making my decision? If you can point me to some docs
>>that would be great.
>>    
>>
>
>As you know we are still improving Axis2/java docs and I agree that it
>is not complete. Perhaps we can learn a lot about documentation from
>Axis2/C project ;)
>  
>
Well I do not think Axis2/C is there yet either :)

>If you are curious about engaging a module, this is how you do it.
>
>AxisModule module = axisConfig.getModule(moduleName);
>            if (module != null) {
>                axisService.engageModule(module);
>            } else {
>                throw new AxisFault("Unable to engage module : " +
>moduleName);
>            }
>
>Don't think I am smart to write this code. Just copied and pasted from
>ServiceClient.engageModule method. So in Axis2/Java we follow the
>concept of "on-demand" documentation :D
>  
>
Again, my problem was, I was only looking at the API.
Well, code is the best form of documentation, next time I should also 
have a look into the code  :)

Thanks,
Samisa...

>Chinthaka
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.3 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFGUS5njON2uBzUhh8RAuzmAJ9MQBTKU/99tTKnxRixX67KOMNQiACdG3VR
>b5sEmIRAz8/M+wue/ZxZzcg=
>=ogQj
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Re: Service vs. Operation client APIs [was Re: [Axis2] SOAP header elements]

Posted by Eran Chinthaka <ch...@opensource.lk>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Samisa Abeysinghe wrote:
> OK, I really do not want to criticize the client API here, specially
> given that it has been around for more than two years.
> 
> However, I have a problem when deciding whether to use the service
> client or operation client API for my implementation.
> As an example, in operation client, I do not have an API to engage a
> module but with service client I can. However if I want to access the
> SOAP envelope or play around with SOAP level stuff, I have to use
> operation client. 

See you are not getting the point here. ServiceClient is for users who
just want to send and receive some XML chunks. In ServiceClient there
are quite a number of convenient methods to do things, which are not
available. So are you suggesting to have all the methods that are in
ServiceClient to be available in OperationClient. No.
ServiceClient is for simple users and OperationClient is for more
adventurous users who wanna get some more control.

> Now I am confused as to what I should be using. How
> should I go about making my decision? If you can point me to some docs
> that would be great.

As you know we are still improving Axis2/java docs and I agree that it
is not complete. Perhaps we can learn a lot about documentation from
Axis2/C project ;)
If you are curious about engaging a module, this is how you do it.

AxisModule module = axisConfig.getModule(moduleName);
            if (module != null) {
                axisService.engageModule(module);
            } else {
                throw new AxisFault("Unable to engage module : " +
moduleName);
            }

Don't think I am smart to write this code. Just copied and pasted from
ServiceClient.engageModule method. So in Axis2/Java we follow the
concept of "on-demand" documentation :D

Chinthaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGUS5njON2uBzUhh8RAuzmAJ9MQBTKU/99tTKnxRixX67KOMNQiACdG3VR
b5sEmIRAz8/M+wue/ZxZzcg=
=ogQj
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org