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
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.
I need to develop a server side component to accomplish some internal task for my company.
We have a Java EE scheduler application deployed on WebSphere 6.x that will be my client application.
I'd like to write my server side component with EJB 3.1 or with another Java EE 6 compliant technology.
Can I generate a legacy EJB 2.1 client for my component with maven?
Is it better to use another solution like web services and let the scheduler generate his own client?
Other ideas?
I'd suggest using Web Services. EJB will involved RMI/IIOP and serialization. Since you will have 2 different servers, JDK versions you may have much more troubles using EJB integration. If communication is asynchronous, you could also consider JMS.
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.
I have an assignment that requires exposing a web service to 3rd party vendor based web application. I have the choice of server platform (between the 2 mentioned below) on which to deploy the web service. Should I deploy on tomcat 6 vs websphere 6.1.
I want to developed JAX-WS compliance web services in this case (with all the annotation support etc.)
My main concern - which of these two server platforms will scale my web service better - for example today the load might only be 300 transactions a second but it could increase 3-4 times in very near future..
This is probably something you will have to figure out for yourself by doing some load testing against both servers (if you already have them installed). Performance issues will always be dependant on how you have coded your web service and what resources are utilised (e.g. database, jms, etc).
A well tuned Tomcat server will perform just as well as a well tuned Websphere server because it's just a JVM under the hood. Keep in mind that Websphere provides a full J2EE stack, it will provide you with access to J2EE functionality that Tomcat does not provide (e.g. EJB) which is only a servlet container.
As long as you write your web service in a portable manner, you will be able to migrate between Tomcat or Websphere or ServerX in the future if that is what is required. Portability can be achieved by using a framework like Spring, with remote services so that you're not tied in to using a particular vendor's stack.
If you already have investment in Websphere servers I would continue to use them. If you are starting from scratch, why not begin with Tomcat (it's free!). Should you run into perfomance issues you'll have to look into using a load balanced solution and both servers can support this configuration.
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.