Is AXIS or CXF necessary for Java web services? Can it be all done via the JDK (1.6)?
Is AXIS or CXF necessary for Java web services?
No. Although Axis2 is the most popular framework to work with Web Services is not the only way to do them.
Can it be all done via the JDK (1.6)?
Yes, but it is way much harder. You will benefit tremendously from using a framework used by others apps and from the bug fixes the development team provide. Doing all by hand is like reinventing the wheel.
If you want to have full control of what's happening underneath, probably you could go with: JAX-WS
or if the application is very simple, directly with socket.
But again, Axis2 is the canonical way to do WS ( but not the only one )
The following is based on an all to true and personal story:
So you want to consume a web service in your Java web application, and you don't want to add 10MiB of JARs to your lean 1.3 MiB .war file, and besides you are great at parsing XML (you can hand code XPath Queries, and XSLT files), you totally understand HTTP, and the client you are interfacing with has great documentation. You download the WSDL look at your endpoints and your methods and start creating a Java class that maps to the features you are going to need. You feel great already.
They you start reading up on how to send a SOAP request and you think well this looks a little verbose but what they hey it's all just a string, so you start building a utility that takes your Java request object and converts it to a SOAP request. You send your clear SOAP request to the server but it gets denied (missing a signature).
So now you start adding encryption JARs to your project and you start looking at how to calculate a signature of part of an XML document and include both it and the document in the request. This takes you a while but with enough hacking you get a message that you can send to your soap service and you are now dealing with the SOAP response. Now you are feeling great...
Until the admin at your client changes their security requirements, issues new public keys, and updates the soap interface with some custom types, and your next client who is running a similar service (but on a Windows Server) wants you to implement with them as well.
At this point I gave up trying to implement this in a pure Java way and just started using standard libraries. They deal with stuff like encryption, marshaling, deviations form the standards and they let you focus on stuff that is closer to your problem domain. I hope you can save yourself the lost month it took me to learn this lesson.
An update on the landscape of web services in 2013.
Web services used to be SOAP and XML-based. Web services were standardized into JAX-WS. Some of the more popular frameworks are (were):
Axis 1.x
Axis 2
Apache CXF - CXF also includes other protocols. It is a much broader framework
Metro Web Services which includes the JAX-WS Reference Implementation.
Java 6 and Java 7 include the JAX-WS RI by default. It means that frameworks are no longer needed except to generate client and service stubs / skeletons
There are other implementations not listed here that are vendor-specific e.g. IBM Websphere's WS implementation and Weblogic's WS implementation.
Generally though, to create web services, I would recommend Metro and the JAX-WS RI.
Note that there are many WS-* standards e.g. WS-Security which may not be part of all WS implementations.
Since web services have been around for a while, other alternatives have come up both in terms of architectural style, protocol, and encoding.
For instance, XML used to be the de-facto encoding. JSON is now more prevalent. It is worth looking into Jackson, a JSON parser, or Google GSON. The main arguments in favor of JSON are that it is easy to use, lightweight, and developer-friendly.
Along with JSON came REST. REST is an architectural style. With REST, you can still implement "web services" in the sense of remote services that can be easily consumed over a network. REST has also been standardized in the Java family of standards as JAX-RS. Some of the popular JAX-RS implementations include CXF, Jersey, and RESTLet.
Finally, there are some new kids on the block that use binary encodings. Those are Google Protocol Buffers and Apache Thrift. Their main goal is performance as well as broader support for other languages (Java, C#, Erland, Perl...).
When developing a web service today, the question should be:
- do I care about performance?
- do I want to access the service from many different languages?
- do I want mobile-friendly?
These should help you guide your choice. Also, I prefer to keep my dependencies to a minimum. This means I would rather take something that is native to the JRE or JDK e.g. the JAX-WS or JAX-RS reference implementation.
As an alternative to Axis, you can use the Spring WebServices framework to run your webservices application within a J2EE container like Tomcat or anything similar. I've found it very easy to use and setup, and if you want to integrate your webservices into another web application later, it's quite easy to do (I've done so myself on two separate occasions).
You can use the http streams provided by the webserver as you whish, but using a framework and some jars (which are proven to work) will save you a lot of headaches and a lot of time in the long run.
Normally you will want to use a programming framework for web services.
Something like AXIS, CXF, or the Java EE (GlassFish) download from Sun.
Related
I feel a bit naive for asking, but I'm trying to get a better understanding of web service frameworks.
Do you absolutely need a Jax-WS/RS reference implementation (like Axis/CXF) to run a web service application on a server like Tomcat? Is it at possible to get by with a collection of your own imports (Spring Framework libraries, Java EE libraries, JAXB, etc.), provided that you do not need things like wsdl2java auto-generation?
Are Axis/Axis2/CXF an essential part of any web service project, or just a nice to have?
I've used CXF and Axis in the past, but both were buried so deep beneath Spring and my IDE that I never got a clear picture of where the web service framework ended and the Spring framework/dependencies began.
The documentation on the web service frameworks also doesn't tell me much, as it focuses on what they frameworks can do, vs. how you might be able to get by without them.
Thanks
If you want to deploy a web application on Tomcat then the bare minimum you need to do is implement the javax.servlet.Servlet interface.
If, by web service, you mean a SOAP service, then there is more you will need to do (well, to be specific, you will need to implement a Servlet which behaves in a certain way). There are two primary features that frameworks like CXF/Axis provide (and a myriad of smaller features):
Serialization/Deserialization
Bare HTTP requests are available as streams of bytes (InputStream/OutputStream). In many applications you will want to convert those byte streams into Java objects. With JAX-WS this is done by requiring the input/output be XML and using JAX-B. Other frameworks (e.g. JAX-RS) can work with other input/output formats (like JSON).
Routing
An HTTP request consists of a URL (perhaps with query parameters), headers, an entity body, and various metadata around the call itself (e.g. IP address, session object, etc). Somehow this request has to get mapped into a method call in your service, with parameters. In JAX-WS this is done by mapping parts of the SOAP envelope with information about your service endpoint gleaned from reflection.
So...
If you want to skip using Axis/Axis2/CXF you will need to find some way to implement those two features yourself. You will almost certainly also be surprised by the amount of tiny details involved in solving those problems (e.g. SOAP RPC/encoded message format versus document/literal format, etc.)
CXF will also implement a number of SOAP extensions, the most prominent of those being ws-security (although many people end up using Spring security and bypassing formal SOAP security anyways).
Alternatives
Your question is a little vague so I'm not certain what you're after but there are some alternatives.to just using Axis/CXF...
Different JAX-WS library
There are other JAX-WS providers out there. For example, you could use the JAX-WS RI although your experience is not likely to be too much different than CXF/Axis.
Different web service technology
Rather than using SOAP you could use a RESTful framework like JAX-RS. This can be particularly helpful if you want to understand more the connection between HTTP and your calls. There are a myriad of articles discussing the benefits/drawbacks of SOAP vs. REST so I won't go into that here. In general JAX-RS is a lot more clear and customizable but requires more work to configure.
Given a task at work to understand the usage of java webservice or aka JAX-WS in eclipse IDE with axis2 tool and using soap UI to view the messages.
looked at few examples on [http://docs.oracle.com/javaee/6/tutorial/doc/bnayl.html][1] and also tried a example to retrieve database info to soap ui message but still not confident to say that I understood everything.
Need clarity on the points below:
What is axis2 tool and what it does to help when combined with eclipse ide
soap ui - as the name says its a user interface to view soap messages if I am not wrong, but what is other way of running a webservice with out soap ui and what is the convenience for a developer to adopt to soap ui
As I am simultaneously learning webservices with burden of understanding tools at the same time please guide me few good tutorial sites.
Thank you
I did more or less the same few years ago. My experience is as follows (your mileage might vary):
you need to understand XSD well
when you look at few WSDL examples you will figure out that WSDL is XSD + little overhead, which is almost always the same
it helps to play with examples, I personally found axis/axis2 bit clumsy, if possible take another provider, e.g. JBoss or reference implementation (Glassfish), but perhaps you will have to use axis afterwards, so better to stick to it from the beginning. SOAP UI is ok, you use it as client.
I read one of the books on axis and one on JAX_WS alone. I would recommend the JAX-WS book, which did good job covering all the theoretical background and provided lot of examples. Bit boring read but good for getting started and as a reference.
Axis2 is WebService provider. It's a bunch of libraries and tools which on one hand generate for your the needed artefacts (Java from WSDL or the other way around) and on the other when packed into a web war allows you to publish a webservice by deploying the war in a container, e.g. tomcat. Yo might start by deploying one of the examples in Eclipse into Tomcat (running in Eclipse or outside) and write and run a Java client against it. Writing a simple client against a running service is good alternative against SOAP UI. SOAP UI helps you to understand the JAX-WS at protocol (SOAP) level. For playing with axis (not axis2!) was the axis book helpful.
Instead of SOAP WebServices, go for RESTful WebServices. RESTful Web Services are build to work best on the web.
REST is almost always going to be faster. The main advantage of REST is that it provides a mechanism for services to describe themselves to clients, and to advertise their existence.
REST is much more lightweight and can be implemented using almost any tool, leading to lower bandwidth and shorter learning curve. However, the clients have to know what to send and what to expect.
REST has no WSDL interface definition
REST is over HTTP,
but SOAP can be over any transport protocols such HTTP, FTP, STMP, JMS etc.
"In general, When you're publishing an API to the outside world that is either complex or likely to change, SOAP will be more useful. Other than that, REST is usually the better option".
In the REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs), typically links on the Web.
REST is an architecture. REST will give human-readable results.
REST is stateless. REST services are easily cacheable.
SOAP is a protocol. It can run on top of JMS, FTP, Http.
The REST architectural style constrains an architecture to a client/server architecture and is designed to use a stateless communication protocol, typically HTTP. In the REST architecture style, clients and servers exchange representations of resources by using a standardized interface and protocol.
I like Play 2.0 much (especially Scala API). But it lacks SOAP completely. Is there some not mindblowing way to provide SOAP WS (wsdl based) from Play 2.0?
Say, I'd want it to be accessible from some URL (e.g. /soap), preserving other pages to be HTML. Please, help, I have no clue (I'm java newb, and zillions of abbreviations for frameworks and libs make me confused).
PS To prevent possible unproductive treatments: I'm a java newb but not a newcomer programmer, so I know how SOAP, HTTP and other stuff are meant to work at protocol level.
I ran into the same problem - Apache CXF and Axis2 depend on the Servlet API, which the Play Framework doesn't have.
I created a custom transport plugin for Apache CXF which connects to Play's Controller API.
There is a tutorial about setting it all up in an empty project: http://www.imind.eu/web/2013/11/07/developing-soap-services-using-play-framework-2-2-x/
The plugin's source (and a sample Play application) is here: https://github.com/imindeu/play-cxf
If you trying to create a web service API for existing business logic that will be part of your Play service, then you should probably look using existing Java libraries that can do the SOAP magic for you (e.g. Axis2). Scala can use existing Java libraries without any problem.
However, most people would strongly recommend you look at a REST service rather than a SOAP service, if this is an option. Have a look at Play Mini to see how this is done.
UPDATE:
Ah, this may help you: https://github.com/mandubian/scala-xmlsoap-ersatz
We are building a web-application and a significant portion of the project will be making real time calls from our servlets to some back end webservices. Some of these calls will be cached depending on the context. We will also have a reqiurement to handle incoming double byte character strings for languages such as Hebrew and CJK.
The platform this web application is in is Java.
What types of frameworks should i use for consuming and calling these web services? Axis 1/2? Does an ESB such as Mule give me some added features that will come in handy?
Clarification point: We will only be consuming webservices. We will not write and provide our own webservices.
Axis2 will work fine but I'd also consider Spring-WS. If this is a basic web service and you don't anticipate alot of consumers then I would shy away from ESBs and such (ESBs are great if you need them but don't force them if you don't need them).
I'd also suggest that you take a look at Apache CXF as well as Apache Axis2.
If you use Java 6 it has built-in support. I use IntelliJ to generate the needed classes from the WSDL (which in turn calls wsimport) - a recent client shipped in a 26 kb jar.
For your requirements an Web service implementation like Axis 2 should be good enough. Also there are other implementations like Spring web services too. Unless you need some serious service orchestration and service mash ups, an ESB will probably be an overkill.
Axis2 is good. You can deploy the WS and then, use the Eclipse wizard to generate the client.
How can I interop easily between WCF and a Java app.?
WCF is a web service framework. Java also provides its own web service frameworks. They should be able to interoperate quite easily, although you'll need to ask a much more specific question if you want a better answer.
edit: The ProjectTango link you ask about says it all in the first paragraph:
... to ensure interoperability of
enterprise features, such as security,
reliable messaging, and atomic
transactions.
These are fancy additions to basic web services, and the specifications alone are not enough to ensure compatibility.
Basic web service interaction, which is all 99.9% of us ever need, will work just fine between WCF and Java.
Short Answer, Yes.
Long Answer, the interoperability depends on several factors. Basic interoperability is very easy. Only when you throw in factors such as security that things get complicated. We did some research on availabe Java web service frameworks and found out that the best suited one for our scenario is the metro stack along with netbeans 6.5 IDE. We achieved message secuity which has mandatory for the project using client/server mutual certificate authentication.
Some gotchas discovered in the process are:
- You have to add the webservices-rt.jar library from glassfish directory in netbeans project. (doesn't need glassfish to be running, just the jar file)
- WCF generates multifile WSDL files and netbeans cannot use them to generate proxy, although if netbeans is configured to use the URL (http://../?wsdl) it can generate the proxy.
- You have to put [IsRequired=true] on all datamembers in WCF. Java's handling of optional datamembers is quite complicated.
- Dictionaries as datamembers comes out as list
We have done this successfully on several projects. We use WCF basicHttpBinding, it is the simplest option if you just need to get it to work.
One of the things that can be a show stopper is if a service uses a platform specific datatype, like a Java vector or a .net dataset.
You can use JAX-WS services on the Java side, and then use WCF in .NET.
First create the JAX-WS services (glassfish libraries will allow you to do this). Create your POJO's, add the JAX-WS annotations, and deploy your WAR. Then, get the WSDL generated by your server and give it to VisualStudio. VisualStudio can generate the client for you.
That is the simple way, but your mileage will vary of course.