What's the difference between ActivationSpec and ConnectionFactory?
Asked Answered
R

3

20

My understanding is that:

  • MDBs (Message Driven Beans) connect via Activation Specification.
  • MDPs (Message Driven POJO) connect via Connection Factory.

This diagram from IBM is helpful:

enter image description here

To me, this explanation from IBM does not shed much light on the difference:

  • Connection factory -- used by the application to get connections to the messaging bus.
  • Queue -- used by the application to send and receive messages.
  • Activation specification -- used by the application's message-driven bean to connect to the queue and receive messages.

One real difference I have found is that:

Session beans and entity beans [aka MDPs] allow you to send JMS messages and to receive them synchronously, but not asynchronously. To avoid tying up server resources, you may prefer not to use blocking synchronous receives in a server-side component. To receive messages asynchronously, use a message-driven bean [MDB].

So the unsatisfying list I have so far is:

  • Use ActivationSpec with an MDB and ConnectionFactory with a POJO (but wait, can POJOs use ActivationSpec too ?)
  • MDB's operate asynchronously. MBP's operate synchronously.

My question is: Are there other differences? Can you clarify the difference ?

References:

Rendon answered 12/9, 2011 at 15:28 Comment(0)
T
15

@Jeffrey Knight: Let me try to clarify based on my experience.

We understand MDB are beans to consume incoming messages. Now there is need to specify what kind of messages, from which destination a particular MDB wants to consume to.

MDB is basically a message end point.

Prior to JCA compliant MDBs:

flow in websphere was :-

incoming message --> listened by Message listener --> listener ports-->deliver to MDB

So typically a developer would create a MDB and specify message destination details in ejb-jar.xml as follows:-

<message-driven-destination>
    <destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
<res-ref-name>jms/QCF</res-ref-name>
<resource-ref>
    <res-type>javax.jms.QueueConnectionFactory</res-type>
    <res-auth>Container</res-auth>
</resource-ref>

and a deployer would need to create listener port and associate deployed MDB to the listener port. QueueConnectionFactory specified above is made to create connections to queue.

Post JCA compliant MDBs:

Post JCA, MDB is treated as a JCA resource. JCA specification incorporated messaging framework APIs as well. Flow in case of JCA is:-

incoming message --> listened by Message listener --> Resource Adapter-->deliver to MDB

Now since JCA was created to work with any type of resouce be it JDBC, JMS, EIS etc, so it has a generic "Activation Spec" way of creating configurations for any adapter. In ra.xml file, it is mentioned what kind of activation spec is needed by that particular adapter to work. Activation spec is not a runtime entity, it is just a configuration details used by resource adapter. In above case JCA adapter will use connection from queue connection factory mentioned in activation spec. So basically queue connection factory in above both cases are same.

In case of websphere, you can use either SIB (Service Integration Bus) destinations for messaging OR external software like websphere MQ for messaging.

In case of SIB destinations for messaging :- SIB has implemented a JCA resource adapter. So MDB using destination on SIB can use activation spec to specify destination details. and resource adapter module can interact with messaging engine and can deliver the messages to MDB.

In case of external messaging framework like websphere MQ:- Since websphere MQ has not implemented any JCA adapter, so we will need to configure listener port to connect to destinations residing on websphere MQ. It is listener port who will deliver the messages to MDB.

In short, both cases use queue connection factory to get queue connection. In one case, it is resource adapter (with configuration information in form of activation spec) used to deliver messages where as in other case it is listener port (bound to queue & factory) used to deliver messages.

I hope this clarifies now.

Theophylline answered 14/9, 2011 at 7:48 Comment(1)
WebSphere Application Server v7 allows creating an activation specification using the WebSphere MQ messaging provider.Shifrah
N
12

They are both configurations, but connection factory is used for outbound message and activation specifications is used for inbound messaging.

This is what I've got from IBM.

Activation specifications are part of the JCA 1.5 specification. The MDB application uses the activation specification to connect to a WebSphere MQ queue manager for the processing of inbound messages. The activation specification also provides other options, such as security settings.

A JMS connection factory contains information about how to create a connection. When an application needs a JMS connection, the factory creates a connection instance. The connection factory requires the same connection information as the activation specification that you created earlier, but is used for outbound messages from the MDB, whereas the activation specification is used for inbound messages.

Nimiety answered 20/11, 2012 at 6:42 Comment(0)
N
2

The client of a ConnectionFactory is the application. The application uses the ConnectionFactory to push/pull messages to/from the messaging engine via a Queue.

The client of an ActivationSpec is the EJB container. The EJB container obtains an ActivationSpec to register a MessageEndpointFactory for the MDB or MDP with a ResourceAdapter. When a client pushes a message to the messaging engine, the messaging engine will use the registered MessageEndpointFactory to forward the message to the application (e.g., the MDB or MDP). This allows the application to "asynchronously" receive messages rather than requiring the client to poll or block trying to pull a message from the Queue.

Nose answered 13/9, 2011 at 15:11 Comment(1)
Yes, you're right, I confused myself. I updated the answer to hopefully be clearer. Thanks.Nose

© 2022 - 2024 — McMap. All rights reserved.