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.
Related
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
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 would like my Qt app to expose a service to another app written in .Net using WCF.
Is there any support in Qt for implementing WCF services?
AFAIK there is no 'native' Qt support for WCF or extensions; however as you know WCF can consume and expose a web service (in addition to a WCF or remoting service, etc.) All you need to do is expose it as a Web Service for the other .NET app to consume.
But that brings up an interesting aspect; usually you would write a windows service (I presume you are on Windows) which is exposed as a Web service rather than one via Qt. Qt is not ideal as it is a GUI framework (and a very good one); you will get into a few interesting situations as discussed here. It is usually easier to consume a web service with Qt as shown in this example.
Do you have the option to expose your service using some other stack such as ASP.NET or WCF or Java?
I already have an enterprise Java EE application. I want expose some of the existing EJBs as web services.
I wanted to know how to organize the Java EE project. I mean where does the web services sit in the Java EE EAR file hierarchy and how to invoke the deployed webs services?
It depends upon exactly how you implement your WebService and also on which Java EE version you are using. Simplest, with JAX-WS your webservice implementation and interface are all packed in the WAR. See the sun tutorial. Possibly you may implement your service as an EJB and in which case you can simply use the #WebService annotation. In which case you're delivering the EJB jar.
Recommend you work through a few tutorials for the specific App Server you are using.
Hy, I'm developing a Grails app which has to communicate with an existing Java EE application (built with EJB2).
Both the "legacy" app and the new Grails app will offer services and consume them.
For intercompatibility reasons, I'm thinking of communicating using WebServices. Now I'm wondering which frameworks I should use on both sides.
Since the Java EE application now runs under JDK5, I could use JAX-WS on I guess it would make sense to use Metro (https://jax-ws-commons.dev.java.net/grails/) on the Grails side. Does anybody have experiences with that? Or other suggestions?
If both the Grails and EJB applications live on the same LAN then there is nothing wrong with using RMI. Its the default way of talking to EJB's, is native to Java and is supported in Grails.
If you need to use Web Services then your container will have built in support for exposing the EJB's as Web Services (assuming J2EE 1.4 or later). Which container are you using?
If you cant use (or don't trust) the containers WS support then its best to pick a framework that you can use in both applications, thereby avoiding compatibility issues. Metro has worked well for me standalone but I haven't tried it with Grails.
Also there are more lightweight ways of exchanging XML messages than full SOAP'y Web Services. Hessian and Burlap are examples, plus Spring has its own HTTP messaging framework.