Hi,
I wonder if anyone in the community has a formulaic method for componentizing a color domain model (DNC/ADS model) for use in EJBs?
I've been working on this problem recently and don't want to re-invent the wheel.
First my assumptions - Entity Beans are out! The persistence solution should be something like JDO or Toplink or Hybernate running against the domain classes from the color model.
What I would like to do is partition the domain model into Java packages resolving any two-way dependencies using <<interface>>s and class methods (such as _find()). How I see this happening is that a <<Moment-Interval>> holds the key theme for a package. Everything below it, i.e. its <<MI-Details>> and all the <<Thing>>s hanging from that go into the package along with the <<Role>>s for the <<Place>>s and <<Person>>s on the other legs of the DNC. So far this has produced some nice packaging which seems to be working without side-effects.
I then want to create a SessionBean "facade" class which exhibits the same interface as the public interface to the package - typically a few public methods on the central <<Moment-Interval>> in the package. I would then wire the SessionBean methods to the <<MI>> methods by messaging straight through. In other words, the SessionBean is dumb and acts as a pure "facade" in the G4 design pattern definition.
I would then hook my persistence middleware transactions to the application container transaction manager running in BMP mode.
Does all of this seem reasonable?
Also, in the case where a domain class object needs to be passed from package to package - which would now be from SessionBean to SessionBean - how would you recommend that this is done?
Two alternatives jump to mind: make the class public and simply pass it around; or, make a value object (immutable) version of it and pass that around instead.
NOTE: Throughout this post, I am assuming that the business logic goes in the domain classes. I do not subscribe to the standard EJB notions that DOs only have accessor methods and that (mostly) procedural business logic goes in some kind of "controller" class - as per the Rational <<entity>> <<controller>> <<boundary>> method.
Comments...?
Not an Answer For You, But...
First thing is to challenge the requirements - sometimes the need for EJBs falls away. This still leaves us with a J2EE app - just not an EJB app.
Jeff
The problem with EJB's
I've looked at this several times over the years, and the short answer is you can't.
The EJB architecture has all the issues you get when using any "framework". You might be able to get a bunch of stuff for free, but you have to do things their way. And it's (usually) all or nothing.
Like most comprehensive frameworks EJB assumes control - it decides what's going to happen, when it's going to happen, and most importantly how it's going to happen. You can plug in the bits you want, and you live within the frameworks way of doing things.
When evaluating any framework you have to make a call on whether its "way of life" works for you or if it's too restrictive. Sometimes it's black and white, e.g. you simply cannot achieve something you need to if you use that framework. More often however it's a trade-off, and you have to balance out the potential benefits you'd gain from using the framework with any downsides from having to conform to its view of the world.
EJB is a classic case of this. With a properly written EJB app and any one of the leading app servers that support it you get a bunch of things out of the box - scalability, failover, etc. etc. The downside is that your apps have to be written their way.
Personally I think they got a few things wrong, some badly. Persistence is probably the most obvious, but there are others. You can work around some of them, but then you're adding cost and complexity just to "work around" what you're supposed to be getting for free. Then you start to get back into the grey area of trying to weigh up the costs and benefits again.
Looking at how we map a "domain model" onto EJB's and you quickly start having to look at these issues. CMP is a mess - so what am I going to do about persistence? Probably get a good ORM tool and use that, as you've noted. That's the easiest to solve today.
The biggest problem is the whole notion of a split between entity and session beans. If you consider BMP it's not hard to see how they arrived at this approach. Remember that early on there was only BMP - CMP came later. Unfortunately its legacy lives on. With BMP entity beans are little more than half-baked wrappers onto relational tables. You get a realational view of the world, not an OO one. Clearly you can't map any kind of model onto entity beans.
So you end up writing another layer that more closely models the domain. All you have left is session beans. So now we have these two layers when there should only have ever been one. Session beans exist only because we got the persistence of entity beans so wrong in the first place. There should just be "beans".
So what we're left with is a case of the horse leading the cart - if you adopt this approach you're allowing the technology to influence the domain model. Surely a bad thing.
Add to this the extra layer of EJBHome and EJBObject references, plus the need to be able to serialize everyting for RMI, and it gets confusing pretty fast.
What's happened is that people seem to have adopted the shortcomings of this architecture as valid design principles, e.g. DAO's. They're workarounds for getting it wrong in the first place. Facades are also grossly overused.
There are alternatives that get some aspects of this right. The Spring framework is one example (but it's NOT an EJB replacement!).
Having said all that - sometimes EJB's make sense. When you need all those features that you get for free, it would be madness to roll them all yourself. I have used EJB's in the past, by choice, because it was the most appropriate way to get the job done.
If your domain model is not overly complex then one of many persistence solutions will do the trick with little or no effort. You can use almost any UI technology on top of it, e.g. struts / JSP / servlet / JSF / whatever.
So we have a "persistence capable" PD model, as plain old java objects (i.e. not EJB's). We still need to hook ourselves into the EJB world - so session beans are the obvious answer. The simplest approach is to view the session beans as part of the "C" part of the MVC triad. They're not part of the PD, but the UI. They're not "facades" that belong in the PD, they are controllers. They implement the interaction design, which makes a bunch of calls to PD objects (that participate in JTA transactions via the persistence tool).
IMO most people get this the wrong way around - they assume that all the beans must be part of the PD. Again they let the technology get in the way. The PD classes are persitence capable, and can operate inside an EJB container. The session beans that we write as the controller code for the UI talks to them. There's nothing that says our PD classes MUST be EJB's.
That's the best compomise I've found so far. The way I see it today you've got two choices with EJB's - do it their way, or not! But choose carefully each time.
PaulS :)
Use Session Beans as containers for UI transaction
Paul,
You seem to be suggesting something which had occurred to me but I didn't know if it was possible or feasible or just plain ridiculous - use the Session Bean as a transaction container in the C part of the UI layer.
So we have a "persistence capable" PD model, as plain old java objects (i.e. not EJB's). We still need to hook ourselves into the EJB world - so session beans are the obvious answer. The simplest approach is to view the session beans as part of the "C" part of the MVC triad. They're not part of the PD, but the UI. They're not "facades" that belong in the PD, they are controllers. They implement the interaction design, which makes a bunch of calls to PD objects (that participate in JTA transactions via the persistence tool).
IMO most people get this the wrong way around - they assume that all the beans must be part of the PD. Again they let the technology get in the way. The PD classes are persitence capable, and can operate inside an EJB container. The session beans that we write as the controller code for the UI talks to them. There's nothing that says our PD classes MUST be EJB's.
That's the best compomise I've found so far. The way I see it today you've got two choices with EJB's - do it their way, or not! But choose carefully each time.
I have written elsewhere about modeling the UI as a Statechart of Visual Vocabulary diagram. Transactions can be indicated by drawing a box around a set of elements on such a diagram then insuring in the code (or the "action" elements on the diagram) that all entries to the box run a begin() and all exits run a commit() or a rollback().
One pratical question about your suggestion - do the PD classes all go in the server lib in the app server? Hence, the PD doesn't have to be partitioned into components (or at least I don't have to put too much effort into this)
BTW. In answer to Jeff's question - EJB is a given as the system - though going to be a huge thing in itself - can't say too much but world class problem designed for use with up to 1 billion clients (remember I'm in the mobile phone business) - has to work with our existing product as part of a suite. That product is totally coupled to Weblogic app server.
Regards and thanks,
David
Packaging PD classes in an EJB app
One pratical question about your suggestion - do the PD classes all go in the server lib in the app server? Hence, the PD doesn't have to be partitioned into components (or at least I don't have to put too much effort into this)
I'm not sure I understand what you mean by "components" here. In the usual EJB sense an "Enterprise Bean Component" is all the things that make up what we usually call "an EJB": its remote interface and remote home interface, the bean class itself, perhaps a primary key, and maybe local interfaces also.
None of this applies to the PD classes, if we agree that we're not using entity beans and we'll only use session beans as part of the controller in the UI layer.
If you're talking about packaging the classes, you can do it a number of ways. They end up in the .ear file for execution in the EJB container of the app server. Other than that I'm not sure what to say - I'm not sure what you are asking.
PaulS :)
Java packages rather than components
I was talking about Java packages, i.e. if we are using SessionBeans as UI transaction containers, then many SessionBeans need access to the PD classes. Hence, should those be in the server lib and consequently how they are packaged (in Java) is fairly immaterial? i.e. as the PD is not being componentized into EJBs.
I hope that is clearer.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
PD packaging
Do the same as we've always done - PD is separate from UI. The pd classes go into pd packages and the UI classes into UI packages. The breakdown of the pd package hierarchy is dictated by the makeup of the PD model.
The UI classes are split between the "presentation", say a web app, and in this case the session beans. You package each as usual for each of those technologies.
Any one of a number of books on EJB or J2EE will have explanations and examples of how to do this - it's standard stuff. The o'reilly "Enterprise JavaBeans" 3rd edition (which also covers EJB 2.0) is just one example.
PaulS.
I'm not following...
I wonder if we have a disconnect as I am unclear as to why you replied this way.
Yes, I am following how to split PD from UI. I was purely wondering about packagin in the PD layer, i.e. I was speculating that the rest of the architecture does not care whether the PD comes in a single package or in multiple packages. I would envisage packaging the PD using strategies such as those found in Lakos, Large Scale C++ - a book which you introduced me to about 6 years ago.
Hopefully, we are flying in formation now?
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
java packages
ok - now I think I know what you're talking about. You simply mean splitting the PD classes into a java package hierarchy? I've not heard to this referred to as "packaging". Since the discussion started out talking about EJB's, and you mentioned "server libs" my guess was that you were talking about bundling together the classes for deployment.
But since we're talking about java packages, then yes - the rest of the system doesn't care they're partitioned (other than client programmers sanity), and I'd use similar principles to those you mention.
With Java it's less of a concern that in other languages such as C++, which I think the book was concerned with. However the principles are still valid.
I've found that the Java pacakges usually become apparent pretty early on when doing the modelling in process 1. The models that we end up with from each of the domain walkthroughs *usually* make rather good "components" (in the traditional sense of the word) in that they're pretty self contained and relatively loosely coupled to the other components. These often give good hints for packaging of the PD classes that implement the models.
And please, don't anyone take this to mean that the packages are derived *directly* from the domain walkthrough models. They are just a *hint* at a reasonable partitioning (assuming you model things well) which can often guide the java package hierarchy.
PaulS.
Controller not part of the UI
Paul
part of the "C" part of the MVC triad. They're not part of the PD, but the UI.
I agree with you on the "C" part of the MVC, but don't agree they are a part of the UI. For example in David's domain transactions spanning multiple devices and hence multiple UI sessions are common. Think of downloading ringtones.
My understanding of the MVC and I recall from a couple of years ago there are at least 2 distinct interpretations of the MVC pattern is; View = UI, Model = PD, and Controller = Session which acts as a container for transactions, i.e. it owns the transactions.
phil
MVP - Model View Presenter
Hi Phil,
IMO the "controller" is certainly part of the user interface layer. But we might be mixing terminology here.
What we're really talking about these days is MVP - a slight variation on "traditional" MVC, but you'll probably find that when someone mentions MVC today they are probably talking about MVP.
The original article on MVP is here
You can see the parts shaded pink in the MVP diagram are part of the UI, and address the question "how does the user interact with my data?". Quoting from the text:
The third question is "How do I put it all together?". This represents the function of the Smalltalk controller, but elevated to an application level and taking into account the intermediagte selection, command and interactor concepts. To capture this distinction we refer to this kind of controller as a presenter. As a result, we refer to the overall resulting programming model as Model-View-Presentor, MVP, acknowledging its origins as a generalized form of MVC. The role of the presenter within MVP is to interpret the events and gestures initiated by the user and provide the business logic that maps them onto the appropriate commands for manipluating the model in the intended fashion".
While I don't see a direct mapping of the parts of MVP onto the various pieces of technology in an EJB app, IMO you could roughly say that the interaction design of the UI addresses the Presenter part of the MVP triad and session beans are a good way to implement it using EJB's. Based on this I really *do* see all of these as being part of the UI.
When you talk about sessions and containers, I'm not sure exactly what you mean here (most likely because of overloaded terminology again). Within the J2EE architecture a formal definition exists for the "EJB container", which is the runtime environment in which EJB's are executed. Assuming the use of session beans, transaction semantics are usually handled simply by delaring the necessary semantics for the operations in the session beans - we don't usually do anything programmatically.
This is all based on the architectural approach that I was first introduced to by Jeff DeLuca on the Singapore project - it says the transaction boundaries are part of the interaction design (David - you should remember this). For me that's the biggest clue that session beans are a good fit here, and that it's certainly not a PD function.
IMHO of course. PaulS :)
Too many Cs
With MVC their are two popular variants - the original Smalltalk MVC and what Sun popularized as the "type II" pattern which is most popular in presentation layer frameworks such as Struts and JStateMachine.
However, Rational also popularized something called Boundary-Controller-Entity architecture which is closely related to UseCases. I have some belief that EJB architecture was intended to map onto this model with the SessionBean playing the Controller role. Controllers in a B-C-E architecture are actually procedures and map closely (or precisely) to Use Case task flows. The EntityBean would be the Entity role and the web server with the presentation layer the Boundary role.
I've never been a fan of the B-C-E architecture as I don't see it as "object oriented" more as "procedural code wrapped in objects". Many EJB implementations also fit this description "procedural code embedded in SessionBeans disguised as object oriented". All in all I find the EJB architecture to be pretty unsatisfactory.
To Paul's point - yes I do remember that transactions are scoped as part of the UI - and I have actually proposed an extension to the Statechart notation to facilitate doing so. The JStateMachine engine implements that proposal. I have also written several papers over the last 5 years which talk about this topic.
If you look at the name "SessionBean" it gives off a feeling of "application session" i.e. something in the UI. However, the other aspects of it don't match with this expectation.
I am considering giving Paul's idea a chance. However, I am wondering if there is a tradeoff that clustering of the PD is no longer possible and that the multi-user aspect of the system must be handled through the database. This has a drawback for the specific problem domain in which I am working - there is a desire to componentize the PD so that it can be offered in different configurations which are in effect different products with different prices and licensing models. The customer then has the option to "plug-in" modules at a later date to grow the functionality. This requires the PD to be componentized and the natural way to do this in EJB app servers would be to offer sections of the PD as separate SessionBeans.
Anyway, I need to go off and try some things - which may take a month or two - before I could usefully comment further on this thread.
Cheers,
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Controller and UI
Hi Paul
I think I originated the idea that transactional boundaries are part of the UI design on the Singapore project. What I argued and I still maintain this, is that the UI must reflect the transactional boundaries. That is, the user must know when a transaction starts and ends. This doesn't mean the UI owns or originates the transactions. Similar arguments apply to sessions. Although at the time I strongly argued the UI did own them. Since then I have realized that a controller must intermediate between the UI and the PD.
BTW, when I talked about containers, I meant in a normal use of the word, as in a basket is a container for eggs. Something that holds something of a finer grain. There was no implication of an EJB container or similar.
I think we agree that the PD never owns transations or sessions. All it does is support them.
You can combine sessional and transactional control with the UI when you are just dealing with a single type of UI device, but when you deal with multiple UI devices - browser, voice response, phone download, SMS, etc. then it makes less sense to combine them. When you deal with distributed systems where there is no user or interface to them, then there is no UI to combine the controller or presentor with. But you must have the controller, (as well as sessions and transactions in most cases). They are integral to the PDs interation with the rest of the world.
phil