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.
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.
I am trying to consume a public Web Service:
The Web Service uses SOAP communication
The Web Service doesn't expose the WSDL. It is possible to download it from the creator's website.
The Web Service only allows to connect via "whitelisted" static IPs.
The Web Service is hosted on GlassFish, so I am guessing it is written in Java.
The Web Service specification is rather long and contains many mandatory fields.
I would like to expose the Web Service to different type of developers during a Hackathon challenge, which may be using Python, Java, C# or other programming languages.
I used SOAPUI to test the Web Services and it was rather easy.
When I tried to use the standard packages in Python (SOAPpy) and C#, I had many difficulties. When using Java and CXF, it was a nightmare creating the request object.
How would you go about exposing the Web Service in a way which is friendly to developers?
No changes can be made to the original Web Services.
Thanks in advance!
If you want to access the original web service I recommend use its native protocol (SOAP) even though SOAP can be a major PITA and sometimes library support might be lacking (especially in modern script languages like Python, Ruby) because SOAP is not "cool".
ReST/JSON web services are deemed to be more "easy to work with" by many developers but shoehorning a "wrapper"/proxy on top of the existing web service will probably cause even more confusion and subtle bugs.
If the web service is fairly complicated this could mean this project is not ideal for a hackathon. If I were in your position I'd prepare client stubs (including a simplified library API) for 1-2 languages like Python and Java. For Python check out one of jurko-suds, pysimplesoap, or soapfish and check out which one works best out of the box with your service.
As I feel I'm drifting out of the StackOverflow scope I'll stop here :-)
Hi I am working REST Services and I just want to know how can I provide the web descriptor for REST Services. It will be great if their is some API that can directly produce the WSDL for REST Service.
I am using Spring STS for development is their anything inbuilt in Spring STS.
I have few more questions for the same:
Is it feasible to provide the descriptor for REST Service.
Providing the descriptor is not the violation of REST or HATEOS architecture style.
What are the different ways to achieve this.
REST services shouldn't use WSDLs. WSDLs are used for SOAP Web services, not for the REST design style.
Instead of using WSDLs, REST APIs should be discoverable.
Possible duplicate of this Stackoverflow question.
Though it's possible to generate some sort of WSDL if you use WSDL 2.0, people don't seem to generally describe REST services with WSDLs. This is because REST services are usually HTTP requests with GET/PUT/POST/etc methods.
At best, people can generate something called a WADL, but generating WADLs hasn't really taken off in the general community.
There's no de facto standard for describing REST APIs. If you need to automate it, I recommend looking up how to generate WADLs.
There are also other solutions/alternatives out there used to document and describe REST APIs. It all depends on what your actual requirements are.
Some other good Stackoverflow questions to explore:
What is the reason for using WADL?
Why the slow WADL uptake?
Web services are used to share the services provided by an application, to outside world. This is my basic understanding of web services.
Suppose my application is to expose some specific behaviors and I have written the code for it and exposed the methods. The ones who want to use it can take the link to the wsdl, generate stub and call the methods.
What is the use of doing all this, when I can myself expose the methods, generate a jar and bundle everything in it and share the server address,jar.
How differently is web services important, when compared to a case explained above. Am asking such a general question due to unsuccessful search in many websites.
If you'd generate a client jar, whoever wants to use that would have to deal with Java. If you expose a Web Service instead, the user can use whatever technology he/she wants to use (e.g. Python, Ruby, .net, C, C++ etc. etc.). That would be a huge advantage.
Web service use a series of standards(SOAP, WSDL...) to make different kinds of system work together, certainly you can generate client jar as you like, but that requires your service consumer to learn how to play with it, so it's not a generic solution.
What you are suggesting is quite close to RESTful webservices. Unlike SOAP webservices, RESTful webservices do not require any WSDL files. All that you need to do is to issue a request to a particular URL.
As you explained correctly (in my opinion) SOAP webservices involve some more work which needs to be done, thus making them more complex, if you will, to integrate with other systems. This is not the case with RESTful webservices.
EDIT: You can check out a tutorial here. I have tried it myself a while back and it is enough to get you started.
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.