JBoss EJB 3.0 Preview 4 has been released. Other than a bunch of bug fixes, we extended EJB 3.0 with a few new features. We're extremely interested in feedback to know if these features are useful and if they are submittable to the EJB 3.0 (or 3.1) specification. Specifically, the new extensions are:

• @Service EJBs Singleton EJBs that can hold stand and are multi threaded. As was as being able to publish traditional @Local/@Remote interfaces, they can also publish JMX @Management interfaces and hook into JBoss lifecycle and dependency injection.
• Message Driven POJOs These are Message Driven Beans with a typed producer and consumer interfaces. Work with JMS through regular business method calls
• Lightweight Asynchronous EJBs Any EJB reference can be transformed into an asynchronous proxy where you can invoke on methods and receive responses asynchronously. No changes to bean class or bean interfaces required.

For more information:

Visit the main JBoss EJB 3.0 site
View our Release Notes

I think @Service EJB is what I missed the most in the previous EJB specifications. As there will be only one @Service instance in the cluster(?) and as some services must be synchronized to allow execution by one client at a time I think this is very good idea. The question is: will using of java synchronization on the service be allowed?

I think @Service EJB is what I missed the most in the previous EJB specifications. As there will be only one @Service instance in the cluster(?) and as some services must be synchronized to allow execution by one client at a time I think this is very good idea. The question is: will using of java synchronization on the service be allowed?

JBoss has something called an HASingleton service where there is only one instance allowed in the entire cluster. We want to make this available for the new @Service EJB type. So, if you annotated with @Servie and @Cluster it will be a singleton across the cluster.

@Service
@Clustered
public class MyService implements MyServiceRemote {
}

That's nice, Bill. I like the design; very clean.

It will be important for you to update your docs to be clear that @service creates a singleton per VM and that @clustered is needed for a HA singleton. Most people will ask this question, so anywhere you reference one of these tags, just add the standard phrase to clarify.

Tyler

JBoss has something called an HASingleton service where there is only one instance allowed in the entire cluster. We want to make this available for the new @Service EJB type. So, if you annotated with @Servie and @Cluster it will be a singleton across the cluster.@Service@Clusteredpublic class MyService implements MyServiceRemote {}

It's very nice. It would be even nicer if it became a part of EJB3 official specs. Is there any chance it will?

JBoss has something called an HASingleton service where there is only one instance allowed in the entire cluster. We want to make this available for the new @Service EJB type. So, if you annotated with @Servie and @Cluster it will be a singleton across the cluster.@Service@Clusteredpublic class MyService implements MyServiceRemote {}

It's very nice. It would be even nicer if it became a part of EJB3 official specs. Is there any chance it will?

It is probably too late for EJB 3.0 since we're closing in on a public draft for JavaOne.

Sorry if I don't get the point, but what's the real difference of @Service EJB to having a RMI-Server on one of the server nodes in the cluster ? (That's not meant as a criticism, I really don't understand it ;) )

Probably it's the container who makes your RMI server up on the other node after the failure of the previous cluster node.

I am always a bit confused by these JBoss announcements... Introducing non-standard extensions at the same time as you are releasing a preview of the new standard (which is still just a draft) is kind of perplexing.

I'd like to use JBoss as "the in-progress reference implementation" for EJB 3, but it seems like you're deviating from the spec before you finished implementing it.

That said, your extensions seem pretty cool.

Another approach:

http://www.tangosol.net/forums/thread.jspa?forumID=6&threadID=82&messageID=140

Basically, the pattern we've suggested makes the state clustered and lets the "service" (the functionality) operate anywhere in the cluster.

The difference is kind of like having a thread-safe class versus making your function calls somehow switch threads to a particular thread so that the class doesn't have to be thread-safe.

Thoughts?

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Here is an example code.
http://radio.weblogs.com/0135826/2005/01/17.html#a113
Would this work on jBoss3?
.V

How will this work with dynamic datasources? In the project I am working on the datasource is tied to the user, each company having its own datasource.

Hi John, I am having very similar situation where verious user from "Branch office" has their own database but accessing a single JSF-EJB3-MySql application at "Head Office". So is there any way you found out by which application can invoke datasource dynamically at runtime based on logged in user's branch ? Thanks in advance, Pragun.