gsoap and SSL/TLS vs .Net Web Services - web-services

Does gSOAP provides SSL/TLS, VPN, encryption, digital signing of data? What to prefer for web service security, gsoap or .Net for previous mentioned properties.

Yes, gSOAP supports ssl/https by using openssl, the info can be found from http://www.cs.fsu.edu/~engelen/soapdoc2.html#tth_sEc19.21.
About which to choose, gSOAP or .NET, i think that should depend on the project and be different case by case. For these two, at least gSOAP is corss-platform while .NET is only on Windows.

Related

What framwework to use for SOAP if using Websphere Application Server

I have been going over the list of frameworks available for SOAP. My application is Spring MVC pattern and its deployed on Websphere servers. Do I still need to use framworks like Axis 2 or CXF? Can I just Use spring?
As Gas pointed out WebSphere provides support for JAX-WS (i.e. Java API for XML Web Services) since WAS 7.0. Additionally IBM provided Feature Pack for Web Services for WebSphere Application Server V6.1 that supported JAX-WS.
Even earlier versions of WAS supported JAX-RPC (since J2EE 1.4) but I do not recommend JAX-RPC approach because it was cumbersome and I don't think anyone is still using it. It is in fact deprecated since JEE 6.
So you do not need to use external libraries. Using standard JAX-WS implementation from WebSphere gives you possibility to easily configure services from administration console. This is especially nice when you integrate with other IBM WebSphere products or use some IBM standards like LTPA tokens. However, this implementation does not integrate with Spring.
You also might use external libraries, like Axis 2, Apache CXF or Metro. These also have some advantages. For instance Apache CXF integrates really nice with Spring and supports many standards. Spring WS is on the other hand minimalistic.
However, with these libraries you must expect some problems with class conflicts as they require often different versions of libraries than WebSphere provides. This might require you to change default classloading policy or other tweaks. It is possible to deal with but it is not for free.

Random questions on JAX-WS and JAX-RPC compatibilities

We have a web service running on an old version of an application server. It this old application server is running on JAVA EE 1.4. Its clients are on another server also running on the same version of the application server.
The move to upgrade our application server has started. The new version now will run on Java EE 6. The thing is, the clients would still run on the old version. Would it still be able to access the web service that will now be running on Java EE 6?
If yes is the answer to #2, I have a follow up question below
Our web service will now be created using JAX-WS. Does that mean that we should generate client classes as JAX-RPC? for the clients running in the old version to be able to access it? if yes, how?
To rephrase the question, if you have a JAX-WS web service, how do you generate a JAX-WS client and how to generate a JAX-RPC client? ive done some initial research and they seem to be done the same way, which I'm not sure is correct. Im confused.
thanks
Since you mentioned J2EE 1.4, I am guessing that the web service is based upon JAX-RPC 1.x standard. As the Java EE 6 based web service is based on JAX-WS, I would suggest generating client stubs using wsimport command by using the WSDL from your new service to generate stub classes.
In case you want to dig deeper and you should always refer to the JAX-WS specification document here (read up on chapter 4 - Client APIs)
The service consumer (client) and service provider technologies are independent. You can (for the most part) have a JavaEE6/JAX-WS web service provider but still consume with a JAX-RPC client, technically (for that matter, clients might not even be implemented in Java!). The only technical barriers to this would be perhaps if your service provider used SOAP 1.2 constructs that JAX-RPC could not handle, but I suspect that not to be the case if you are strictly migrating/upgrading the provider application.
Several application servers still support JAX-RPC even though it is now (JavaEE 5 & 6) optional for compliant app servers to implement.
I would personally however recommend updating the clients to JAX-WS as you upgrade those applications/appservers. I would think they should work with the upgraded web service provider without change - so long as the service provider WSDL doesn't change when that application is upgraded (though you may have to regenerate them if there are subtle differences in the regenerated WSDLs - the marshal/unmarshal technology in JAX-RPC is notoriously brittle).
-SH

why should i use axis 2 for jax-ws 2 compliant web service development

based on this link http://axis.apache.org/axis2/java/core/docs/jaxws-guide.html
I assume that axis 2 provides FULL support for JAX-WS 2 compliant web service development.
My question is why should i use Axis-2 as web services runtime instead of using my app server's (like websphere's) inbuilt support for JAX-WS web services development.
Are there any special reasons for using AXIS 2 like runtimes. My assumption is they are provided as embeddable web services runtime implementations that can be used with tomcat / resin etc. which do not provide out of box web services support. And that they are not required to be used with app servers like websphere or weblogic which already provide support for full jax-ws 2 compliant web service development out of the box.
please confirm.
I'd definitely recommend using what WebSphere or any other server provides out-of-the-box whenever possible. You'll know it's tested and supported.
Somebody who really knows Axis2 may have reasons to prefer the 3rd-party version of it (WebSphere's JAX-WS support is actually based on Axis2), but I can't speak to that.

Compatibility of Axis2 with older wsdl files / Web Services

If I understand correctly, all frameworks use SOAP while communicating with Web Services. I am still in dilemma whether a particular server supports all frameworks.
Let's say, XYZ has released its WSDL file longback (in Axis era), and they have not upgraded anything. Now, can I use Axis2 to build the stubs from the same WSDL, and communicate successfully with the same old server?
There are different versions of WSDL and SOAP, AXIS2 would normally use SOAP 1.2 This is a reference to how to use SOAP 1.1 with Axis2.

WSDL / Web Service and need to generate interfaces

I have an WSDL / Web Service and I need to generate an set of Interfaces for them, is there any easy way of generating Interfaces for the WSDL?
As you're a C# developer I'm assuming you mean C# interfaces for the client? You can do this using svcutil for WCF or WSDL.exe for legacy Web services.
Yes. Download SoapUI for free. SoapUI can generate code, interfaces, or stubs for a variety of platforms, including .NET and numerous Java formats.
Apache CXF has tools that will generate interfaces for several languages