I need to create a web service project that creates some web services and exposes the end points using SOAP and REST. I've done a lot of JAX-RS work but I'm a little light on an JAX-WS implementations. Is there an open sourced technology that implements both?
I would suggest Apache CXF. It is an open source services framework which will allow you to do exactly what you need.
Related
our problems:
a sets of existing applications (recruiting, purchasing, payroll etc..) communicate outside through various ways (email, pdf, csv file, webservices etc)
a new ERP system we gona use(SAP or Agresso) communicates the outside through web services
we need integrate the existing systems with the ERP system, and apply some rules
my questions:
can we do the job by only using CXF?
is CXF a subset of camel
or perhaps to achieve what we want, we have to combine those two?
also Mule doesn't give a specific price for the cost, anyone had experience with MuleSoft?
thanks for time!
The comment by BMW is very true.
However to answer you a little more closely.
CXF is a services framework. It allows you to create SOAP, REST and even CORBA services. So yes it can help you create and consume web services.
CXF is a component used inside Camel, CXF is not a subset of camel. Camel will allow you to provide and consume web services using CXF.
Camel is a EIP(Enterprise Integration Pattern) framework which allows you to do things such as route a file to a web service. Or expose a SOAP service that talks to JMS queues etc. I know Camel also has a SAP component.
Thus Camel orchestrates the various components into routes that allows various systems to integrate.
In short you will use Camel with the CXF and other components to resolve your problems.
I have not used Mule yet but I can tell you this. You can host your Camel routes on Apache Karaf and create your own light weight "ESB" so no need to use Mule ESB.
Another alternative would be Fuse ESB and also Servicemix. THey are also capable of hosting Camel route.
I currently have several camel routes that expose web services and consume various data from files, rss feeds etc hosted on Karaf and it works like a charm.
Does a RESTful web service (e.g. in a JAX-RS implementation) support both contract-first (top-down) approach and contract-last (bottom-up) approach?
Do RESTful web services support both contract-first and contract-last approaches?
It depends on what tools/frameworks you use.
What you are talking about applies to a SOAP web service and its accompanying WSDL.
A WSDL describes what a web service expects as input and what should a client expect as output. It defines the contract to be followed in order for both parties to communicate with each other. You can obtain the WSDL by doing contract-first or contract-last and you can later use this WSDL to generate code for a client stub or a service skeleton.
But doing REST isn't the same as doing SOAP. Processes that worked for SOAP (a protocol) can't necessarily be applied to REST (an architectural style) just because we are familiar with them.
Unlike SOAP that exposes methods and method signatures, REST exposes resources. An understanding of the media types used in the exchange of those resources is all a REST client needs in order to communicate with a REST web service. There is no need for a separate document to describe the resources.
Because of the HATEOAS principle, REST clients are more dynamic and can adapt to other services that communicate using the same media types. Exposing static service description documents would be limiting for a REST service.
Having said that, there are REST tools that do expose a description document, for example Jersey who exposes a WADL (contract-last). I'm sure you can use the published WADL to build client stubs and I don't see a reason why you couldn't write the WADL by hand (contract-first) and use it to generate stubs and skeletons. But as I said, that might not be the best solution for REST.
Here are some posts you might want to read to form an opinion if contract-last or contract-first approaches make sense in REST:
Does REST Need a Description Language?
Why the slow WADL uptake?
I have to implement SOAP based web services for a project. We are considering different options like axis2, ejb as a web service, jax-ws but not really sure about the advantages/drawbacks of these options. Can someone please help in this regard.
It would be great if someone can point to any other alternatives for implementing SOAP based webservices.
Thanks in advance,
-Csn
For me, the easiest way to expose a web service is creating an EJB with annotations (JAX-WS) if you are using a Java EE server like JBoss.
Consuming a WS is a bit different but I prefer JAX-WS too, because Axis2 throw exceptions if you use complex parameters (classes) and you add an attribute. JAX-WS instead calls every 'get' and 'set' for the serialized xml. If no 'set' is implemented, no problem.
That's an advantage for backward compatibility.
I would highly recommend to use Apache CXF for developing SOAP web services. This stack is based on JAX-WS but has much more features. CXF has an excellent integration with Spring. There are a lot of documentation on the internet how to create web services using this framework. If I would be working on completely new web service I would definitely choose Apache CXF.
i am new to REST Service development. I compared the development mechanism for both REST and WS web services and i found that you can create a WS web service using WSDL file that is the top down appraoch (Correct me if i am wrong) and using bottom up approach also, that is generating the classes manually.
But when it comes to REST web service development you have to follow bottom up approach only that is generating the classes manually. NetBeans IDE provides certain wizards for creating REST web service quickly from databases, entity classes and patterns.
I had also seen when you are developing web service in eclipse and you are using wizard in eclipse IDE, you can create a REST web service from WSDL file. I found this very strange. My question here is what are the approaches we can have for creating REST web services. Can we create REST web services using top-down and bottom up approached. If yes then please provide me details.
Thanks.
It is possible to describe a REST service using a contract. This is the intent of WADL and WSDL 2.0. WADL is specifically a REST contract, whereas WSDL 2.0 evolved from the original WSDL spec. to support all HTTP bindings. Since REST services rely on the use of HTTP methods and headers to exchange messages a WSDL 2.0 contract can work. There is a really good explanation here: http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and-wadl
For development of REST services, I'm not sure if NetBeans, Eclipse or other tools specifically support automated REST service from WSDL generation. I would imagine that most are still intended for SOAP service creation. At this point I think WSDL 2.0 and WADL can be used to describe a REST service, but are not intended for automated generation of a REST service.
REST services are simple HTTP request/response,and therefore don't require complex stubs. In most cases it would probably take more time to write the WSDL describing the REST service, than it would take to write the REST service itself.
I need to develop Webservice Application for our Client .
I dont know anything about WSDL4J
From the net I found this
"The Web Services Description Language for Java Toolkit (WSDL4J) allows the creation, representation, and manipulation of WSDL documents.
Is the reference implementation for JSR110 'JWSDL' (jcp.org)."
But anybody please tell me why should we use WSDL for developing webservices?
Is there any specific advantage we will get?
And can anybody please point me a link where to start for working with WSDL4j?
You actually need not to use wsdl4j for developing web services or clients for web services. There are other SOAP stacks developed on top of that. Axis2 is such an open source SOAP stack..
WSDL2Java tool that comes with Axis2 - which been used to generate client side stubs from a given WSDL. uses wsdl4j internally..