Develop Reference

REST and RESTful WS

I have worked on RESTful Web Services at a high level (not very exhaustively), coded few REST based web services.
To begin my journey in RESTful WS, I read online articles (wiki, online tutorials etc.) and I came to know that it is an architectural style specifying constraints and when applied to web service induce desirable properties, such as performance, scalability etc. Ok, this is the theory part of this concept.
A simple example using JAX-RS:
#Path("/simple")
public class SimpleRESTService {
#GET
#Path("/{param}")
public Response getMsg(#PathParam("param") String message) {
String output = "Jersey say : " + message;
return Response.status(200).entity(output).build();
}
}
My doubt is:
If REST is architectural style (and using those guidelines build RESTful web services), what does JAX-RS do? To what I understood, REST is just architectural style and not any specification, what does JAX-RS has to do with this? I am having difficulty in understanding the relation between these two entities.
Can anyone help me understand this in simple words.

REST is indeed an architectural style of building web services independent of application-layer protocols (it could be implemented over FTP or HTTP as well).
JAX-RS is just a standardized API of Java EE with which you can easily implement RESTful services in Java. It is a toolkit for a developer to lift the burden off his shoulders, and as part of Java EE, it is implemented in application servers such as WildFly out of the box.
But note that it is just as possible to create REST services in frameworks like Spring using the Spring Web MVC and Spring HATEOAS modules.
Edit:
Although REST is a well-defined architectural style, it is (as you mentioned) not a specification so there is a lot of foggy areas about it among developers.
In a nutshell, all it states is "Hey man, if you use the communication protocol (say HTTP) this way and this way, it will be very convenient for you to change and scale and it will be very straightforward for the clients of your service to talk to you".
JAX-RS gives you the ability to define service endpoints with dynamic parts (eg.: /api/jediknights/{id}, so that the id could be anything), makes it easier to respond to the client in the format of your (or your client's) desire, like XML or JSON. It provides convenient wrapper objects to wrap your response body along with status codes and headers and many other things of convenience.
The catch however is: it is still your responsibility as a developer to adhere to the principles stated by the REST style. Nothing is really enforced upon you by JAX-RS.
To be fair, you could even achieve a RESTful web service by only using the somewhat lower-level Servlet API. JAX-RS just hides the unnecessary details from you and will make your life easier.
I hope it became a bit clearer :)

Java API for RESTful Web Services (JAX-RS), is a set if APIs to
developer REST service. JAX-RS is part of the Java EE6, and make
developers to develop REST web application easily.
You can read some more here: http://www.mkyong.com/tutorials/jax-rs-tutorials/

ESBs vs Services

I'm new to Java EE and have been struggling with some basic middleware concepts for several days now and believe I might have just had a breakthrough in my understanding of "how tings work"; a part of this question is a request for confirmation of my findings, and the other part is a legitimate question ;-).
Please confirm/clarify: My understanding of service buses/MOM (message-oriented middleware) is that they are by nature intended to process client requests asynchronously. This, as opposed to the normal request-response cycle, which is synchronous, which is usually implemented by some kind of service. In Java, such a bus/MOM could be something like Apache Camel, and the synchronous service could be something like an EJB(3). So if the client needs a request processed right away, the HttpRequest may go to a web service which then forwards the request on to the correct EJB; that EJB process the message and returns the result to the service, which then returns the HttpResponse to the client. As such, if the client has a request that does not block them and which simply needs to be processed, the web service forwards their HttpRequest on to some endpoint on a service bus and the request is treated like a message and is handled by various processors (filters, transformers, etc.).
So first off, please correct me if I am wrong in stating that an ESB/MOM solution is best suited for handling asynchronous requests, and that EJBs (again, 3.x) are best suited for responding to synchronous requests in real-time; or confirm that I am correct.
In that case, it seems to me that big applications would need both types of backends to handle synchronous (blocking) and asynchronous (non-blocking) client requests alike. So my theory would be to have my backend implemented as follows:
Use a full-blown app server like JBoss or GlassFish
In the app server's web container have two WARs: WebServices.war and ESB.war; which represent the backend "gateway" and service bus respectively
In the app server's business container have all my EJBs
Now, the WebService.war (gateway) can detect whether to relay the request on to the ESB or the EJBs
My second question is: am I way off-base here and have I missed the basic concepts of Middleware 101, or is this a half-way decent approach?
Edit: From the initial responses I already see that I was wrong in two areas: (1) that ESBs and EJBs can in fact be either synchronous or asynchronous, and (2) that, when using MDBs, EJBs can be wired up like an ESB.
So these correction pose some new mental obstacles for me:
When to go with an ESB, vs. when to go with a MDB/EJB solution; and
I really like Apache Camel's Processors API (implementation of EIPs); could I use MDB/EJBs but inside every EJB just use a Camel processor (Filter, WireTap, etc.)?

