ESBs vs Services

Question

I am new to Java EE and have been struggling with some basic middleware concepts for several days now and believe that maybe I just had a breakthrough in my understanding of “how tings works”; part of this question is a request to confirm my conclusions, and another part is a legitimate question; -).

Confirm / Clarify: My understanding of service buses / MOMs (message-oriented middleware) is that they are inherently designed to asynchronously process client requests. This is in contrast to the usual request-response cycle, which is synchronous, which is usually implemented in some way. In Java, such a / MOM bus can be something like Apache Camel, and a synchronous service can be something like EJB (3). Therefore, if the client needs a processed request immediately, HttpRequest can go to the web service, which then redirects the request to the correct EJB; that EJB processes the message and returns the result to the service, which then returns the HttpResponse client. Thus, if the client has a request that does not block them and which just needs to be processed, the web service forwards its HttpRequest to some endpoint on the service bus, and the request is processed as a message and processed by various processors (filters, transformers, etc.) .d.).

So, please correct me if I am mistaken in stating that the 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 right.

In this case, it seems to me that for large applications, both types of backends will be required to process synchronous (blocking) and asynchronous (non-blocking) client requests. So my theory would be for my backend to run as follows:

• Use a full-blown application server such as JBoss or GlassFish.
• There are two ESB.war application server web container: WebServices.war and ESB.war ; which are the “gateway” of the firewall and service bus, respectively.
• In the business application container, all my EJBs
• WebService.war (gateway) can now determine whether to send a request to an ESB or EJB

My second question: I am here outside the base, and I missed the basic concepts of Middleware 101, or is this an approach halfway to the decent?

Edit: From the first answers, I already see that I was mistaken in two areas: (1) that ESBs and EJBs can be either synchronous or asynchronous, and (2) that when using MDBs, EJBs can be connected as ESBs.

Thus, this correction creates some new mental hurdles for me:

• When to go with an ESB, and when to go with an MDB / EJB solution; and
• I really like the Apache Camel Processors API (EIP implementation); can I use MDB / EJB, but inside each EJB just use the Camel processor ( Filter , WireTap , etc.)?

Answer 1

This is a big question, and it deserves a big answer.

An ESB can handle synchronous or asynchronous requests, and messages are typically used asynchronously.

However, your theory of backend implementation is pretty wrong.

JAX WS web services can run directly in the EJB or EAR bank and can do this on any application server. EJB can queue a message or even be asynchronous.

You should not forward requests to the ESB, but vice versa.

The ESB must relay and translate requests and responses between clients and the backend. One of the big ideas with the ESB is that if the backend changes the client, he does not know or care, as their contract with the ESB is not a backend.

All of this suggests that if your application already exposes web services, you probably don't need an ESB, and remember that there is no RIGHT or WRONG way to do something.

I suggest you write a more specific question that covers your specific problem, you will probably get a lot of tips on how to solve it.

UPDATE

You also get message-driven EJBs that really allow EJBs to connect together on the bus like a mod.

ADDITIONAL UPDATE

Thus, one scenario when I use the ESB is if I need to expose non-standards-based services on legacy systems as a SOAP service. However, keep in mind that you should also use a data dictionary for your organization, which will increase the likelihood that services open by the ESB may remain unchanged even if your old system is replaced.

So, as a concrete example, an organization should define in its data dictionary what a client object looks like, ESB can provide a service for retrieving a client. The ESB will make some calls based on an outdated system and then convert the result. If the backend system in which clients are stored is changed in the future, the open ESB service may remain the same, and you just need to update the backend call and conversion.

Now, hopefully, with that in mind, the next bit will make sense. All this is possible with the help of a "traditional" ESB, such as a JBoss ESB or Mule ESB, but it is also possible to use EJB + Camel (or other things).

The advantage of ESB is the presence of connectors, listeners and transformers. However, if none of the functions from the window help you, then there are very few differences in the direction you choose.

An advantage in the home development of your ESB would be ease of maintenance, it is much easier to find a resource that knows EJB well and can quickly learn Camel if necessary, than find a specialized ESB resource or train a resource.

I hope this helps!

Answer 2

As you already noticed, the middleware / integration world is a kind of mess in definitions and terminology. Let me clarify a bit.

Service is simply the concept of "something" that provides an opportunity. There are several ways to provide a service.

When referring to EJB below, I mean EJBs, except for MDBs (Message Driven Beans), which implement asynchronous message passing.

• Request / reply synchronously - where a response is expected "soon soon" after the request. Typically implemented through web services and EJBs (RMI, etc.).
• As a published message to several subscribers who consume data (usually price lists are pushed from the pricing system to various systems that require information, for example, to the order system).
• As a message about fire and forgetting from one application to another. As a rule, an order system needs to send an order to the invocing system, then the invocing system provides a service for creating invoices.

Conceptually, an ESB is a soft thing. This is a concept / agreement on how the company's business services should be exposed so that the company's applications can consume / use these services. It may just be a set of contraindications. "Only request / response services are allowed using SOAP / WebServices, and all messages must comply with the OAGIS XML standard." However, in most cases, the application / server / system environment in most companies is not uniform. There are COTS products, mainframes with COBOL applications, .NET applications, and Java EE applications. Therefore, the general approach is to use the ESB software package to implement the service bus in the technology or to create adapters for the bus. Apache Camel can be part of an ESB implementation for configuring routing, translation, conversion, etc.

One thing closely related to the ESB is the Message Oriented Middleware, which you are talking about well. This is usually a server that implements message queuing. The advantages of MOM are several, unlike EJB / Web services with direct invocation.

• If asynchronous templates (publish / subscribe, start and forget, asynchronous request / response), then the relay server, which has a high period of time and is very stable, will allow you to have less unsuccessful business message transfers.
• MOMs usually simplifies the implementation of adapters and ESBs, which are very robust for loading peaks, network interference, and hardware / software failures. Messages are often saved and saved to disk before relaying. Transactions are also often available, particularly in JMS-compatible implementations. This ensures that data is not lost in transit.

I hope I haven’t ruined things anymore than before. At least that's my opinion.