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.
Related
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.
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
i am new to camel?
i am not able to distinguish between camel web-service component
so please help me to find out difference between those component
and also suggest that in which situation which component is better to use.
Thanks in advance.
Camel SOAP is not a component but a data format http://camel.apache.org/soap.html it's used for marshaling and unmarshaling SOAP payloads.
Spring-WS http://camel.apache.org/spring-web-services.html uses Spring Web Services to provide client and server side SOAP support.
Camel-CXF http://camel.apache.org/cxf.html uses Apache CXF to provide client and server side SOAP support.
Camel-CXF is my goto tool when I have to deal with SOAP. It's a mature and very full featured component (and underlying library). The only time I use Spring-WS is if I'm dealing with very outdated SOAP that is using RPC encoding which CXF doesn't support.
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.
We have finally upgraded our web services from .Net 1.1 to .Net 2.0/3.5. One of the clients that calls these web services is run as a windows service. It is probable that the windows service will not be upgraded until some time after upgrading the server at customer sites.
Is it possible to massage my .Net 2.0 web services so they will correctly service the calls from the .Net 1.1 client? In my test environment, I connect to the .Net 2.0 web service from a .Net 1.1 client and I receive a 401.1 error from IIS. The web service is set to anonymous access. The same credentials work when connecting to the .Net 2.0 web service from a .Net 2.0 client.
Thanks for your help,
-colin-
Web services are meant to be platform-neutral. If your web service was written properly, then any client, on any platform supporting SOAP 1.1, should be able to consume it.
One place where this can fall down is if your service is returning or receiving types specific to .NET. If you send or receive a DataSet, for instance, then there can be problems - DataSet is specific not only to .NET, but also to specific versions of .NET. There were many changes made in the area of XML and XML Serialization between .NET 1.1 and .NET 2.0, and you could eventually see one of those problems.
But I don't think any of those should get you a 401 error. Look into the event log and see if anything interesting was written about that error.
It depends on the service. If the .NET 2.0 service:
Is configured to support SOAP 1.1
Does not use WSE 3.0 (WSE 2.0 is OK)
Does not use any nullable types (not supported in .NET 1.1)
Accepts and returns only primitives or POCO classes (no DataSets, etc.)
Then it's compatible.
If you're getting a 401.1 error, but have no problem connecting with other clients from the same machine, then my guess is that the service is expecting something in the SOAP headers. What it's expecting, I can't tell you offhand; I'd have to see the service code/configuration.
Alternatively, it might just be a configuration issue on the web server. Without more details about the specific environments that can/cannot connect, it's hard to say.
As #Aaronaught wrote, The error can be that the service is expecting something in the SOAP headers. To analyse this, you could verify the wsdl generated (expand all files of web reference) or download the metadata via svcutil.exe. This will generate a proxy, that is used to call the web-service.
That way, you have more control over the proxy.
Example on how to use svcutil:
From command prompt:
svcutil
http://service/metadataEndpoint
Thank you for your responses. They were helpful in further diagnosing why it wasn't working. It turns out that everything does work and that the 401.1 response was misleading (but correct). Our problem was due to a change in the web services directory structure. Had I been paying better attention, I might have caught it before asking this question.
To answer my question: Yes. A .Net 1.1 client can call a .Net 2.0 web service and, in general, no additional configuration is necessary. Just make sure you're URI is correct.