How to deploy a Java EE project that has web services - web-services

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.

Related

How can i expose a web service in Grails made with Java?

I need to expose a web service in my Grails application but made in Java, the reason to this is that any of the Grails plugins for web services, does what we need, but after looking at Spring services, I know is possible, after all Grails is made upon Spring
Note that I'm speaking of a Service as a Web Service, not a Servlet, a SOAP to be exact. If I don't find a way to do this in Java, my superiors are pointing to .NET and I really going to hate doing that going to .NET from Java is just wrong.
=== Software currently used ===
-> Grails Version 2.4.3
-> WebService type must be SOAP I have no other choice since my superior does not like REST
-> Spring 4
-> IDE is Intellij

How can I deploy a .EAR file package on wso2as-5.2.1 application server?

I have installed wso2 application server on my lab server, the version used is wso2as-5.2.1.
I am experiencing that I can't deploy a .ear, but only a .war file. Could someone help me about?
WSO2 Application Server is not a fully Java EE compliant Application Container and as of now it supports majority of the Java EE Web Profile specifications. Please refer to http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Web_profile and https://docs.wso2.com/display/AS521/Java+EE+Support for more information. WSO2 App Server is not meant to become another Java EE compliant Server. Hence you cannot deploy Java Enterprise applications (EAR) files in WSO2 App Server. WSO2 Application Server has Web App deployment capability. Hence if you can implement your Java EE application as a Web Application (WAR) file and embed all the required Java EE framework Jar files in to the same Web Application, you will be able to run your Java EE application in the WSO2 App Server. More information on migrating from Java EE world to WSO2 is mentioned in http://wso2.com/whitepapers/evaluating-java-ee-application-migration-and-java-ee-service-migration-to-wso2-application-server/. Currently there is no other out of the box solution for this.

Call EJB 3.1 from EJB 2 client

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.

When to use javax.ws.rs.core.Application to create RESTful web services?

I have developed RESTful web services in two ways:
used a class that extends javax.ws.rs.core.Application without defining a web.xml file, using Glassfish.
haven't used javax.ws.rs.core.Application but included a web.xml and a Jersey implementation, using Tomcat.
Is there a preferred way of building RESTful web services with JAX-RS?
Using the javax.ws.rs.core.Application class is the preferred way and also the only portable way of configuring resources and providers in a JAX-RS web service,
so if possible that would be the recommended way to set it up.
But that works well only in JAX-RS aware servlet containers or application servers, for JAX-RS non aware servers you need other ways for deployment and that most of the times means some proprietary servlet class of the JAX-RS implementation you are using.
To get more details on the subject, see for example the Jersey documentation, Deploying a RESTful Web Service (for Jersey v1.x) and Application Deployment and Runtime Environments (for Jersey v2.x).

Java EE and Grails: Communication with WebServices? Which framework?

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.