CODEWITHSUNDEEP
javaarchitecturesoaapache-camelesb
IAmYourFaja
IAmYourFaja

Reputation: 56904

Where do EJB3s fit in with SOA/EIP?

My (perhaps all-too-simple) understanding of EJB3 is that its a way of turning a POJO into a Java EE-compliant unit of business logic. It is reusable and can be "plugged in" to different backend architectures spanning multiple projects. It's a step in the direction of true component-driven architectures. If any of these assertions are untrue, please begin by correcting me!!

If I am correct on these items, then I'm wondering how/where/when/if EJB3s snap into an ESB like Apache Camel. With Camel each endpoint typically implements some EIP like WireTap, Filter, or Transformer. I'm wondering which of these EIP/SOA patterns the EJB (specifically EJB3) fits into. Is it a simple Filter? Something else?

I guess at the root of my question is this:

Upvotes: 1

Views: 507

Answers (3)

Viktor Stolbin
Viktor Stolbin

Reputation: 2939

In addition to previous answers I'd mention that SOA is rather approach with specified requirements than a concrete technology stack. Make your EJB3 beans or OSGI services be operable via network regardless to operations systems, platforms and languages at least and you will have service-oriented system. So EJBs and OSGI or Spring-powered applications do fit to SOA when they do fulfill its requirements.

Upvotes: 0

Christian Schneider
Christian Schneider

Reputation: 19606

Basically an EJB is a service. The idea behind a service is that it can simply be used without needing to create it as a consumer. Additionally services often can be looked up in a registry.

So my advice is to use the simple bean integration for cases where it is easy to instantiate the bean impl and to use services where it is difficult. So you can encapsulate the initialization inside the component that provides the service.

I am not using EJBs regularly but often use OSGi services which are very similar in concept to EJBs.

Upvotes: 1

Petter Nordlander
Petter Nordlander

Reputation: 22279

There is no right or wrong in this case.

EJB plugs very well into JavaEE application servers and are built to provide an architecture to encapsulate the business logic as Java code inside EJBs and let the application server handle scaling, throttling, fail over, clustering, load balancing etc, as well as exposure of the EJBs to communication protocols (Web Services or JMS for Message Driven Beans).

I see no real point in introducing EJBs as business logic containers in Apache Camel, unless you already have a full stack Java EE application that you want Camel to work with.

Camel has a great set of features to connect to "real" pojos through bean-binding.

I would recommend using simple java beans/pojos for business logic, and you can easily plug them in at any other application through camel's rich set of connectors. There are multiple options for implementing the different camel EIPs. One common way is with java code, but XSLT for transformations and groovy for filters is just as common. I would never use EJBs for simple filters, but rather invoke some complex logic inside a Java EE app. server, or typically avoid all together (except MDBs) and look at JMS communication with the application server instead.

Upvotes: 2

Related Questions