I'm very new at WSO2 stack and wonder when I should use WSO2 ESB proxy service and when – create business process via BPEL?
I think they are doing the same thing – performing a task via services composition and some mediation.
There is a fundamental difference between ESB and BPEL.
The role of ESB is to provide various non-functional properties to the business requests. ESB is thus used for e.g. mediation, transformation, security and virtualization/proxying of the requests. While it can do some simple message-enrichment using sequence diagrams, its primary purpose is to mediate messages between various services/hosts in the system.
On the other hand, BPEL is dedicated to implement business services and handle complex business workloads. Therefore, the role of the BPEL is to provide the functional properties to the business process- e.g. implementing the actual business process logic.
ESB and BPEL thus together deliver the separation-of-concerns which is often emphasized by component and service-oriented architectures.
If you have a well defined long running Business process you need to use WSO2 BPS. You can use WSO2 ESB for short spanning process with a shorter life cycle. WSO2 BPS has many integration points that you can control the Business process with features such as Human Tasks. On the other hand ESB has the capabilities but it may not be convenient and optimized as BPS for the long running well defined business processes.
Related
In developing backend components, I need to decide how these components will interact and communicate with each other. In particular, I need to decide whether it is better to use (RESTful, micro) web services versus a message broker (e.g. RabbitMQ). Are there certain criteria to help decide between using web services for each component versus messaging?
Eranda covered some of this in his answer, but I think three of the key drivers are:
Are you modeling a Request-Response type interaction?
Can your interaction be asynchronous?
How much knowledge does the sender of the information need to have about the recipients?
It is possible to do Request-Response type interactions with an asynchronous messaging infrastructure but it adds significantly to the complexity, so generally Request-Response type interactions (i.e. does the sender need some data returned from the recipient) are more easily modeled as RPC/REST interactions.
If your interaction can be asynchronous then it is possible to implement this using a REST interaction but it may scale better if you use a fire and forget messaging type interaction.
An asynchronous messaging interaction will also be much more appropriate if the provider of the information doesn't care who is consuming the information. An information provider could be publishing information and new consumers of that information could be added to the system later without having to change the provider.
Web server and message broker have their own use cases. Web server used to host web services and the message broker are use to exchange messages between two points. If you need to deploy a web service then you have to use a web server, where you can process that message and send back a response. Now let's think that you need to have publisher/subscriber pattern or/and reliable messaging between any two nodes, between two servers, between client and server, or server and client, that's where the message broker comes into the picture where you can use a message broker in the middle of two nodes to achieve it. Using message broker gives you the reliability but you have to pay it with the performance. So the components you should use depends on your use case though there are multiple options available.
We have a system using EJB 3 Stateless bean which is also exposed as web service.
There's a integration request from other team that want our system to fire a notification to other system after invocation (by web services or other means). Since this is not totally related to our system I would prefer to have this feature loosely coupled with our own system instead of hard coding these features in to our system code.
Is there any feature on EJB or web services that can achieve what I desire? We would require a method level invocation listener so that when the EJB method/ web service get invoked, it can trigger a callback/message so we can do something according to it. I would expect it to be some kind of annotation/configuration for setting up JMS or something.
We are using JBoss as the application server. If there's any JBoss specific solution it's also welcomed.
I would suggest two options:
use JMS. When you mentioned loose coupling, JMS first crossed my mind - you can put a message on some queue/topic after method invocation and let the listener to perform futher actions. JMS messages can carry various kinds of objects - the only request is that class implements Serializable (ObjectMessage#setObject); other advantage is that you can (un)deploy your Stateless bean and other system independently. They can be on different JVMs.
use Interceptors. Technically, they would be invoked before your methods runs, but of course there is always some nice workaround :-) Here is the official documentation about Interceptors, but since you mentioned that you're using JBoss, there can be also found some interesting material on JBoss pages.
SOA is about integrating heterogeneous applications or composing business processes from lower level services.
Can we realize complete SOA solution in a large enterprise where applications cross departmental and ownership boundaries using only state of the art JMS provider that supports both Java and non-Java JMS clients and using web services and application servers at various integrations points if needed without using more complex ESB product?
Integration architect with good industry experience can best answer this question.
Yes - an ESB is not necessary to implement SOA.
Preferably, use Web Services over JMS for implementing your services.
Some issues that are commonly addressed by ESB, that you should be aware of:
Adapters
When using legacy service provider or client that don't support the relevant technologies (JMS, SOAP,...) the ESB can act a an adapter for them - in your case all you services and clients should support these technologies them self, or you'll need to implement an adapter.
Routing
The ESB acts as a router, hiding the physical address of the service provider.
you should use a strict Queue \ Topic naming convention to ensure consistency and maintainability of your solution.
consider coexistence of multiple environments and versions when planing the naming scheme.
Service Registry
You should have some kind of registry with the specs of all services.
some issues that are not easily supported are
Content Based Routing
Central Logging \ Policy enforcement \ Auditing
In addition to what is in Ophir's answer:
Your question translates as, "can JMS be used for wiring?" Yes, it can be.
SOAP - the crux of many an SOA solutions - is inherently a messaging protocol. This allows an asynchronous solution, and hence JMS fits the bill. SOAP needs to run on another session/application-layer protocol, which JMS can be.
Envisage the solution as following:
Service providers listen on a JMS bus, possibly a specific queue/queue+message selector
Service consumers post messages on the JMS bus, addressing the service they need (particular queue)
The response varies based on the requirement, typically a separate queue for response (possibly specified in the JMS reply-to property,) to which the consumer listens to for responses.
In essence, the service port is a JMS queue.
Being a beginner, how should I go about deciding if a particular process has to implemented as ESB or as BPEL ?
What are the various parameters that one should use for deciding if either should be used for implementation?
First of all ESB is just a concept while BPEL is an OASIS standard based on XML and Web Services. A BPEL file is actually XML.
You use an ESB when you need to connect 2 or more applications together, to avoid direct point-to-point integration. This offers various benefits, such as translating messages from one format to another, or introducing other message exchange patterns. An ESB's communication is typically stateless, i.e. a message goes through, gets routed to its destination(s), and it ends there. An ESB is a very broad term, interpreted and misinterpreted by vendors to market their products.
A Business Process Management system implementing BPEL and similar technologies on the other hand are concerned with keeping track of the progress of various activities and their relationship. A BPEL process is very similar to a flow chart. A BPEL process preserves state, keeps track of its progress and flow, and is typically used (although not necessarily) in long-winded transactions which could also involve manual human tasks.
A textbook example of a BPEL process is a loan processing application. A request for a customer loan comes in, and the process first performs some automated checks using web service calls on some systems and if the credit rating is too low, the system informs a manager to evaluate the form manually (via some workflow system). The process then waits for a callback from the human workflow system, uses some correlation method (some ID) to match it with the right BPEL process instance (so that the right customer is serviced), and resumes the process accordingly.
ESB from my experience are always for processes that do not include a wait state. When you are just going through a list of services and will get to point a to point b without any pause states, I would use an ESB. ESBs also can handle higher quantities of message requests.
Any time human interaction is involved(Entering values, Review submission), I lean towards implementing this in a BPM. These tend to have more robust handling of long periods of waiting.
There are several questions you need to ask yourself when making the choice between ESB and BPEL. Among the most important:
- am I dealing with a stateless process (then I choose ESB) or a stateful one (so I choose BPEL)
- do I need to handle a large volume of short messages - in this case I choose ESB
- do I need orchestration of business processes - then I use BPEL
Here you have a good resource for your question:
http://www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html
This question already has answers here:
JMS vs Webservices
(9 answers)
Closed 7 years ago.
I need to develop a system which accepts orders and returns confirmation. Orders could come from java or non java clients.
Not sure whether to go for web service implementation or JMS.
Any suggestions ...
JMS is an API which abstracts messaging middleware, like ActiveMQ or IBM MQSeries.
Messaging middleware has a store-and-forward paradigm and asynchronous message passing, while web services tend to promote a synchronous procedure calling paradigm. In distributed systems where a lot can go wrong, dealing with things asynchronously tend to focus the mind better to the things you need to do when part of the system is not available or poorly performing and the code needed to deal with that tends to be a lot less complicated.
Clustering parts become trivial if you have multiple servers listening on the same queue, parallelism and load balancing is for free in this case.
Personally I find JMS much easier to work with and more robust and reliable than web services, but the messaging middleware must support all platforms you want to use. If all the components who need to talk to each other are under your control, I would give a messaging middleware with a JMS interface serious consideration.
If the other party is external then probably Web Services rule, and in that case you could think of a using thin layer to convert the external web service to an internal message passing infrastructure so you still have the most of the advantages.
If it is "just slapping an remote API on a webapp" then of course it does not pay either to setup asynch messaging.
You can use both depending on your interoperability, scale, distribution and integration requirements.
Web service approaches utilising SOAP, XML RPC and REST provide something quite interoperable given the use of HTTP as the protocol. From a service side, you might receive a web service request and then marshal it into a message. Your message could then be delivered to a messaging bus.
JMS is a reasonable API for interfacing with a messaging bus and I've found that Active/MQ very good here. Active/MQ supports JMS across many languages.
With messaging you can utilise the Request/Reply Enterprise Integration Pattern to receive responses and return them via your web service. However think about the merit of providing immediate feedback as to whether the order has been processed vs feeding back the fact that an order has been received; you might not need to implement request/reply to acknowledge that an order has been received.
The benefits of messaging can be found here: http://www.eaipatterns.com/Messaging.html
You may even want to look at Apache Camel to simplify the development of highly scalable and distributed service layers.
check the links
difference between using JMS/Messaging Middleware versus Web services
Messaging, JMS and Web Services
Web Services HTTP vs. JMS
Choosing among JCA, JMS, and Web services
Java Message Service
Web service
So if communicating Applications are Java based use JMS and if may be different then Web services... thats what which I follow.
For interoperability sake, use a web service. JMS is little used outside the Java world.