Can we realize complete SOA based solution using only JMS provider?

1
votes

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.

2
web-servicesjmssoaesb

2 Answers

2
votes

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

2
votes

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:

  1. Service providers listen on a JMS bus, possibly a specific queue/queue+message selector
  2. Service consumers post messages on the JMS bus, addressing the service they need (particular queue)
  3. 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.