Dependent Session Objects


J2EE patterns: Dependent Session Objects

  1. Dependent Session Objects (51 messages)

    Hello Everbody,
    This pattern may sound interesting but applicable. We are using it in a large enterprise system development project - in replacement of a mainframe system which operates a complete wholesale bank with all fuctionality-. And, we are satisfied with results.
    After we have worked nearly a year for analysis and design we got a huge OO design with UML in Rational Rose. During this period of time our architects decided to use Java and EJB as architecture. In spite of the increased popularity of EJB technology we could not find answer below design problems;
    -When all objects were implemented as EJB, network cost would be increased.
    -When Aggregate Entity Pattern is choosen, error prone, labor intensive code would be increased.
    -Relying the discussions about EJB patterns and architecture, nobody knows the answers in this architecture , especially developing enterprise system.

    So, we choosed below layered structure;

    -UIML based generic applet

    Web Server
    -Servlet as presentation manager

    Application Server (Business Layer : Session EJB+dependent objects)
    -Caller Object as Business Service Supplier(calls Stateless Session EJBs)
    -Light Stateless Session EJBs as wrapper for dependent business java plain objects. All business object hierarchy is implemented with plain java objects (very huge) which are created inside wrapper session EJB. Briefly, we built a class layer between Session EJBs and Entity EJBs.

    Application Server (Data Layer )
    -Fine grained CMP entity EJBs

    Application Server schema:

    Caller object || Wrapper Stateless Session EJB || Class Layer || Fine grained CMP entity EJB

    All commands and suggestions are welcome.


    Threaded Messages (51)

  2. Dependent Session Objects[ Go to top ]

    We are also using same kind of design in a clustered environment. Are you using it in a clustered environment.

  3. Dependent Session Objects[ Go to top ]

    Yes, we are using clustering and performance is very good.
  4. Dependent Session Objects[ Go to top ]

    Hello Ghari!

    You wrote:
    "After we have worked nearly a year for analysis and design we got a huge OO design with UML in Rational Rose. During this period of time our architects decided to use Java and EJB as architecture."

    I'm very interested in the **process** followed during this analysis and the step to design, especialy the point where the decision to use EJB was made (and the state of analysis and design at this point).

    My master thesis I'm working on analysis this process and I'm searching for good input from the practice.

    Also, I'm interested on your full UML model (I've never seen yet such a full one, which is not constructed for a book but comes from real live, with full of artifacts put together!) Are you using packages in use cases? If so, how, and how are this used later? What is the EJB-free and where begins the EJB-related part?

    Could you be so kind and give me more (as much as possible! ;-) information about this things?
    Feel free to email me at e9127099 at student dot tuwien dot ac dot at
    or (nicer name ;-) ewald at iname dot com

    Have many, many thanks in advance!
  5. Dependent Session Objects[ Go to top ]

    Oh! "Ewald" and "Franz Mueller" are the same person!
  6. Dependent Session Objects[ Go to top ]

    I am afraid, this analysis and design process is not the one you expect. We left a lot of issues later iterations and we are not satisfied with the UML model. So Sorry.
  7. Dependent Session Objects[ Go to top ]

    Very interesting. But could you elaborate some more on your suggested architecture. It is stated that i solves severel problems, for an example, mapping OO design to J2EE architecture. What is the problem and how does your architecture solve the problem. (or chance of easy migration?, benefit of c++, OO, Corba skill usage?)

  8. Dependent Session Objects[ Go to top ]

    J2EE forces fine grained Entity EJBs and coarse grained Session EJBs. Indeed, there is a pattern as Aggregate Entity but it results in labor intensive work. So, with coarse grained Session EJBs and fine grained Entity EJBs, your code will turn service based legacy code. Nobody wants this result in spite of the benefits of EJB because, maintainability will be lost. OO design is important and must be preserved. if you designed an enterprise as suggested in J2EE, OO will be lost and you will be lost in a service based designed system. And, in the future, the way to return back to OO designed system will be nightmare.
  9. Dependent Session Objects[ Go to top ]

    " After we have worked nearly a year for analysis and design we got a huge OO design with UML in Rational Rose. During this period of time our architects decided to use Java and EJB as architecture. "

    You know what ? Fire the software architects, and burn the UML diagrams.
    The results already look bad, they spent almost one year on nothing, they came with a conclusion that anyone who reads the technology magazines can come with (and trust me they don't have a clue why it's the right thing to do EJBs).
    More, you're unsuren if the whole UML enchilada is not going to hit some hard walls.

    Replace the architects with tough experienced programmers and do some little coding, then you'll modify the design oin the run, do a little "refactoring" (rebuilding some classes/interfaces from scratch) .

    It's not mandatory that you should use eXtreme Programming by the book, but until you do the coding and testing there's no combination of tool/methodology that will validate a design.

    A good design is just a sketch on the wall. You could use graffitti if you like.
    And fire all "software architects" or let them stay only if they can do the coding.

    As to what regards the technical aspects and what are the right patterns there's only one answer: "there's not silver bullet".
    If theree was one somebody would wright a nice wizard and all the problems were gone.
    The "right" solutions differ from situation to situation , therefore do the coding, test, recode where needed and test again.

  10. Dependent Session Objects[ Go to top ]

    Hi Ghari,

    please could you send me a diagram of your architecture. I can't imagine what are the fine grained EBs for. If you use DOs for the fine grained behavior controlled by your services, what do the EBs do ? Wouldn`t it be better to use the EBs as data containers for the DOs or to replace them by a tool like toplink ?

  11. Dependent Session Objects[ Go to top ]

    Hi Thomas,
    In the architecture, there are small Stateless Session EJBs which contains no business logic but service interfaces. For every service call, EJB instantiate a business object hierarchy to do job. These business objects are implemented as ordinary java classes. These business objects use fine grained Entity Beans as persistence layer. As you said, fine grained EJBs may be implemented as DO or TOPLink. But we did not prefer hand coding in persistence layer for simplicity. In conclusion, fine grained CMP Entity EJBs are for built in concurrency, TX control, persistence, workload management, v.s.

    Thanks for your comment, I am waiting further ones.
  12. Dependent Session Objects[ Go to top ]

    Hello Ghari

    We are in a design phase and we came pretty much with the same solution that you have implemented and described above but we have decided to use an O/R mapping tool instead of EB. Now we are wondering if instantiating a business object hierarchy each time an client call your Stateless SB has an impact on performance because of instantiation delay and then garbage collecting process. Have you considered the usage of an object pool ? This might sound pretty weird as normally such services should be handled by the container... what do you think?

    Thank you in advance for your valuable feedback

    Greetings Laurent

  13. Dependent Session Objects[ Go to top ]

    Theoriticaly you are right about instantiation and GC. However, we have not seen the bad effects of our design. In the begining, we were suspicious about performance, we tested but could not catch any clue about wick performance. It is possible, we could not test very well. If you have suggestion about testing -EJB profiling tool, sample application, etc. - ,you are wellcome. Regarding the object pool, we are wondering that, the complexity will increase but performance will not increase as expected because of the cost of object initiation and state maintanance of objects. Regarding the your choice, firstly it is propreitary, secondly it needs more programmer effect for large and integrated projects. Our project is an enterprise wholesale banking application, old system has nearly 3000 tables, nearly 60 developer are working, nearly 10-20% are experienced. And, finally, the development period is 8 months. So, simplicity are very important for us.

  14. Dependent Session Objects[ Go to top ]

    I would argue that from all the advantages you enumerated only "persistence" may be regarded as such.

    Let's assume the alternative (which you would naturally reject) is Session Beans + SQL to database.

    You have:
     - built-in concurrency, far better than with your solution
     - TX control, well everybody has that without any special effort
     - workload management that's a red herring it doesn't mean anything (zip, absolutely nothing).

    So in the end, the only thing is that fine grained CMP entities, it saves you some programming effort.

    The impact in terms of performance and flexibility may be disastruous.
    And if you "instantiate" a graph of objects for every service call you're going to suffer more, you're better off using entities directly.

    Even by the spec's own words, you shouldn't use "fine grained" entities.
    Use "coarse grained" as they say (it's true that they also fail miserably to define the notion).

    Don't get me wrong, if you don't like my comments you can disregard thenm, but I don't like to see what it apears to be an anti-pattern defined as a pattern on this fine site.

  15. Dependent Session Objects[ Go to top ]

    Hello Costin

    When you state "The impact in terms of performance and flexibility may be disastruous" are you talking about fine grained entity beans or entity beans in general?
    Also when you comment on the bad performance of instantiating a graph of objects do you suggest that having a whole bunch of statless session beans calling each other in cascade is a better approach? why?

    Thank you in advance for your comments

    Greetings Laurent

  16. Dependent Session Objects[ Go to top ]

    Hi Laurent,

    I'm talking especially about "fine grained" entity beans, but entity beans in general are not that much better.

    I was referring of the fact thast the graph of object is only an indirection to the entity beans.

    On this site there's also a pattern "SessionBean as facade to Entioty Beans", which is a little better because it doesn't use another indirection.
    But that pattern is also not very convincing.

    On the other hand the solution you mentioned Laurent (Session Beans as facade to an O/R tool persisted java objects) is one of the few valid way of doing business in the J2EE environment.

  17. Dependent Session Objects[ Go to top ]

    Hi Costin,

    you're spot on. as session beans (sb) are used as a facade for eb then client should only "see" the facade. so the client should never invoke an eb directly. all the tx stuff can be controlled by the sb in the facade (CMT || JTA). the question is then: "why should i use such heavy weight objects like eb ?".
    my point of view is to replace the ebs by plain java objects, which are mapped to DB by an O/R tool (toplink). what are the eb (a remotable/sharable object) for if they are only invoked by a facade or service implemented with sb ?
    This question is not only for Costin, it can be noticed by all ejb developers.

  18. Dependent Session Objects[ Go to top ]

    What do you mean with anti pattern ? Can you explain more ? Regarding the your suggestions and comments;
    -If I prefer to Session Bean + SQL, where will I implement business object hierarchy. Isn't it the same place. I mean, business objects will be instantiated by Session Beans. Or, do you mean to implement all the object graph with Session Beans, inheritance, composition, etc.
    -Is there any method or tool to implement the persistence of a huge graph by nearly 60-70 programmer efficiently?

    Can you explain your suggestions and comments more? I don't mine, continue your sharp comments.

  19. Dependent Session Objects[ Go to top ]


    When I told you about session beans + SQL I meant that you have the same things that you mentioned as "advantages" of your pattern .
    Of course, you cannot implement an "object graph" with Session Beans + SQL, but nevertheless you can implement an "relational model" which is much more sound and well founded than the illusional "object graph".

    That's a totally different approach , but is nevertheless a valid one, althoug many OO foos will have a hard time to admit it.

    When I affirmed that your pattern is anti-pattern, I meant that there's already a pattern called "Session Bean as facade to Entity Beans" .
    Your pattern differ from that one only by the fact that you add a layer of java objects (you call them business objects).
    When you use this architecture the Session Beans and the Entity Beans already ARE your business objects.

    So even if we admit that "Session Bean as Facade to Entity Beans" is a valid pattern , yours still remains an anti-pattern, or you have to justify what you want to use the extra java objects for.

    Yes, that's a tough job organizing a project in the situation you described, but that's an orthogonal aspect.
    It has very little to do with design patterns.
    And it's even tougher if you spent that much time architecting and designing.

    On the side note, I would say that 300 COBOL indexed files should not necessarily be ported as 300 relational tables.

    And be aware that if the old application was using CICS+ Cobol architecture as I suspect, you'll have a tough time getting the same transactional throughput using J2EE.
    Unless you're lucky and CICS was running on very old hardware.

    Good luck,
  20. Dependent Session Objects[ Go to top ]

    Your remarks are much appreciated. It appears that the OO enthusiasts create a problem by abandoning the relational model in favor of much more complex object data models. Then they go through complex gyrations trying to make the complex object data model work for them rather than just admitting that maybe the relational model was better in the first place.
  21. Dependent Session Objects[ Go to top ]

    Whoa! Perhaps Costin was implying more than I intuited, but I got the feeling that all he was saying is that there are different ways to approach a problem -- and one must be willing to accept the consequences.

    For anybody to uniformly denounce either relational or OO as an inferior approach to solving problems is a shame. Both technologies have their benefits and each represented a major leap forward in computing when theory became practice - otherwise we'd still be using indexed COBOL tables.

    I'll spare everyone a history lesson, but remind you that a component application/relational persistence merely represents a series of tradeoffs compared to a OO application/relational persistence or OO application/OO persistance or structured application/hierarchical persistance (and so on and so on). Each with their pros and cons...

    With regard to the above mentioned proposed pattern I too think that more time needs to be spent on the explanation of the additional Java object layer between session beans and entity beans. I have experience in a large banking system implemented without EJB that use a logical three tier{presentation|business object|data adapter} application layer. This proposed pattern sounds similar in that you essentially have logical fine-grained entity bean adapter layer to obfuscate the business layer from knowing about the relational store, everything in front of the business layer {jsp|servlet|session} appears to be a traditional MVC approach. Overall though, it is tough to really sort out the details based on the discussion so far in this thread.

    I do disagree with Costin on the anti-pattern call though. As with patterns, anti-patterns must be considered 'a common solution to a common problem...' with the addition of '...that is repeatedly (more than 3 times at minimum) proven to create serious problems'. It seems to me that this is an uncommon solution where the jury is still out.

    It is a shame, however, that the Java Class Layer cannot take advantage of typical and beneficial container services. Usually this kind of "separation of concerns" (ie: layering) is used to improve the already low odds at future reuse and maintainabiliy. Without some more thought, I'm not sure that the Java Class Layer actually adds anything to either reuse or maintainability.

    On a side note, with a development team this size 60+ and so few experienced in EJB there is a huge risk of not coding to the architected specification anyway. Typically, with development creep programmers will start to sidestep 'soft rules' like logical architecture layers in favor of faster, less portable two-way dependency class/EJB coding.

    With the development team this size and (apparently) a tech lead with little extreme programming (xP) knowledge, an adaptive process approach would probably spiral just like the analysis and design period did. I'll be curious to find out how this proposed pattern works for (a)reusability (b)maintainability and (c)performance.

    I'll stay tuned for more updates.



  22. Dependent Session Objects[ Go to top ]

    Hy Jeff,

    Perhaps you read me right the first time, so to make it clear I'm not saying OO is "bad", I'm doing OO right now and been doing OO programming all the time.

    But I wanted however to correct you a bit.
    Like all good OO folks you think in terms of "persistence"
    like OO application/relational persistence and so on.

    Last time I heard of, it was called the "relational model" and it was a little more than merely a thing where you "persist" your nicely designed objects/components/ejbs and whatever.

    The OO model and the relational model are not trade-offs with respect to each other, they simply have quite different usage patterns.

    Only when you think in terms of objects everywhere, or EJBs everywhere , which is worse, then you really hit a hard wall.
    And since usually the RDBMS is the rule, you're free to blame it on OO/Relational "impedance mismatch" :)

  23. Dependent Session Objects[ Go to top ]

    how do you get concurrency with session beans?
  24. Dependent Session Objects[ Go to top ]

    Posted by Todd Murray 2001-03-30 16:11:27.822.

    > how do you get concurrency with session beans?

    If you haven't noticed databases have supported concurrency for quite some time.

    So you can read in white papers, product bochures and whatever that Entity Beans will do miracles with concurrency scalability and whatever else one might dream of.

    They all suffer greatly from the "not invented here" syndrome
  25. Dependent Session Objects[ Go to top ]

    Hi Gari,

    I think you do not have to instanciate a whole graph of object each time a client call a method in your stateless EJB. What we plan to do is use the same approach as yours, placing all the business logic in a set of collaborating plain java classes, which offer us the advantage of using the full power (inheritance, polymorphism) of the OO paradigm, and instanciating the graph just once in the EjbCreate method of the stateless facade EJB. Since the EJB is stateless, it does not make sense to maintain state in the object graph between client service calls. This does not mean we avoid to use instance variables in the business classes. Simply, we know that those instance variables do not maintain usable state between call from their client. Since each stateless EJB has its own business classes graph, nothing is "shared" between the EJB's.

    The issue of pooling our business objects is also not relevant since the EJB container manages the pooling of the stateless EJB's, and so of the attached business object graph.

    A last advantage of this architecture is that you can debug your business logic without having to use a application server, which slows the debugging process. You simply use a proxy (again, a plain java class) which calls your business object graph in exactly the same way as your stateless facade. With the proxy, you can debug your business logic using a light, non EJB project, which improves your debugging speed.

    So, to summarize:

    o creation of the business logic graph in the EjbCreate method
    o built in pooling of the business objects, no gc
    o ease of business logic debug

    Please tell me what if I am dreaming or if this makes sense !

  26. Dependent Session Objects[ Go to top ]

    Exactly true. I have not seen any bottle-neck until now. So, we will continue dreaming until someone/something waken us. Nobody/nothing has achieved to insist me that concept is wrong in EJB programming.

  27. Dependent Session Objects[ Go to top ]

    Hi Ghari,

    We are not trying to "achieve to change your mind" :)
    This is a friendly discussion site, but you posted your ideas in the Patterns section, so it would be nice if you will have some arguments in this regard.

    You may feel that it works for you, but a pattern should be something that others will comprehend and be able to apply, therefore it would be nice if you can share with us why you needed a layer of objects that in turn use CMP Entity Beans to do their work.

    Is this facade layer needed because you want to be able switch the implementation to another technology ?

  28. Dependent Session Objects[ Go to top ]

    I agree with you what the pattern is and I want to discuss friendly. As you know, me and Jean-Pierre tried to tell the need for OO and object layer. If you say it is needless to utilize object orientation I can not accept it. All of your implementation and design ways may be a partial solutions of a big system. However, they can not mainly be utilised in an enterprise wide project with a large development team.
    Infact, I would not preferred J2EE in my project. I beleive the mature power of CORBA and try to find safe path in Java.

  29. Dependent Session Objects[ Go to top ]


    I like your design, except for the fact that you are creating your huge object tree (of plain java objects) in each service invocation. Why not consider using a Stateful Session Bean to hold the object tree instead? Obviously, each service call is not going to replace/modify all the objects in your tree. (if it does, something is terribly wrong).

    Assuming that each service call replaces/modifies a portion of the object tree, you gain in two ways, by using a single stateful bean for each user session.

    1. You can use this stateful bean as a server side Cache

    2. Stateful beans makes sure that your object tree is manipulated by only one thread at a time. (Prevents the possibility of more than one window on the same session leaving your object tree in an inconsistent state)

    The minus side of using the stateful bean is that you cannot keep anything in the stateful bean that cannot be recovered after a server crash - that is, any data not in your persistent store will be gone. This shouldn't be a problem for you, since you are using Entity EJBs for your persistent data.

    I am not sure I understand your requirements completely, and so part of this may not be applicable in your case. Just wanted to share some thoughts...


    Application Architecture,
    Dain Rauscher Inc.
  30. Dependent Session Objects[ Go to top ]

    Are you sure?I feel When you say "stateful session bean" what really should be is "stateless session bean"..
  31. Dependent Session Objects[ Go to top ]

    I am suggesting to use one "stateful" bean for each user's session to maintain the object tree. Obviously, the state of the objects in the tree is different for different users and the only way that you can hold on to this state, without having to write any persistence, is by using "stateful" beans.

    When a user logs on, you will create a stateful bean and populate this bean with the object tree. (lazy initialization can be used here). At this point, you store this bean's handle in the Session Cache. For subsequent service calls for the same user, we will be calling "STATELESS" session beans, passing in the reference to this user's "STATEFUL" bean as an argument. (I think, you will pass the EJBObject, got from the handle stored in the Session Cache)...

    We have performance problems today because we store the object tree in the Session Cache using HttpSession persistence using DB2. (we operate in a clustered envt). We are thinking about using a Stateful bean to hold the Cache instead.

    By going to the Stateful bean, we will be adding a remote call for the service calls that simply serve data from the Session cache without using any Stateless EJB (has any business logic). We are anyway going to DB2 to get this info today, so it is no big deal using remote calls. Also, the number of service calls of this type are very minimal in our system.

    We considered other approaches such as storing the objects in the tree individually in the Session Cache, but did not like them because it involved either breaking your Object Model or adding cumbersome ad-hoc code & logic....

  32. Dependent Session Objects[ Go to top ]

    <q>the state of the objects in the tree is different for different users </q>
    Disagree, when you say state here, are you refering to
    state of object or state of tree?
    As my understanding of the original post,
    state of object: if the object has state,all these state
    is maintained in the data layer/entity bean.
    state of tree: there is no client specific state regardless
    using lazy initialization or not.

    I feel your approach is definitely less scalable, in the
    other word, why go for stateful session bean when they
    are already statelss..

    I do agree you that lazy initialization can be used, or
    as previous post suggested: pre-initialization during instance creating, these dependent session objects can be kept during the life cyle of the bean instance, method level
    allocate/GC doesn't make sense.
  33. Dependent Session Objects[ Go to top ]


    It was not clear from the transcripts that you are using these java objects only for behavior and not for state. In this case, I completely agree that we should use the Stateless beans. Also, the post by Jean-Pierre Schnyder on April 3, 2001, describes how you can avoid creating these objects every time.

    Let us talk about some detailed design. Assume that our object model is an User having zero or more Accounts. In OO terms, say that we should be able to invoke "getAccounts()" on the User object, and "withdraw()" and "deposit()" on an Account object.

    It is obvious that the methods "withdraw()" and "deposit()" will be in the java objects. What about getAccounts()? Will this be in the User Entity EJB or user java object?

    In other words, are you using the Entity EJBs just to mimic the relational database OR making it a bit more intelligent, by including the navigation for the associated objects?

    I am familiar with the "Session wraps Entity" pattern, where you will probably have the "withdraw()" and "deposit()" methods, plus a host of others, in a single stateless bean. But, I am yet to understand the benefits of a parallel java object hierarchy proposed here.



  34. Dependent Session Objects[ Go to top ]

      See my prev. post for the benefits, this is just my
    understanding,Ghari please correct me if I am wrong.
  35. Dependent Session Objects[ Go to top ]


    The "need" for an object layer is not absolutely a must.
    I didn't say it's bad or needless either.
    There are alternatives way of programming, and I don't mind if you can't accept the relational model, feel free to ignore it at your expense, while many major enterprise software packages are specifically programmed to take advantage of the relational model.

    To be brief, I'd say you should try to understand that OO and relational are alternatives.

    But while we all understand your need for an object layer we all wait to here from you why you need an extra object layer while your "fine grained" CMP Entities already are an object layer.
  36. Dependent Session Objects[ Go to top ]


    I don't understand why you have problems understand
    <q>why you need an extra object layer while your "fine grained" CMP Entities already are an object layer</q>

    since you said before:
    <q> I'm doing OO right now and been doing OO programming all the time</q>

    Simple answer: to implement business logic.

    In object oriented world, everything is object,right?

    I do agree use "fine grained" entity bean is not a good idea.
  37. Dependent Session Objects[ Go to top ]

    Thank you for your explanation.

    I need objects to model the world. I could not represent such a huge system in procedurel service based paradigma. Some advantages of OO paradigma are;
    -Everybody in project should understand what they are doing.
    -Objects are communication bridges between users and IT or between real world and implementation.
    -OO has important futures -encapsulation, inheritance, polymorphism, etc.- which are well known by every IT people.
    -High Tech people regards not only money but technology for long term career. So, it is easy to find good and talented people for that kind of projects. As known, this kind of enterprise projects are very long (1-2 year) and wearing(tiring). So, precurement and keeping talented employees are very important.

  38. Dependent Session Objects[ Go to top ]

    Qing and Ghari,

    Ok, now I see what you are trying to sya, thpough I think it is either not that obvious or I was not paying enough attention.
    I encline to think it's the first one, but I appologize (or "regret") the misunderstanding.

    So you are trying to say, if this time I understood correctly, that you couldn't put business logic inside the EJBs (either entiy or stateless) you feel you needed to add another layer of java objects.

    The usual approach is that you "put your business logic in session EJBs and data access logic in Entity EJBs" (I'm not saying this is good either, therefore I quoted, the idea is not mine).

    In your pattern then we have :
    - the session beans are a facade to the client
    - the java object layer represents the business logic (algorithms )
    - the fine grained CMP entitities are the way you access your data.
    This is based on Qing's explanation which makes more sense.
    I hope I got it right this time or Qing is right.

    You said that "All business object hierarchy" is implemented with java objects.
    Your "business objects" (like Account, Customer and so on) should then be implemented directly as Entity in this type of approach, not as a java object lets say AccountPlainJava which in turn goes to AccountEntity.

    I'm not
    Please put some more effort and try to make the pattern a little bit more clear.
    Try to describe what exactly is the problem you're trying to solve, why the other usual approach doesn't work for you.


    Qing , in OO world it is not generally true that everything is an object.
    You have to think what is the definition of object :
    object= data + behaviour.
    That's one of the reason the pattern looks suspect, object that represents only data and objects that represents only logic SHOULD be an exception, otherwise you have an rebadged structured programming approach where your functional objects represent the procedures and data objects represent your data structures.
    The only place where everything is an object applies is SmallTalk.
    Of course there are people who think Smalltalk is the one and true OO language, and they might be right in their own way :)
  39. Dependent Session Objects[ Go to top ]


    I feel you still misunderstand the idea.
    <q>that you couldn't put business logic inside the EJBs (either entiy or stateless) you feel you needed to add another layer of java objects.</q>
    Not exactly, these business logic belong to session bean,
    it exists in the form of pure java objects. Session beans
    then use those java objects and serve as facade/adaptor.
    The key problem this pattern try to solve is avoid using
    chain of session beans,reducing beans instantiation/communication overhead so that overall system performance/scalability can be improved.

    object= data + behaviour.

    That's one of the reason the pattern looks suspect, object that represents only data and objects that represents only logic SHOULD be an exception, otherwise you have an rebadged structured programming approach where your functional objects represent the procedures and data objects represent your data structures.
    Hey, are you try to blame this pattern or the whole EJB architecture:-)
    Interesting topic, as my understanding, EJB is where
    traditional TP system(TUXEDO/CICS) meets OO programming.
    Former based on procedure programming and concentrate on performance and scalablity, latter concentrate on better software design.

    At first sight, there is a "impedance mismatch" here, but
    actually not true, because they are in the different architecture levels(I am not sure if you have read a book
    called CORBA design pattern, it explain the idea pretty well). Taking EJB, at glance, is seems OO is broken,
    session bean=function, entity bean=data. But when you
    zoom in, or one architecture level down, entity beans and session beans are consists of tens/hundreds of "fine grained" objects that developed by established OO techniques..

    In a word,EJB try to be the combination of the best of the both worlds, whether this itself is correct or wrong is another issue...

  40. Dependent Session Objects[ Go to top ]


    let's clear out the discussion abit, do you wotk together with ghari ? just to make sure we are not speaking of two different patterns.

    I still feel like you're talking Chinese to me :)
    You may blame it on me being a mediocre programmer / bad english speaker, but I like things that are clear.

    The key problem this pattern try to solve is avoid using
    chain of session beans,reducing beans instantiation/communication overhead so that overall system performance/scalability can be improved.

    That's one of the reasons of the pattern I suspected, but it was never said that way, more it says "business objects hierarchy" which in turn depends on "fine grained CMP entity beans" (horrible dictu).
    Well, it seems to me that in common software jargon business objects and business logic are different things.
    Do you at least agree with me that business objects (such as Customer and Account) don't need an extra facade, if they are alkready implemented as "fine grained CMP Entity" ?

    If business logic belongs in Session Beans , why do you need facade/adaptors and you can't use Enity Beans directly ?
    You ought to give more explanations and/or be more specific, just stating something doesn't help.

    Here I'm taking the role of devil's advocate, since I think the original pattern with Session Bean for business logic and Entiy for <q>"data logic"</q> is not that perfect either.

    Hey, are you try to blame this pattern or the whole EJB architecture:-)
    Nobody ever heard me saying that EJB architecture is great.

    As to what you're saying about the philosophy and beauty of EJB architectures, I think it's overly poetic.
    It may spound perfect marketing people from Sun, Bea and the likes, but usually it should be argumented, while your expression of this wonderful idea (if consistent) comes out of the blue sky.

    It's a totally different discussions but you can post your vision as a pattern and give more details there.

    And I never said anything wrong about structured programming, it's just the mix and confusion that I can't understand.

    By the way, CORBA is a OO model where you have a lot of data being passed around. So "everything is an object" does not hold .
  41. Dependent Session Objects[ Go to top ]

    Ghari, Quin, Others....

    Could you please explain, with an example involving an object tree, (may be you can use Customer -> Account(s)-> Transaction(s)), using "Session Wraps Entity" patterrn and "Dependent Session Objects" ?

    If you highlight the problem with the "Session Wraps Entity" pattern and then, highlight the benefits of your method, we can easily understand why you are doing the way you do, clearing the confusion we have.

    As we all know, every project situation is unique and with J2EE/EJB, there are numerous combinations of design possible. While it is easier for you to see your design, it is not so easy for others to follow without concrete examples and detailed write-ups.

    Is this because you guys have not yet thought about the "Detailed" design?

  42. Dependent Session Objects[ Go to top ]

      If business logic belongs in Session Beans , why do you need facade/adaptors and you can't use Enity Beans directly ?
    Isn't that the whole point? Allright, let me stop and wait for Ghari's input...
    CORBA is a OO model where you have a lot of data being passed around. So "everything is an object" does not hold
    What you mean? Please help, any good Romania intepreter:-)
  43. Dependent Session Objects[ Go to top ]

    With CORBA, what I meant is that except for:
    - object references which are rare cases anyway
    - Objects By Value, which has beeing pushed mainly for political reasons (namely interoperability with EJBs and RMI in general) and has not been widely adopted as far as I know

    all other parameters you pass in method invocations (let's say >95% of the cases ) are not objects.
    They are either primitive types or composite structured types (struct,enums,arrays and all the combinations).

    So it is obvious to me that in CORBA not everything is an object.

  44. Dependent Session Objects[ Go to top ]


    Maybe this is indeed a useful pattern, but the way it has been documented so far is not really the way to present it.

    The key advantage I understood so far is the smooth design of large object models and implementation by big teams.

    If you have time, it would make sense to present a real-world example, such as the one suggested with Customer-Account and compare it to the "Session wrapped Entity" option.

  45. Dependent Session Objects[ Go to top ]

    I completely agree with you. It seems that the main problem with this proposal(pattern?) is that the author(s) have not thought through the details and is not coming up with any detailed design information for our requests.
  46. Dependent Session Objects[ Go to top ]

    Cosmin, Quing, Ghari :

    I like to give a lot of thanks for your discusion about this pattern, but i think that you must explaint it beter.

    I dont't know anything better than an example.

    If you like to do a really good contribution to the comunity, please make one with the really know example Customer-Account .

    I think everybody regards you.

    Thanks an pardon for my english.
  47. Dependent Session Objects[ Go to top ]

    Agree. The purpose of CORBA is to allow access to remote 'objects'. If you are using C (or any other procedural language) a function can be exported for remote access; at a higher level it appears as an object, but it really isn't. Invoking that remote function will result in data - not objects. CORBA is not just for OO languages ...
  48. Dependent Session Objects[ Go to top ]


    Use of "fine grained" entity bean is definitely not a good
    idea. Some of the things you point out are due to the
    limitation of current EJB implementations and will improve
    as the technology become more mature.

    I think your statements about CORBA is misleading..what you are saying is RPC.As a matter of fact, I have yet to see a CORBA implementation that support C language binding.
  49. Dependent Session Objects[ Go to top ]

    I agree that fined-grained entities are not a good idea; maybe what I said was confusing. I was just making the point that entity EJBs in a simple world were designed to represent the OO paradigm "object = data + behaviour", but due to object/relational mapping issues this does not work well in the real world. EJB purists will have you believe that data-related business logic should be encapsulated in an entity EJB, and that's how they were designed - it says so in the spec, but I don't necessarily agree with the implementation.

    As far as C language bindings in CORBA orbs go, I've seen and used plenty, although as IDL was based on C++ production orbs tend to support C++ bindings more naturally. I was merely highlighting the fact that CORBA can be used successfully by non-OO programmers. And isn't CORBA just the next-generation RPC with an object model and services thrown in? It achieves the same thing at the end of the day.

  50. Dependent Session Objects[ Go to top ]

    As far as C language bindings in CORBA orbs go, I've seen >and used plenty..

    which one? Just curious.
  51. Dependent Session Objects[ Go to top ]

    I think the point Costin is making is that the fine-grained entity EJBs should be implementing the business logic, just as their design intended. Indeed, this is the only reason I can think of for the existence of entities at all: associate the business logic required by the data in the same context. CMP allows developers with no relational experience to easily implement this business logic. Otherwise they are heavy-weight objects - I personally think CMP entities simplify data access, but provide little further benifits. The approach to using session beans as a facade to entities is a common one nowadays. I prefer to use JDBC/SQL in session beans, and use entity EJBs in projects that are relatively small and require quick time-to-market. In my experience entities don't perform well in large scale implementations - organisations get around this by throwing hardware at the problem, which is obviously not the best solution.
  52. Dependent Session Objects[ Go to top ]

    Hi, Ghari

    Something missing from your argumentation is the need to implement the business logic as a Java dependent object hierarchy. Does this mean that the analysis was a generic OO analysis, without considering the final infrastructure that it will run on ?

    It may make perfect sense. One problem I see with the EJB containers as they move to the back-end of the enterprises is the fact that their roots are rather in a web-based architecture. They cover very well all the web-centric issues, but tend to have weak points in the back-end, where they have to compete with other models which are proven by history...

    On the other hand, I think it is a bit over optimistic to build such a complex system as you describe without considering the package / framework it is going to run upon. Either you had to consider your own set of framework services (security, transactions, persistence etc.) in your model, or you built just on the problem domain entities without considering the final application domain.

    I saw CORBA systems implemented in Java but I don't think they are any better in terms of the methodology and conceptual support for the designer. It either maps nicely to your domain analysis, or in the end it looks just like a bunch of hacked-together interface implementations and a web of interdependencies.

    So, I would argue for the early consideration of the target framework in the design rather than starting as in the text-book OO "green-field" implementations.