I am new to Java and trying to jump into WebServices. I found two examples somewhere and I am confused with the available options.
Firstly, javax.jws.WebService with annotation seem to work fine, but there is loads of material on javax.xml.ws. It seems javax.jws is newer and there is not much material available about it.
What is the difference between these two approaches?
Web Services Metadata Annotations (JSR 181)
Using annotations from the JSR 181 specification (java.jws.xxx), you can annotate a Web service implementation class or a Web service interface.
e.g. from Deploy JAX-WS Web Services On Tomcat
package com.mkyong.ws;
import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
//Service Endpoint Interface
#WebService
#SOAPBinding(style = Style.RPC)
public interface HelloWorld{
#WebMethod String getHelloWorldAsString();
}
JAX-WS 2.0 Annotations (JSR 224)
The JSR 224 specification defines annotations for JAX-WS 2.0 (javax.xml.ws.xxx).
e.g. from Using SOAP Faults and Exceptions in Java JAX-WS
#WebFault(name="CheckVerifyFault",
targetNamespace="http://www.example.com")
public class CheckVerifyFault extends Exception {
/**
* Java type that goes as soapenv:Fault detail element.
*/
private CheckFaultBean faultInfo;
public CheckVerifyFault(String message, CheckFaultBean faultInfo) {
super(message);
this.faultInfo = faultInfo;
}
public CheckVerifyFault(String message, CheckFaultBean faultInfo,
Throwable cause) {
super(message, cause);
this.faultInfo = faultInfo;
}
public CheckFaultBean getFaultInfo() {
return faultInfo;
}
}
Peer Reynders says:
My guess would be that BEA wanted something NOW to put into Weblogic to compete with the equivalent feature in .NET. (see, developing Web services in WebLogic is just "as easy"). Also the annotations specified in JAX-WS 2.0 (JSR-224) seem to provide you with more control. However JSR-224 does explicitly support/include JSR-181 (JSR-224: 7.10 Annotations Defined by JSR-181).
For a more complete discussion about, see JSR 181: a Java Simplification Request
See also:
Annotations references
JAX-WS annotations reference
JSR 181
JSR 224
These two package namespaces do not define different approaches.
If you're creating services based on the Web, there are two options: SOAP services (AKA Web services) or REST services (AKA RESTful services).
If implementing SOAP services in Java, the way to go is to use the JAX-WS framework. The framework provides tools, such as wsimport and wsgen, and of course an API.
The JAX-WS API includes annotations, classes and interfaces for implementing the code of a SOAP service itself and the code of a service consumer (the client).
Altogether these elements of the JAX-WS API use both javax.xml.ws and javax.jws package namespaces.
Just follow the tutorials or examples to create the services using JAX-WS. Don't worry about which packages do the API elements come from.
But remember to avoid vendor specific API elements. You're more likely to run into these vendor specific elements when using WS-* standards (e.g., WS-Security) beyond WSDL and SOAP.
Related
I have a service that I want to consume in a few projects in basically the same way. I'd like to simplify the process of sending and receiving data to and from these projects, so I would like to make a client jar that handles the process of packing and unpacking jaxrs responses/requests and include that in my other projects.
However, to use any jax-rs objects, I have to be dependent on a specific implementation of jax-rs. In my little client library I have to include jersey (or resteasy or cxf) to have access to any of the jax-rs imports. If I were to include this jar in any of my other projects, they'd be forced to use that rest implementation as well.
Is there a way to create a single project jar that utilizes jax-rs objects, that would use the jax-rs implementation of the consuming container instead of having many nearly identical client projects that just include a different jax-rs implementation?
Essentially, I want my project wars to include a jar that will handle packing and unpacking jax-rs rest objects that use whatever implementation of jax-rs the war project uses.
Classes from the javax.ws.rs.* package are portable and are expected to work across different JAX-RS implementations. Use the following dependency:
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>javax.ws.rs-api</artifactId>
<version>2.1</version>
</dependency>
Classes from the following packages are implementation specific and you don't want to use them directly when you want your code to be portable across different implementations:
Jersey: org.glassfish.jersey.*
RESTEasy: org.jboss.resteasy.*
Apache CXF: org.apache.cxf.jaxrs.*
However such classes must be in the classpath during runtime.
The JAX-RS Client API was introduced in JAX-RS 2.0 and enhanced in JAX-RS 2.1 with reactive capabilities. Check the API documentation for details.
Prior JAX-RS 2.0, any client support was vendor specific and not portable. The proxy-based clients provided by most of the vendors are not portable either.
The JAX-RS Client API can be used as follows:
Client client = ClientBuilder.newClient();
Response response = client.target("http://example.org/hello").request("text/plain").get();
In the above code, a javax.ws.rs.client.Client instance will be created using the default javax.ws.rs.client.ClientBuilder implementation class provided by the JAX-RS implementation provider.
If you are interested, check the documentation for the Client implementations:
Jersey: org.glassfish.jersey.client.JerseyClient
RESTEasy: org.jboss.resteasy.client.jaxrs.ResteasyClient
Apache CXF: org.apache.cxf.jaxrs.client.spec.ClientImpl
My application shall make calls to a REST service. So I added the package cxf-rt-rs-client from org.apache.cxf as a dependency.
In a cxf.xml configuration this is how I define my JAX-RS client:
<jaxrs:client id="myRestClient" serviceClass="org.apache.cxf.jaxrs.client.WebClient">
<http-conf:authorization>
<sec:UserName>testuser</sec:UserName>
<sec:Password>myPassword</sec:Password>
<sec:AuthorizationType>Basic</sec:AuthorizationType>
</http-conf:authorization>
</jaxrs:client>
However I think I have missed a point. How do I actually use this client in ma Java code? There must be some mechanism which makes this myRestClient available in the application?
This is tersely documented in section Injecting proxies of CXF JAX-RS Client API documentation. To be more explicit, the useful Java code for the XML example in this section can be found in the class org.apache.cxf.systest.jaxrs.jaxws.BookStoreSoapRestImpl of CXF samples.
So, in your case, I guess something like this:
#Resource(name = "myRestClient")
private org.apache.cxf.jaxrs.client.WebClient webClient;
I read Beginning Java EE 6 platform with GlassFish 3 from Antonio Goncalves.
In chapter about EJBs he wrote that some features of EJB may be deprecated in next releases of Java EE.
None of the following features is actually removed from EJB 3.1, but
the next version will have to either remove or retain some of them:
JAX-RPC-based web service endpoints
But I not understand what he mean here. He wrote about classes annotated with #Stateless and #WebService? i.e.
#Stateless
#WebService
public class MyService {
}
So it is bad practice to annotate one class with this both annotations? It is better to separate classes? Create one to act only as EJB, and create another class to act only as as WebService (which delegates method invocation to EJB defined as class-member)?
Both #Stateless and #WebService are not part of JAX-RPC. They belong to EJB3 and JAX-WS. They will not be deprecated.
JAX-RPC 2.0 was renamed JAX-WS 2.0 in 2005.
When I create a new Web service using RSA 7.5 IDE and Web Sphere 7.0 server from a Web Application, then I can see a few auto-generated files created by this process, namely:
1) For the service, a SEI file is created
2) For the models, ser, deser and helper files are created.
But I cant understand what are the use of all these SEI, ser, deser and helper files.
Any valid explanation on this will be much appreciated.
BOUNTY EDIT:
Bounty-Edit:
Since I did not get any response I would like to ask this question again - offering a bounty to encourage an in-depth answer. I would love to know how and when are these files used internally?
Regards,
Service Endpoint Interface (SEI):
SEI is the Java interface corresponding to the Web service port type
being implemented. It is defined by the JAX-RPC, which specifies the
language mapping from WSDL 1.1 to Java. Ref
Or
A service endpoint interface (SEI) is a Java interface that
declares the methods that a client can invoke on the service. Ref
These ser,dser,helper are helpers to convert an XML document into a java object and vice versa (WebServices). Ref
Files generated in the server project: (WebSphere Application Server 6.1 Ref)
According to the settings made during the run of the wizard, the following files in the WeatherJavaBeanWeb project have been created:
Service endpoint interface (SEI): itso.bean.WeatherJavaBean_SEI.java is the interface defining the methods exposed in the Web service.
WSDL file: /WebContent/WEB-INF/wsdl/WeatherJavaBean.wsdl describes the Web service.
Deployment descriptor: webservices.xml, ibm-webservices-ext.xml and ibm-webservices-bnd.xml. These files describe the Web service according to the Web services for J2EE style (JSR 109). The JAX-RPC mapping is described in the WeatherJavaBean_mapping.xml file.
Data mapping files: The helper beans in the itso.objects package perform the data conversion from XML to Java objects and back.
A servlet is defined in the Web deployment descriptor to invoke the JavaBean.
Hope this information help you.
Those files are related to the WebSphere mapping between Java, WSDL, and XML. They are automatically generated, and should not need to be edited. You should pretend they are not there (except if they are not there you may have trouble deploying...).
SEI - Service Endpoint Interface
ser - Serialize
deser - Deserialize
helper - ?
Here are some psuedo-helpful links, that may provide some more insight into your question:
IBM Technotes
WebSphere v6.1 Handbook (check Chapter 15 -> Creating a Web Service --> Generated Files)
All these files are basically generated for webservice.
A web service ia basically a port between 2 running applications independant of the framework or language.
Leta say if you are using java from one side of web service then for complete compilation the java end would need some class files that have those methids which you wish to call on the service.
For this a stub is generated. This stub is basically an interface(SEI).
Also websphere needs additional files for implementing the webservices functionality, thus tge helper files.
This is basically the summary of it.
I'm searching a java rest framework or JAX-RS implementation that allows me to configure the dispatcher at runtime through an API. In JAX-RS it is only possible to do the configuration with #Path and #HttpMethod annotations or by effectively building your own dispatcher in a sub-resource.
I'm searching for:
dispatcher.addResource("/my/{path}", Resource.class) or
dispatcher.addResource("/2nd/path", resourceHandlerFactory)
Unfortunately there is nothing in JAX-RS for dynamic resource specification as you've found. Apache Wink has another alternative to Restlet called DynamicResource http://incubator.apache.org/wink/1.1/html/5.1%20Registration%20and%20Configuration.html. I'd be quite interested in why you need dynamic resources as I had similar requirement.
Try Restlet. It provides runtime dispatch functionality through its Router class. See http://wiki.restlet.org/docs_2.1/13-restlet/27-restlet/326-restlet.html for an example.