Thread safety in Java Collaborations

Of course, I want the JCD to be thread safe, if indeed there would be multiple threads executing in the JCD instance. That is the essence of my question.

If I understand your response, the JCD instance could be multithreading if it is processing more than one request. Then, my question is - under which scenarios would a JCD instance be certain to process only one request - single threaded, and which scenarios would the JCD instance possibly process multiple requests - multithreaded.

For example, if my JCD implements an existing web service - a JMS receive - is it possible for it to be processing more than one request at a time? What if the connectivity map had more than one instance of the same JCD consuming messages from a common queue either in serial mode or connection consumer mode? Or, what if the JCD was invoked by a Business Process?

Thanks for your reply.

Message was edited by:

AKsuited

AKsuited at 2007-7-7 >

The implementation is a bit more complex then this. When you create a JCD that implements an existing web service (ie a JCD that is started by a connector), eDesigner will create a message driven bean that is triggered by the connector and a stateless session bean that will be called from the message driven bean. This stateless session bean will call your JCD web service method, the receive or the start method.

Because your JCD is hosted in a stateless session bean it will receive all the benefits of the J2EE thread and instance management. If there are multiple JMS messages to process, the application server can create multiple instances of the stateless session bean that hosts your JCd and thereby multiple instances of your JCD class will be created. If these are no longer needed, the application server can destroy them. As stateless session beans are thread safe, you do not need to code your JCD's in a thread safe manner. Of course if you want to access static resources or use singletons then you will need to access these in a threda safe manner from the JCD.

When you JCD's are started by a JMS message (this is when your JCD's implement the JMS receive web service), you can configure in the connectivity map how many instances of your JCD can be started concurrently by the application server. When double clicking the configuration block on the JMS inbound connection you can specify two options:

- Connection Consumer or Serial mode: multiple instances can be started when multiple messages are available or not.

- Server session pool size: how many instances can be created.

Frederik@NL at 2007-7-7 >

If your message is implementing a new web service instead of an existing web service, it will still be hosted by a stateless session bean. However, because it will not be triggered by a connector, no message driven bean will be generated.

If you Java collaboration is exposed as an external callable web service, the stateless session bean will be called by the servlet, if your collaboration is called from en eInsight business process, the stateless session bean will be called by a message driven bean that is triggered from the eInsight BPEL engine. The eInsight BPEL engine is implemented as a JCA connector and a single message driven bean exists to allow it to call Java collaborations. This message driven bean is not generated when you define a new java collaboration but is predefined and linked to the eInsight engine.

Regards,

Frederik

Frederik@NL at 2007-7-7 >

Hello,

It seems it is not possible ? It is a pity because when building a composite application taking data from backend systems via web services (this is the famous SOA buzz...) you would expect a possibility to call the web services in parallel to ensure scalability....

The only options I have seen so far are:

- using a BP

- using the http inbound eway (not a "true" web service then)

Any other idea's ?

Thanks

Nicolas

Degroof at 2007-7-7 >