Most of the significant changes in the proposed final draft 2 of the EJB 2.0 spec involve the removal of dependent objects and the introduction of local interfaces. Tyler Jewell discusses local interfaces, their proposed implementation, and issues that developers may expect to encounter when dealing with this technology.
The article is available at: http://www.onjava.com/pub/a/onjava/2001/05/10/ejb.html
What are people thinking about Local interfaces?
How about best practices wrt using them?
The single biggest stumbling block I face at work when talking about the advances in 2.0 is "its not out yet - we can't base our next project on something that isn't out"... and basically the ears are turned off from then on. Never mind that I have EJB 2.0 beans running on Weblogic. So the big question I have is.... WHEN WHEN WHEN is this spec going to go live? Tyler's article says "...in the next couple of months". We're about to embark on what will become the cornerstone of the entire enterprise using 1.1 and it bothers me. IMHO the local/remote interface solution is simple and beautiful - so let's let it fly. There must be others in a similar predicament.
WebSphere has had some of the benefits of local interfaces for some time now. It includes an option that lets you turn off pass by value semantics in favour of pass by reference for local calls. This has had a favorable impact on performance in the past for local calls but programmers who coded expecting pass by value might have been surprised if this option was enabled.
Do anyone know if the other application servers have a similar feature and any experiences with it?
yah - both iPlanet and Weblogic have this as well.
Billy Newport wrote:
It includes an option that lets you turn off pass by value semantics in favour of pass by reference for local calls. This has had a favorable impact on performance in the past for local calls but programmers who coded expecting pass by value might have been surprised if this option was enabled.
Again, I ask, why can't application servers use optimized local calls, but keep remote semantics intact by making copies of data? Just with a little performance testing I can prove that the vast majority of the overhead caused in a remote invocation is in the marshalling, de-marshalling, transport, etc... Why make EJB more complicated by adding local interfaces into the mix? Why not just keep remote semantics (pass-by-value) but optimize the intra-vm calls into local calls?
They do but they copy the parameters to keep with the RMI spec. You have to remember also that all calls to EJBs when local go through the container so that it can manage pooling, security checks and transactions. If someone naively made all their classes session beans then performance would just suck something pretty aweful because of this overhead.
My normal approach is to only use EJBs for defining services. Most of the code is straight Java using the J2EE runtime infrastructure. I prefer to use just session beans as a facade for my business logic and an off the shelf OR mapper if applicable (i.e. the application suits it, most do not in my experience). I don't use entity beans as a rule because all calls go through the container and are therefore WAY too expensive. A normal OR mapper will not have this drawback and is just an easy to use and your application is actually more portable than if you used entity beans anyway as the OR mappers tend to be available for all J2EE servers where as the one that comes with your J2EE server is not (WebLogic/TopLink is an exception here). For example, with WebSphere, Persistence Builder (IBMs OR mapper) is a better product than WAS CMP at the moment. It have more tuning options and is more performant (no container coupled with preload paths etc).
If a business logic component is very heavy resource wise and could benefit from running on another box then making it a session bean makes sense from a distribution point of view but it needs to be very heavyweight for this approach to be worth the cost of the remote call and complexity that distributing it brings.
When you look at it like this, there isn't much difference in principle between MTS/COM+ and J2EE except for language choice (J2EE means stuck with Java, COM+ gives you a choice) and MTS/COM+ gives you no choice of server platform (must be W2K) where as J2EE gives you a choice. Product licensing wise, MTS/COM+ is just ridiculously cheap now, database, messaging, app server are basically given away by Microsoft. If you are concerned by the cost of J2EE then if you look at COM+ then you may just jump ship.
your approach of using only session beans as service providers and plain java objects as business domain objects in combination with an persistence framework (TopLink) was also my preferred architecture.
I planned (in a project) to group business use cases and place each group in an appropriate (service) session bean. Because I intend to offer exchangable business components being dynmically deployable I can do this only whith EJB-components, don't I ? How could I build components of plain Java object and (hot) deploy these non EJB-component in an appserver. With Weblogic 6.0 I have only the possibility to deploy EJB-components. If this is true then I can only dou this by wrapping these java components by fine grained session beans.
As I heard about local EJB interfaces I'm not sure to better
build my components by using local EJBs.
So the design should provide services (like yours) but flexible (local) components which are called in the service layer.
What is your opinion ?
The session beans are coupled with the normal Java objects they wrap. You could deploy the java objects with a dummy session bean for example as a workaround, just package the classes in the ear file.
Alternately, when the normal java business objects need to be updated then package them with the session beans wrapping them.
A couple of points. BEA already has an implementation of local interfaces ready to go in the NEAR future. I can't elaborate as to the exact date, but it's in lieu of upcoming product releases.
I think we could debate Toby's suggestion for a long time. I was personally in favor of an option where all methods remained remote and then the DD was used to indicate local/remote/both semantics. I think that would have been the easiest implementation.
However, the more and more that I give local interfaces some thought, I'm starting to like the way NEW EJB developers will react to them. By forcing new developers to places methods in a component interface or local interface, it will cause them to provide additional thought into their design and what actually will be occurring at runtime. I suspect that developers will ultimately end up with better designs initially than using the DD specification approach.
Of course, I know everyone will argue the fact that a component should ideally only have one business interface. Of course that's true and I'll just concede that point now. The more research that I do on local interfaces, however, the happier I get.
I, too, am very excited about getting my hands on an implementation. Trust me in that it will be sooner than later.
Playing devils advocate here but whats the advantage of local interfaces over the approach I outlined. Develop your bean as a straight Java bean with a normal rich fine interface. If it needs to be accessible remotely then make a session bean that ties or delegates to it. This seems equivalent for me and I avoid the need to involve the J2EE descriptors etc. Most beans/classes in an application are local ones. Any component interfaces will likely be a fascade wrapping the functionality of several 'local' ones. It seems like a poor fit, no, there doesn't appear to be a one to one mapping between local components and a distributed one.
Will EJB 2.0 local interfaces still apply security and transaction logic to each call or does that only apply to remote interfaces?
With "Local Interfaces" you will have the transactional control, object pooling, security, etc etc... all that stuff that EJb gives you. If you do not want that,
then it may be better to use the approach that you outlined right?
I have that with the session bean fronting my normal bean in any case, no? Given a lot of parameters are cheap to copy then the cost of going through the container for security, pooling and transactions is still significant. I can turn off the copying for local objects in any case in WebSphere and as indicated by someone else in WebLogic and iPlanet.
Maybe, Tyler can indicate some numbers for performance improvements but if this is the case then it appears to be hardly worth the effort.
This overhead of going through the container is mostly still there for the majority of calls and especially if we're caching data then thats still going to be significant enough to probably stop you using them in any case if you're really worried about performance.
Billy, I have the same concerns that you do. The specification (to me) is a little ambiguous as to whether or not local interface invocations can bypass transactional and security control. Obviously, by default, they'll have to have the same overhead as component interfaces -- I'm not fond of that at all.
Billy, I think the architecture that you lined out was perfectly fine as well. At this stage of my understanding of local interfaces, I'm only making guesses as to whether or not they'll truly work. I want to now observe 3-6 months of field implementation to get a better grasp of the limitations.
To tell you the truth, do we even need 6 months? Isn't it pretty obvious what the result will be? This is just due diligence but the answer is now clear.
Overall, I'm now pretty underawed with EJB 2.0. It appears all that we will get from it now are MessageBeans and the ability to officially support pass by reference calls.
Even the message beans are limiting. Whose idea was it to make them only stateless? What if I want to do in-order message consumption, why couldn't/wouldn't I use a stateful message bean for this. Pretty short sighted.
I dare anyone to respond and say that for in order messaging, stateless beans are more scalable, just stop, think about it, and smile.
It's a big assumption in the spec that people will only ever want out of order messaging. What about financial customers implementing reliable trade feeds, price feeds reference data feeds, I could go on and on (some people have said, I do go on and on but that's off topic).
The EJB 2.0 hype has already started, customers are saying when can I have it etc and you've gotta ask them, why? If a J2EE vendor adds a message bean container and JCA support what would you be missing?
It's hard to see the point of entity beans at all now. Get rid of them. Even products with competitive OR mappers (BEA) basically bugger portability by forcing everyone to use TopLinks API to really get the performance out of it so why both with entity beans at all. Just use TopLink standalone, it integrates find with JTA already.
CMP is inherently unportable between implementations as so much of what's needed is obviously outside the specification. Session Beans + TopLink is more portable than Entity beans + CMP between different servers.
Anyway, sorry for the rant, good weekend...
Overall, I'm now pretty underawed with EJB 2.0.
> It appears all that we will get from it now are
> MessageBeans and the ability to officially support
> pass by reference calls.
This is a very severe judgment on EJB 2.0, overlooking a lot of the good things that CMP 2.0 brings us. On top of my list would undoubtedly be relationships, which bean providers have been implementing manually since EJB 1.0.
Based on my reading of the newsgroups and some other various inputs, I can tell you that relationships have been incredibly well received by the community. And not just on a philosophical viewpoint: a lot of customers are using them and pushing them to uses we had never envisioned. Expect this trend to pick up in the next months.
> Even the message beans are limiting.
> Whose idea was it to make them only stateless?
I'm not sure arguing on this subject makes any sense. It's purely a matter of referential and definition. Ever since the initial implementations of "message buses" (such as Sun's Tooltalk, which I used to use in 1993 as part of my thesis), it's pretty much accepted that broadcasting to stateless targets makes perfect sense.
You are very welcome to note that this definition doesn't cover your needs, but I would tend to reply in that case that what you need is something different than messaging. To put it simply, I'll offer you a quick challenge: give me an example where anonymous message listeners are not enough for your need and I'll give you an alternate way to implement it.
> What if I want to do in-order message consumption,
> why couldn't/wouldn't I use a stateful message bean for this.
Okay, let's think this problem through. Obviously, you want to use Topics, since otherwise, a "stateful message-driven bean" (SMDB) listening to a Queue pretty much boils down to a stateful session bean. So you have a bunch of SMDB's subscribed to the same Topic and you want all of them to receive your messages.
This design only makes sense if all your SMDB have the same state. Why? Because otherwise you might react to identical messages with different treatments, and that would end up in chaos throughout your application. Here comes the main difficulty: messaging doesn't guarantee delivery of messages. You can judge this as a strengh or a weakness, but once again, that would be misguided: it is simply the definition of a message-oriented middleware.
Maybe now you can see why 1) listeners should be anonymous and 2) even so, it is perfectly possible to solve your problem, simply by having your listeners making calls to a Session or an Entity bean (thus guaranteeing the consistency that you can't have with SMDB's).
As a sidenote: the server might maintain the consistency of your SMDB's for you (we already do this through server cross-talk to implement stateful session replication throughout a cluster) but then you are faced with another problem: your SMDB's are going to receive requests for updates from two conflicting sources: your own messages and the server's. Which ones have precedence?
> It's a big assumption in the spec that people
> will only ever want out of order messaging.
Yet it is a fact of life. Denying it is similar to saying that UDP is absolutely useless because its definition states that "it is as reliable as its underlying medium".
Pretty much all protocols at all levels can usually be split between packets that can be lost and packets that can't. A quick example would be the packets that represent the successive coordinates of your mouse. Missing one is typically not a big problem and time has proven that failing to identify this need will lead to a poor implementation (in that particular case, you will need to acknowledge mouse packets and that will end up in sloppyness in responsivity).
Picking the right EJB is like choosing between TCP or UDP: a design decision that should be dictated solely by the semantics you need.
> CMP is inherently unportable between implementations
I'll leave this open for argumentation, but please keep in mind that there are a lot of users who don't need to port between implementations. And before you say it's unconceivable, think about all the customers who have bet all their business on Microsoft-only or IBM-only solutions.
Can anybody point me in the direction of a good example of how relationships are implemented in a EJB 1.1 BMP manner? Specifically demonstrating lazy loading of dependent objects ala Apple's Enterprise Objects EOFault,EOArrayFault concept.
Nice to see that this time you are being flamed for criticizing EJB :)
How's that for a change ?
Now to Cedric:
If you want to build here a bibliography that's very kind of you, but you can start by assuming that people like Billy know what they are talking about.
This is quite elementary; even if you want to flame people, at least you should be able to do it in a more subtle way.
As to your points, you're funny.
What if you only had UDP and instead of having TCP, you would have to write it yourself ?
Billy is right here, probably we need to have statefull message beans and ordered messages also.
Probably they were so preocupied to erase the "dependent objects" blunder that they didn't have time to consider message beans more carefully.
Now about local interfaces, certainly they are a progress, and I'm glad you're perfectly happy, but Entities have a long way to go before you can use them.
Especially those relationships you mentioned and the new kid on the query langiages block.
And from my point of view I don't see why would should stop at maximu 2 interfaces per EJB and we couldn't choose between 1 and n.
Like Microsoft had a very long time ago, and speaking about COM, some interfaces can be dedicated for collaboration between the bean and the infrastructure, just like in COM.
And if we are in the same process the ORB should shortcircuit the call, and if not he should marshall.
It's very simple.
If you want protection for your parameters, you can vote for introducing the "const" keyword in future versions of Java.
You can also have in/out/in-out parameters like in Corba and COM, if you really want a well thought middleware.
If you are perfectly happy with local interfaces, I'm ok with that, it's a good engineering compromise because they went on the wrong path with dependent objects and probably only had enough time to pick the easiest way at hand.
But it doesn't mean at all that they are the perfect solution.
This is quite elementary; even if you want to
> flame people, at least you should be able to
> do it in a more subtle way.
Flaming? Nothing in my message was inflammatory and I'm happy to see that Billy didn't see it this way either. I was merely addressing some of the interesting points he raised. Now, if your goal is to stir up controversy, please go ahead but I am not interested in taking part in discussions that are not purely technical (well, not on this forum anyway).
> Billy is right here, probably we need to
> have statefull message beans and ordered
> messages also.
I would very much like to hear a more substantiated response than "he is right". I provided a clear and detailed example why I think the approach he proposed was not 100% correct. Would you care to do the same with me?
> Probably they were so preocupied to erase the
> "dependent objects" blunder
Dependent objects are alive and kicking, they have simply been renamed Local Entity beans.
> that they didn't
> have time to consider message beans more carefully.
I don't remember you voicing your opinion when their specification was being debated on the EJB expert mailing-list. It's too late to do that now.
> And from my point of view I don't see why would
> should stop at maximu 2 interfaces per EJB and
> we couldn't choose between 1 and n.
Ah, finally an objective and interesting remark.
Would you mind elaborating on the virtues of having one EJB presenting N different interfaces as opposed to having N different EJB's? Maybe I'm missing something here.
> If you want protection for your parameters,
> you can vote for introducing the "const" keyword
> in future versions of Java.
That's very interesting but hardly beyond the reality of a JSR as of now. Customers are not interested in waiting for the Java language to be modified before their company can start making money.
> But it doesn't mean at all that they are the
> perfect solution.
100% agreed, but that's both the vice and virtue of a decision by committee: sometimes, it's not your opinion that prevails. And the funny side effect is that: sometimes, they are right and you are wrong.
Time will tell.
By flaming I meant when you send somebody to do the reading and after that he can comeback to discussion.
Now if you don't think dependent objects was a blunder, I'll tell you why they were a blunder.
Exactly because they were dependent , then we had to species of animals: EJB and dependent objects, and things will local interface had only to be dependent of something.
Now we're back to a unitary and simpler approach where everything is an Entity, except that A BMP cannot be in a "relationship" with a CMP , relationships can be directional, and semantics of relationship assignment proclaimed side effects as the way to go, when they could have simply settled for raisng an exception when relationships semantics were broken.
So we still have a way to go before EJB specification is something simple and unitary.
"I don't remember you voicing your opinion when their specification was being debated on the EJB expert mailing-list. "
I couldn't care less. I don't consider myself an EJB expert, and particularly I don't consider that anyone can be an EJB expert at this time. If there were "EJB experts" indeed, EJBs should have been something mature and robust after more than two years in the public.
"Would you mind elaborating on the virtues of having one EJB presenting N different interfaces as opposed to having N different EJB's? Maybe I'm missing something here. "
Yes, you're missing. If you want to make N different beans you will work very hard to make them the same logical object, and I'm not sure if it is at all possible.
The "const" keyword is not a JSR, but you and anybody else who reads this thread, can take the trouble to vote for the RFE at the Sun developer connection Bug Parade.
And it is something that we're missing in Java more then we miss any other particular JSR out there.
Not to mention that you could also vote for the Generic type support, which is also something far more important for developers then any JSR we have at the moment.
You can find them at
Interesting debate. I have just two points really.
First, when I first started in the early days of MTS/MSMQ, I understood that I should a a matter of principle use
MTS for synchronous transactions, and MSMQ for asynchronous transactions. If I needed to be sure that a transaction completed before I started another, I'd use MTS, otherwise I'd use MSMQ.
I've since been working with EJBs and found "EJB session beans" and JMS to be similar. On this point I tend to agree with Cedric, that where order is required, dont use JMS, and only use EJB. In the UDP/TCP example, EJB would be the TCP equivalent. And I guess thats what the designers had in mind. This would give you the scalablity and distributed server farm architecture. And indeed Billy's system could be designed that way, with all the layers being called within a single EJB transaction.
I can however also see that Billy wants to use JMS in a way other than the simple synch/asynch invocation scenario, which is a feed based system, which is perfectly valid since many existing systems are currently feed based. And in these scenarios, the order may well matter.
e.g. A create order must happen before an amend which must happen before a delete. Billy can make this synchronous by not using JMS and completeing an EJB create before an EJB amend before an EJB delete, but there may be reasons of proximity, or interfacing with existing systems, why these need to go in as feeds.
I therefore agree that it is a shortcoming in the spec.
My second point was about EJB session beans v/v Entity beans
I like the custom controls I can buy for my GUIs, and I understood EJB to be able to provide me with server side "controls".
So far, I've only used session beans, but I'd one day like to be able to purchase a simple off the shelf EJB workflow component that is application server and database independent.
I don't want to buy a whole new Workflow server along with its own separate GUIs, database and message queuing applications that we have to support on top of the servers we currenlty use.
This is where a single .ear file with about 4 Entity beans and a couple of session beans would provide me with this solution. Sure, its currently got performance problems, but thats where I'm hoping things will get beter, and even today, it'll probably be as fast as a monster of a workflow server, if not faster.
The same problem appears again and again, with discussion servers, with time tracking applications, with CRM applications, helpdesk monitoring etc.
It would be nice to not have to buy huge monster applications for each of these tasks. And thats where I see Entity beans being useful, certainly not on performance compared to coding it in session beans.
> I can however also see that Billy wants to use
> JMS in a way other than the simple synch/asynch
> invocation scenario, which is a feed based system,
> which is perfectly valid since many existing
> systems are currently feed based. And in these
> scenarios, the order may well matter.
Note that JMS guarantees order of delivery within the same JMS Session. Server-Side Pool Sessions complicate that matter, though, so I can see where a proprietary extension of Message-Driven Beans (or JMS itself) could add some value here.
On the following topic:
> I can however also see that Billy wants to use JMS in a
> way other than the simple synch/asynch invocation
> scenario, which is a feed based system, which is
> perfectly valid since many existing systems are currently
> feed based. And in these scenarios, the order may well
> e.g. A create order must happen before an amend which
> must happen before a delete. Billy can make this
> synchronous by not using JMS and completeing an EJB
> create before an EJB amend before an EJB delete, but
> there may be reasons of proximity, or interfacing with
> existing systems, why these need to go in as feeds.
In solving this type of problem, we have employed a
J2EE workflow engine (which runs inside our EJB server,
so it does not add enormous deployment complexities on
top of what we already have with J2EE).
The workflow definition is used to define the order in
which events must be processed. The workflow definition
tool supports AND and OR as well, so you can do things
like "the create event must happen first, followed by
either a cancel event or a fulfillment event".
Events are delivered into the workflow engine. The
engine forwards them to specific instances of workflow,
but they are not processed unless the workflow is in
a state where it is ready for that event. If the workflow
is not ready for that event, it is still waiting for one
of the preceding events. Out of order events are held
inside the WfMS and delivered to the workflow instance
when it is ready for them.
There are a lot of aspects to be considered and in some of those, the approach you are offering is flawed. I don't want to go too much into details as it would take much more space and time than I can afford, but I'll try to explain it briefly.
It's pretty much established since Waldo et. al's seminal paper titled "A note on distributed computing" that you cannot and shouldn't transparently handle local and remote calls. First, if you are not convinced, I urge you to read this paper. Even though it's old (1994!), most of what's in it still applies today, and it's pretty much that same idea that led the authors to implementing RMI a couple of years later.
This paper is hard to find, so I took the liberty to copy it to my Web site. You can retrieve it at http://beust.com/cedric/articles/note-distributing.pdf
Assuming we agree on the premises of this paper, it is clearly dangerous to expose only one interface that can transparently apply to local and remote objects. While it is something that most application servers have been providing as a non-standard feature for some time now (including Weblogic), there are very clear gotchas associated with it, and developers need to be aware of them. It would be very easy for a bean provider to read the EJB specification carefully while overlooking the vendor's documentation, and find out the hard way that calls are made with pass-by-reference semantics.
In that respect, Local interfaces are a definite progress since they separate both semantics very clearly.
Another positive aspect of Local interfaces IMO is that they delineate more clearly the roles and responsibilities of relations.
That being said, Local interfaces can also be viewed as a needless burden, forcing bean providers to freeze design choices very early on in the process of implementing their beans. What used to be a simple switch to activate in a deployment descriptor becomes now a radical change in the development process and forces more associated boiler-plate classes to be supplied as part of the bean. Time will tell if this issue matters that much, but my guess is that certain tools (such as EJBGen ;-)) will alleviate this burden somehow.
Okay, that was longer than I initially planned. Let me know if you'd be interested in a more in-depth analysis and I'll try to write up some kind of white paper expanding on these ideas.
Finally, I'm provoking some debate here.. Good to hear from you.
I never said objects should only have a single interface :-). What I did say was use java beans for all local invocations and if it needs to be distributed, use a session bean as a fascade for it and any related beans. That's at least two interfaces. A local one and an optional remote one. The thing with EJB local interfaces is that it's not clear whether this means going through the container (security/transactions/pooling) and I feel that the overhead of this is too high for fine grained objects (persistence ones).
The problem with my approach is that it is similar to the pre POA Corba world. Local calls short circuited the entire mechanism, i.e. security, no interceptors get called etc but this is the price of performance especially on such fine grained and populous objects such as CMP or persistent objects.
As for relationships in EJB 2.0, I already have them and implemented very well in TopLink if I'm a BEA user. Taking your argument that I may not care for switching vendor then what advantage did putting them in the spec server anyway given I have a reasonable implementation now in any case?
Your sidebar on server state replication is exactly what I'm at. I have a messaging system where I cluster message containers. The container provides a proxy topic to subscribe to for the message bean and the container makes sure only m of n of the message beans are consuming work. The real topic does indeed carry both system and user messages, hence the proxy topic to filter system messages before the user code. The others are backups. The state is identical in all message beans on the same "Topic" otherwise the result is indeed chaos as you say.
The container decides which m beans are active and I get a useful service from my J2EE server, i.e. clustered in order message processing. Clustered in the sense, highly available rather than performance.
Given BEA have already implemented this basically for handling HTTP Session failover and now stateful session beans, why not extend it to message beans? Why can't WebLogic's container pick a 'master' message bean and when it can't continue then promote another. My particular problem allowed non transactional semantics, BTW.
Finally, I'm provoking some debate here..
Happy to oblige :-) This thread is definitely interesting, thanks for animating it.
> The problem with my approach is that it is similar to
> the pre POA Corba world. Local calls short circuited the
> entire mechanism
Interesting parallel. Yes, the POA did bring a lot of improvements over the under-specified BOA. And now you mention it, I can definitely see this pattern happening with the EJB 2.0 specification. The goal is ambitious and the kind of hiccup we saw between PFD1 and PFD2 is an unfortunate but inevitable evil, IMO.
As for your "short-circuiting" concerns, rest assured that they are under close scrutiny, but it is important to take things in order. I don't agree 100% with Local interfaces but right now, I think it's more important to accept them and start ironing finer-grained details in order to finally release a final version of the specification.
Note that we (and probably other vendors as well) already perform some of those shortcuts, but I'm hoping that starting with EJB 2.0, they will have to be made within a very well-defined framework. Here again, the parallel with BOA/POA is striking: with the BOA, we were forced to perform a lot of indispensable work (initial resolving, lifecycle, threading, etc...) in a proprietary way since all vendors provided support for those. With the POA, we finally got a standard (and very well-specified IMO) way to proceed.
[I'm not sure I understand completely your architecture but I'm curious. Maybe we should take this off-line, though]
> The real topic does indeed carry both system
> and user messages
And both can update the state of your SMDB?
> Given BEA have already implemented this basically
> for handling HTTP Session failover and now
> stateful session beans, why not extend it to message beans?
We're always interested in improving the container, but I need to understand exactly what you're getting at, first, and then see if there isn't any J2EE standard way to solve it.
> Why can't WebLogic's container pick a 'master'
> message bean and when it can't continue then
> promote another.
First, I'm not sure what you mean by "when it can't continue". Who decides this? The bean? The publisher of the message? Some other party?
Second, unless I misunderstood your problem, wouldn't the following architecture solve it:
- Stateful Session or Entity Bean (EJB-A)
- Message-Driven Bean (EJB-B) updating the state on EJB-A in its onMessage() method
- Have EJB-B subscribed to a Queue
- Replicate this configuration in a cluster for high-availability
- Rely on initial-beans-in-free-pool to get the "m beans deployed but n only active" behavior)
Once again, maybe we should take this off-line, I don't want to kill the very interesting Local Interfaces thread.
Only user messages are received by the message bean. System messages are hidden by the container.
'When it can't continue' means a VM or box failure. The remaining nodes in the cluster then promote a shadow bean to master.
When I say 'm of n' then all n instances run on different boxes (n boxes) and therefore all m run in seperate VM/boxes also.
The problem with the other posters solution of RMI/IIOP to a stateful session bean is just that such session beans are only intended to be used by a single client. I may have multiple sources of such messages and hence my choice of JMS rather than RMI/IIOP. The messages sent from the clients needs to be processed in order.
What I really want is a stateful session bean that is replicated in a cluster but I want a JMS topic to be its source of commands rather than RMI/IIOP. When a failure occurs (the session bean box/VM dies) then I want another instance of the session bean to start processing the pending work and future work ASAP. No messages must be lost during failover but it's ok if a message is processed twice.
For the moment, we're only concerned with handling app server failures, lets ignore the JMS component for now.
Sorry to get a little off topic. I am interested in getting people's repsonse to the following. I do believe that Entity Beans do have some merit despite being non-portable. I am currently using JBoss and I plan to release my product as running with it and WebLogic Server. To do this I will have to write a fancy build procedure which will jar-up the appropriate CMP-type deployment descriptor. I think that this is a 'bearable' task considering the marketing benefit. For this irksome task I get a good level of indirection between my database schema and my session beans (the Entities provide this). I'm much happier hacking XML than discovering JDBC gaffs which only appear at run-time. Could they be faster - yes, could they be more portable - yes again. I've written quite a lot of BMP Entities and it was like pulling teeth trying to keep them in step with a constantly shifting db schema.
People talk a lot about the non-portability of EJB but I think that they tend to consider portability of the bytecode too much. I have worked quite a bit with WLS and when I transitioned to JBoss I found that my EJB design/coding skills remained intact. OK I had to learn how to administer the new A/S and JBoss's DDs. In a former life I programmed Transact SQL and the PL/SQL where the skill intersection was minimal.
Just my 2c.
Some doubts about local interface.
Is there any other advantage besides pass by reference?
If that is the case, isn't pass by value is a feature/limitation of RMI? Why not fix in the
communication layer..to allow IN/OUT semantic just like
CORBA IDL? and set default mode to IN for backward
Also the spec says local interface requires the client and server colocated within the same VM...Isn't that too low level?won't it hinder container's capability to do load balance and fail over?
I agree remote call should not be treated transparently, but from the previous post, local interface also share the same container overhead as the remote interface..they are not pure "local"...so is there really such a big difference that developers should treat them differently?If so,probably it is better to use normal java class in the first place?
Do I miss something?
Pramati's Server 3.0 is the most complete implementation of the new EJB™ 2.0 specifications with support for local and remote entities and Container Managed Relationships and Fields.
the server is integrated with Pramati Message Server 1.0, providing a deployment and execution environment for Message Driven Beans (MDBs). Deploy Tool automatically resolves Container Managed Relationships and Fields against the target database, making serious EJB2.0 deployments simple. Server 3.0 brings forward enhancements to the HTTP Server and Security made in Server 2.5 while providing backward compatibility with EJB 1.1 Containers.