This is a big question and it deserves a big answer.
ESB's can handle synchronous or asynchronous requests and messages are typically used asynchronously.
However your backend implementation theory is pretty wrong.
JAX WS web services can run straight our of an EJB jar or an EAR and can do it that way in any app server. The EJB can put a message onto a queue or even be asynchronous.
You should not be relaying requests to the ESB but the other way around.
The ESB should be relaying and transforming requests and responses between clients and backends. One of the big ideas with ESB is that if a backend changes the client does not know or care since their contract is with the ESB not the backend.
All this said, if your application is already exposing web services, then you probably don't need an ESB and remember there is no one RIGHT or WRONG way to do something.
I do suggest that you write a more defined question that covers your specific problem, you will probably get a wealth of advice on how to solve it.
UPDATE
You also get message driven EJBs which would indeed let EJB's be chained together in a bus like fashion.
FURTHER UPDATE
So one scenario when I would use an ESB is if I need to expose non standards based services in legacy systems as a SOAP service. However there is more to consider, you should also implement a data dictionary for your organization, this will allow a greater chance that the ESB exposed services can remain the same even if your legacy system is replaced.
So as a concrete example, the organization should define in its data dictionary what a customer entity looks like, the ESB could expose a service to retrieve a customer. The ESB will perform some call on a legacy based system and then transform the result. If in future the backend system storing customers changes, the ESB exposed service can probably remain the same, and just the backend call and transformation needs to be updated.
Now hopefully with that in mind the next bit will make sense. All of this is possible with a "traditional" ESB such as JBoss ESB or Mule ESB BUT it is also possible using EJB + Camel (or other things).
The advantage of the out of the box ESB are the provided connectors, listeners and transformers. However if none of the out of the box features helps you then there is very little difference in the direction that you choose.
An advantage in home growing your ESB would be maintainability, it is much easier to find a resource who knows EJB well and can learn Camel quickly if they need to, than finding a specialized ESB resource or training a resource.
I hope that helped!

