What is difference between Asynchronous vs synchronous messaging (java) and how does it impact way in which messaging sender / receiver is implemented.
how does a J2EE architecture decides to choose either.
The Sun J2EE Blueprints cover this.
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/eis-tier/eis-tier4.html
This particular article discusses interoperability with an EIS, but the principles are the same when using it for your own applications.
Related
Can I use SOA and three-tier in one application? Using SOAP to connect for external services, using MQ and Spring MVC. I have an application server and server for the database.
Yes, it seems that they are very different things.
There is a vast array of different SOA implementation styles, you can do it in so many ways. One is to have services talking to APIs over http where the APIs in question are written in a 3 tier style.
You can also have an event driven architecture where messages are passed on a message bus or a queue or some sort, the services reading and writing to those queues can be written in a three-tier style.
To sum up yes you can have SOA and three-tier in the same architectural solution, one does not exclude the other.
Does this help your decision on how to structure your service design and how to structure the wider solution architecture?
they have many common features. but how the difference?
MOM allow asynchronous while SOA does not, this is the only difference?
SOA, Service Oriented Architecture, is an architecture that defines how to structure access to business information between different applications. In a nutshell, usually, one application needs something done with a piece of information (may it be an orderfile or anything else) that application has a need. Another application may be able to do the corresponding processing of that piece of information, hence it has a capability. The first application then Consumes the Service of the second application, which Provides the Service (no matter the underlying technology, which can be anything such as JMS, HTTP/SOAP, HTTP/REST, EMail, FTP, etc.). To make this work, a Contract between the first application and the Service has to be defined which clears such things out as Message Format (XSD or similar), Protocol (HTTP/SOAP? JMS?) etc.
MOM, Message Oriented Middleware, on the other hand is just a family of software/middleware platforms. They are actual implementations, and not a high-level concept like SOA. They can be used to implement a SOA architecture, an Event Driven architecture or other architectures. Usually, MOM enriches a set of applications with asynchronous messaging where a MOM server stores and forwards the messages. Often things such as transactions, guranteed delivery, fail-over, loose coupling and load balancing are built into MOM implementations. Examples of MOM are IBM WebSphere MQ, Apache ActiveMQ, RabbitMQ, JBoss HornetQ, etc.
Message oriented middleware (MOM) is a type of technology where as SOA is a type of architecture. Even though a lot of people think about web-service when they talk about SOA, you can use MOM to implement it as well (in fact in many cases that's the better option)
Can we safely say that if ESB provides Orchestration features, it is eligible to be an implementation of BPM?
I understand that BPM has a different purpose, which is to Model some business processes and the implementation of those business processes can be done by any simple Java/J2EE application, complex SOA application, or some application saying that I provide BPM. Is that right?
First Question:
Your statement is valid for some business processes which merely models request-response interaction.
But when it comes to complex business processes we need to consider some other features apart from orchestration features. Here I have list down few such scenarios.
Let's take a business process which requires to maintain its state for a long period of time. We normally call them state-ful or long running business processes. To support these sort of business processes, there should be a state persistence mechanism. This functionality is not relevant to orchestration features.
Consider a business process, which requires some compensation capabilities. In that case, some of the business process modelling standards like, WS-BPEL have defined its compensation mechanisms. So apart from orchestration features, there are some other features which are needed to be considered.
Second Question:
Yes. But there are several pros in a BPM engine compared to your mentioned implementation mechanisms.
One advantage is, it's not possible to achieve a level of modelling abstraction provided by a BPM engine from a Java application. Let's say we used a JAVA application to implement a business process logic and that business process went to production. Say we need to change a endpoint URL of its partner service. In this case, now the business process implementation need to be modified, re-compiled and deployed back into the production system. if we implement the business process with a business process language standard like WS-BPEL, we can change the business process configuration very easily and push it back to the production. This improves the efficiency and reduce the business maintenance cost.
As well there are other reasons like easy adaptability and flexibility.
I've created these slides some time ago to explains exactly how you can use them both and the relationships between them:
http://www.slideshare.net/salaboy/jbpm5-community-training-module-25-bpm-for-developers
You need to understand the different perspective between something like BPEL/ESB/Orchestration and BPMN (business oriented) they have very different scopes.
Cheers
Normally ESB is assigned to the middle layer — orchestrating low-level services into larger service units, which will be exposed to the business for use in processes — and BPMs in the top layer.
So BPM will be used in the Business Process Orchestration Layer and ESB will enable and facilitate this by working in the Business Services and Service Enablement.
In another words to be successful with business processes first you need to have all your systems and apps exposed as services; that is where an ESB comes into play.
You could see this link : http://blogs.mulesoft.org/why-bpm-and-esb-need-to-work-together/
Let me add clarity by making the distinction between BPM, Orchestration, and ESB, via design patterns and specifications.
Generally speaking, "Orchestration" has been defined as a compound pattern employing the Process Abstraction, Process Centralization, and the State Repository design patterns. By virtue of the implementation of the State Repository Pattern and contrary to a previous post, Orchestration supports long running, synchronous business processes, just like BPM.
The major practical distinction between the 2 is that Orchestration middleware (e.g. WebSphere Process Server, BizTalk, Oracle BPEL Manager, and Windows Workflow Foundation) supports most of the WS * specifications. This includes Ws BPEL, Ws Security, Ws Atomic Transaction, Ws Business Activity, Ws Reliable Messaging, etc., while most BPM Tools do not.
As a result, feel free to use Orchestration at an Enterprise Level, but be very careful about using BPM in that scope.
In practice, both BPM and Orchestration tools enable the graphical representation of a business process. The distinction is that Orchestration may be expressed through Vendor-Neutral BPEL (Business Process Execution Language), while BPM is expressed via Vendor Specific BPMN (Business Process Modeling Notation). This is another reason to avoid BPM tools at the SOA/Enterprise Level.
In cases where a BPM Tool implements the Ws * specifications, it is an Orchestration Engine for all practical purposes. The distinction again being that BPM tools rely on Vendor-Specific BPMN and Orchestration tools rely on Vendor-Neutral BPEL.
In cases where both BPM and Orchestration need to coexist, limit BPM to application architecture (e.g. MVC style) and let Orchestration promote the sharing of enterprise assets.
An ESB is an entirely different animal. It should used for asynchronous, rather than synchronous processes and relies on a different set of design patterns (i.e. Service Broker, Asynchronous Queuing, Intermediate Routing, and the Content Enricher patterns)
What's the difference between an RPC System, like Twitter's Finagle, and an Enterprise Service Bus, like Mule? What kind of problems are each of them good at solving?
I will try to answer this as a soft explanation, rather than a technical breakdown of features:
One may say that Finagle is a asynchronous messaging library that allows services to connect to one another freely (not tightly tied to architectural system integration standards) while supporting multiple protocols.
From the Finagle website:
Finagle is a network stack for the JVM that you can use to build asynchronous Remote Procedure Call (RPC) clients and servers in Java, Scala, or any JVM-hosted language. Finagle provides a rich set of protocol-independent tools.
An enterprise service bus (ESB), on the other hand, is a asynchronous messaging architecture which typically adheres to industry standards and protocols. An ESB promotes a system where message flow is controlled and routed between systems, and where servers can register their service and clients can register what messages they are interested in. The services offered by servers can be registered and versioned.
You will typically find Finagle being used somewhere between a website and backend services. But, you will typically find an ESB inside a large corporate, where it's responsible to integrating systems like finance, support, sales, etc.
Both solutions offer asynchronous messaging and buffering to various extends, but are not designed to solve the same problem. For ESB, you would probably think 'strict, enterprise', but for Finagle you would probably think 'flexible, web'.
Hope this helps
Update:
Not quite related, but if you are exploring this space, I would look at Kafka these days.
RPC and ESB are two architectural patterns. While RPC is usually a request-reply and synchronous in nature, an ESB works on the concept of messaging (simplified explanation) and of asynchronous in nature. ESB is the foundation for any SOA implementation. ESB enables loose coupling thus promoting true agility. A simplified example from implementation perspective is as follows:
A web service is a typical RPC. The consumer is tightly bound to the producer and any change in the contract on the producer side, will require changes on the consumer side.
In ESB, the service consumer doesn't invoke the service producer directly. It just puts the message in the bus and based on the rules (mediator), appropriate service producer will handle it. If the service consumer and service producer talk in different formats, ESB provides the facility to do the transformation (like formatting the zipcode as xxxxx-xxxx, splitting the name into first name and last name, etc.).
This is just simplified explanation. For more information, please check the following links:
Why do developers need an Enterprise Service Bus?
Enterprise Service Bus
Both solve completely different problems:
An ESB is an intermediation middleware that provides message transformation and routing, protocol adaptation and other value-add operations (like orchestration, guaranteed delivery, idempotent filtering...). It sits in-between your service consumers and providers and transparently (ie without any change in consumer or provider) provides its different features.
An RPC system provides client and server technologies for performing RPC operations.
I have been researching asynchronous messaging, and I like the way it elegantly deals with some problems within certain domains and how it makes domain concepts more explicit. But is it a viable pattern for general domain-driven development (at least in the service/application/controller layer), or is the design overhead such that it should be restricted to SOA-based scenarios, like remote services and distributed processing?
Great question :). The main problem with asynchronous messaging is that when folks use procedural or object oriented languages, working in an asynchronous or event based manner is often quite tricky and complex and hard for the programmer to read & understand. Business logic is often way simpler if its built in a kinda synchronous manner - invoking methods and getting results immediately etc :).
My rule of thumb is generally to try use simpler synchronous programming models at the micro level for business logic; then use asynchrony and SEDA at the macro level.
For example submitting a purchase order might just write a message to a message queue; but the processing of the purchase order might require 10 different steps all being asynchronous and parallel in a high performance distributed system with many concurrent processes & threads processing individual steps in parallel. So the macro level wiring is based on a SEDA kind of approach - but at the micro level the code for the individual 10 steps could be written mostly in a synchronous programming style.
Like so many architecture and design questions, the answer is "it depends".
In my experience, the strength of asynchronous messaging has been in the loose coupling it brings to a design. The coupling can be in:
Time - Requests can be handled asynchronously, helping overall scalability.
Space - As you point out, allowing for distributed processing in a more robust way than many synchronous designs.
Technology - Messages and queues are one way to bridge technology differences.
Remember that messages and queues are an abstraction that can have a variety of implementations. You don't necessarily need to use a JMS-compliant, transactional, high-performance messaging framework. Implemented correctly, a table in a relational database can act as a queue with the rows as messages. I've seen both approaches used to great effect.
I agree with #BradS too BTW
BTW here's a way of hiding the middleware from your business logic while still getting the benefits of loose coupling & SEDA - while being able to easily switch between a variety of different middleware technology - from in memory SEDA to JMS to AMQP to JavaSpaces to database, files or FTP etc