* is language-neutral: it will allow the writing of software libraries for communicating with JMS providers in any language that has libraries for communicating over HTTP.
* is RESTful: it provides a RESTful equivalent to all of the non-optional portions of the JMS API including
o registration of resources administered by the messaging provider
o connection and session management
o sending and receipt of all types of JMS message
Implementation overview
HJB
*
is deployed as a servlet (HJBServlet), that can run on any compliant Servlet specification 2.4 container.
*
will work with any messaging vendor that provides a JMS interface.
*
aims to do one thing well. Its role is to act as an HTTP gateway server for JMS resources. Other potentially useful features are deliberately excluded, e.g,
o HTTP session management
o authentication and authorization
One of the biggest promises of Business Process Management was that the business people can model and execute their business processes without involvement from IT folks. This promise was kept in a simple workflow sceanarios by utilizing limited number of 'built-in' activity types of BPMS packages but once you face little more complex business process sceanarios providing transactional integration with existing software and complex interactions with human beings, this limited expression power make it hard to drag and drop process modeling, and finally it brings a huge help from software vendors or system integrators and write a lot of code that is making processes utterly inflexible downstream. That means, concurrent BPMS is extremely lack in something like 'Technical Abstraction' and 'Expression Extensibility'.