As you have noticed, the world of middleware/integration is kind of a mess in definitions and terminology. Let me clarify a bit.
A service is just a concept of "something" that delivers a capability. There are multiple ways to expose a service.
When refering to EJBs below, I mean EJBs except MDB (Message Driven Beans), which implement asychronous messaging.
Synchronously request/reply - where the reply is expected "rather soon" after the request. Usually implemented via Web Services and EJBs (RMI,etc).
As a published message to a number of subscribers that consume the data (typically price-lists are pushed out from a price-master system to various systems needing the information, such as the order system).
As a fire-and-forget message from one application to the other. Typcially, the order system needs to send an order to the invocing system, then the invocing system exposes a service to create invoices.
Conceptually, an ESB, is a soft thing. It's a concept/agreement on how a companys business services should be exposed so that applications across the company can consume/use those services. This could essentially just be a set of contraints "Only request/reply services are allowed using SOAP/WebServices and all messages should conform to the OAGIS XML standard". However, in most cases, the application/server/system environment at most companies are not homogenous. There are COTS products, mainframes with COBOL applications, .NET apps as well as Java EE applications. Therefore a common approach is to use an ESB software suite to implement the service bus in technology, or to construct adapters towards the bus. Apache Camel could be part of an ESB implementation to setup routing, transformation, conversion etc.
One thing that is tightly integrated with ESB is Message Oriented Middleware, which you speak ok. It's typically just a server that implements message queuing. The benefits from MOMs are a few in contrast to just ivoking EJBs/Web Services directly.
If asynchronous patterns (publish/subscribe, fire and forget and async. request/reply, then a relay server that has a high up time and is very stable will make it possible to, overall, have less failed transmissions of business messages.
MOMs, ususally makes it rather easy to implement adapters and an ESB that is very resilient to load peaks, network disturbances and hardware/software failure. Messages are often persistent and are stored to disk before relayed. Also transactions are often available, specifically in JMS compliant implementations. That guarantees that data is not lost on the way.
I hope I did not mess things up more than before. This is my view of this at least.

what is the difference between Restful web services and WSDL? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
WSDL vs REST Pros and Cons
can any one explain what is the difference between Restful web services and WSDL(Web Service and Description Language). And which one is more secure and how?
Thanks

WSDL is used to describe SOAP services. You're really asking for a comparison of SOAP and REST.
There is no inherent security difference between SOAP and RESTful services. Most likely any security issues will be with your specific implementation of them.
SOAP is more like RPC - it focuses on calling commands on a remote server. REST is resource oriented - you interact with the server by adding, retrieving, updating and deleting resources on the remote server, which corresponds to actions.
eg. With SOAP service you might call an updateAccount(account_id, details) method to save changes, but with a REST service you might PUT information to /account/<account_id>.
In Java, JAX-RS is a good place to start with RESTful services.

WSDL "Web Services Descriptor Language" is the standard for defining the content and behavior of SOAP based web services. It is part of a collection of WS* standards that define "Web Services". These standards cover discovery, transport, message format, authentication, non-repudation etc. etc.. These are formal standards managed by W3C.
REST is a style of network programming where every request is made in the form of a valid URL to identify the "key" of the object in combination with an http GET, PUT, POST, or DELETE action to identify what you want to do to it.
REST is a style rather than a standard messages can be in XML, JSON or any format you choose.
My opinion is that REST is great for doing simple things simply. SOAP etc. is great for complex "enterprise" level interactions with sophisticated security and workflow requirements, but, its overkill for simpler services.
As for security REST does not help you. But using standard web security (sessions, cookies, SSL etc. ) you can secure a RESTful service pretty well.
SOAP has built in bulletproof security but its configuration heavy requiring LDAP servers and managing public/private key pairs. Unless you really need it its best left alone.

Require help on Java EE infrastructure choosing the right "mix"

I am a bit lost nowadays with all the available libraries out there. What I'd like to have is a small app server (best: jboss as7 as it is very lightweight and based on osgi) and have a lightweight, yet efficient soa-like infrastructure. I was looking on apache service mix though it looks quite complicated/complex. What I basically want to have is this:
Easy definition of stateless services (easy as in a simple java pojo class)
Modularization with automatic service discovery using osgi
Services can automatically represent themselves as either WebService OR (!!) JSON-Format like REST Service
Integrated, easy to handle authentication using OpenId to secure any service endpoint including handling all validation/verification processes
I couldn't easily figure which of all frameworks would really fit in, for example, in Apache Service Mix I can't seem to find support to represent services as JSON-like RESET services nor could I find any integration of security?

Sounds like you want GlassFish 3.1 to me. I can't speak to JBoss or any of the other Java EE 6 containers.
Java EE 6 pretty much covers most of your requirements:
Easy definition of stateless services -- that's a Stateless Session
EJB, and that's just a Pojo -- put #Stateless at the top if it.
Services can automatically represent themselves as a WebService --
that's also a Stateless EJB -- put #WebService at the top of it.
Integrated, easy to handled authentication using OpenId -- JSR 196 (Java Authentication SPI for Containers) covers that, but you'll need an implementation specifically for Open ID. Oh, apparently here is one.
That's all just plain 'ol Java EE 6.
For OSGi, GlassFish 3.1 is a full boat OSGi platform and all of the EJBs are also OSGi discoverable. So I guess you get that for free as well.
As for HTTP JSON WebServices, JAX-RS will do that, but not "for free" like #WebService can. But creating a facade of HTTP RPC on top of a Session Bean should be trivial, since JAXB in Jersey (the JAX-RS implementation within GlassFish) will publish Java as JSON or XML.
So, I'd start there with GF 3.1 and bend it until it breaks rather than running around the net playing ala carte.

Architect desperately wants to use SOAP over JMS

I have used JMS in the past to build application and it works great. Now I work with Architects that would love to use the Spec : SOAP over Java Message Service 1.0.
This spec seams overly complicated.
I do not see many implementation (Beside the vendors pushing for the spec).
Does anyone here is using this specification in a production environment?
What is your main benefit of using this spec?
Link: http://www.w3.org/TR/2009/CR-soapjms-20090604/

I had the bad luck using SOAP over JMS. It does make some sense, if it is used for fire-and-forget operations (no response message defined in the WSDL). In this case you can use the WSDL to generate client skeletons and you can store the WSDL in your service registry. Plus you get all the usual benefits of JMS (decoupling sender and receiver, load-balancing, prioritising, security, bridging to multiple destinations - e.g. non-intrusive auditing).
On the other hand SOAP is mainly used for request/reply type operations. Implementing request/reply pattern over JMS introduces the following problems:
Impossible to handle timeouts properly. You never know if a request is still waiting for delivery or got stuck in the called component.
Responses are typically sent on temporary queues. If the client disconnects before receiving the response and there is no explicit time to live set on the response message, the temp queue can get stuck in the JMS server until you restart it.
Having a JMS server in the middle dramatically increases roundtrip times and adds unnecessary compexity.
JMS provides a reliable transport medium that decouples the sender from the receiver, but in case of request/reply the client should not be decoupled from the server. The client needs to know if the server is up and available.
The only advantage I could think about is that the server can be moved or load-balanced without the client knowing about it, but using UDDI and HTTP load balancer is a better solution.

I'd say that from an Architect's prospecting the same question would be about why having a 5 layer Internet model, with the 5th being the application when one could simply code the entire application at the socket level. To abstract out the Transport layer (JMS in your case) from what your application produces or consumes (SOA messages) is a good practice for may reasons amongst which independent unit testing, and future migration to other platforms are the first to come to my mind

Goddammit, I hate working with Architect Astronauts. I feel your pain brother. Do they actually have a actual, functional reason for doing so other than "it's a standards"? Is this decision going to lock them into a specific EE container vendor (say WebSphere)? That is so 2002; very few people have a real need for it; and in fact, SOAP has been pretty much ignored by most practical, successful implementations. Unless they have a real need for more reliability than what it is provided by JMS or SOAP-over-HTTP alone, you are in for a trip.
Check out the Apache CXF site for some examples (specific to CXF).
http://cxf.apache.org/docs/soap-over-jms-10-support.html
The rule of thumb would be to really use the bare minimums, and not the full stack. If your architect astronauts still insist in using the whole thing, you might just be walking into a world of pain. Sorry.
EDIT:
BTW, what application container will you be using? WebLogic, JBoss, WebSphere? And which web service framework? Apache CFX, Axis?
Architects astronauts will love to say that those are implementation details. Bull. Any decision on a system whose change carriers a great cost (or whose implementation carries significant savings) is an architectural decision. These pretty much dictate how things will be implemented (and what the cost of change will be) so determining early on which you will be using is an architectural decision except with very self-contained systems.
A few more links on this controversial subject:
http://www.subbu.org/blog/2005/03/soap-over-jms
http://parand.com/say/index.php/2005/03/29/soap-over-jms-no-such-thing/

SOAP/JMS and SOAP/HTTP are used for different scenarios albeit with Message Fire and Request/Response.
SOAP/JMS is actually terrific for propagating discovered (if required converted) messages to multiple sourecs simply by usage of SoapAction and
targetService. The JMS Specs also help in complex routing using the headers.
In Fact, UDDI as well as build servers can, is AND has been used as sources to discover published WSDLs (inline) from massive middleware deployments (Irrespective of engine architecture) as a SOAP/JMS Message to singular SOA Repository Sinks. Very Important in Enterprise Governance
Hence it is of utmost importance for wire tap patterns essentially when asynchronicity is of paramount importance.
SOAP/HTTP and now REST (with the verb noun model) work best for trusted sub-system calls

Image you implemented a frequently used Web-Service, that
tends to run ouf threads, while you promised, that no message
will be lost.
A Webservice implementation (the server) that runs over a
session bean comes with a limited amount of threads (say n
active PE in your pool), that may run n web-service request
concurrently. What will happen to the n+1 request ?
MRDE, didn't you promised you application owner, that no
message will be lost. So the JMS quaranties this functionality.
The Webservice skeleton only has to store the data in a queue,
and this give reliability also with regard to load-peaks.
The interesting thing about WS over JMS is, that the elapsed time
of a running WS-request is quite short, so the computing ressouce
will be back immediately to server the next request.

From here :
SOAP over JMS offers an alternative messaging mechanism to SOAP over
HTTP. While it is not yet standardized and hence may not be
interoperable across platforms, SOAP over JMS offers more reliable and
scalable messaging support than SOAP over HTTP. As JAX-RPC and JSR-109
become integral parts of the J2EE standard, enterprise messaging in
Web services using SOAP over JMS will become well-established.