Middle Tier business logic implementation

[John Davis]

The Blueprint contains the following statement:
"In the J2EE Platform, middle-tier business logic is implemented in the middle tier as Enterprise JavaBean components (also referred to as Enterprise Beans)".
My questions is: Isn't this statement incorrect because it is too limiting? Rationale: The J2EE Platform is flexible enough to allow for a complete implementation of application business logic using the Web Container technologies (i.e. Servlet API, and JSP pages). This approach could be used whenever an application's requirements and user community are local and limited (in other words, it is not part of an Enterprise Architecture and therefore does not require universally available distributed object technology).
------------------

[Ajith Kallambella]

I think the term "middle tier" here refers to a combination of all of your J2EE server-side components and itself can be composed of many logical tiers.
Historically this term has been used to broadly identify all the application components excluding the client and DB ( that are the other two tiers ). Then they started using the n-tier term to distinguish between the components that make up the middle tier.
Just my opinion..
------------------
Ajith Kallambella M.
Sun Certified Programmer for the Java�2 Platform.
IBM Certified Developer - XML and Related Technologies, V1.

[John Davis]

True, that is how the term "middle tier" is used in J2EE. But that is not related to the problem I have with the Blueprint's statement. The Blueprint statement specifies that business logic "is implemented in Enterprise Java Beans". I contend that business logic can very well be implemented within the middle tier of J2EE without using EJBs.

------------------

[Ajith Kallambella]

Ah! okay!!
I think EJB-izing the business logic adds to the flexibility because then, it would inherit all the good things of being an EJB. Since the focus here is to make one understand the advantages of componentization( is that the right word? ) and EJB is right on the money!
Don't you think so??

------------------
Ajith Kallambella M.
Sun Certified Programmer for the Java�2 Platform.
IBM Certified Developer - XML and Related Technologies, V1.

[John Davis]

OK! Now we are talking about the same thing. But I do not agree with you completely. EJB is "not right on the money" as you have indicated. I will also refer to money. I think there is a price to be paid for the EJB flexibility you allude to. That price is in complexity (and also in the per/cpu $s for EJB containership levied by most vendors). Consider the costs associated with software developer learning curves for becoming an EJB client within a servlet. Consider the cost and complexity of EJB packaging and deployment. In my experience, EJB development (compared to simple Web Container development using servlets and JSPs) has been very complex, very expensive, and has demonstrated a long time-to-market. Also, one vendor's EJB container (I don't want to mention names but the initials are IBM) is used predominantly by very large corporations and falls suspiciously short of compliance with J2EE specifications. All in all, I recommend a simple Servlet/JSP development strategy in all cases except those which require an "Enterprise presence" where common business objects and services are accessed globally as distributed objects.
------------------

[Ajith Kallambella]

John,
I agree with you completely. EJB is certainly not a panacea and the choice of EJB should be justified, after exhausting all other possible alternatives, if someone decides to use them as a part of the overall architecture. Hype should not drive your decision process!.
However EJB can add a great amount of value addition to your system. I'm not an EJB guru, but things like transaction support, persistence management, interoparability etc. which are "in built" in EJBs take time and effort to write, if you chose to do it yourself. If you need these features and facilities EJB is worth a consideration.
Standardization and core compliance is something that I hope will mature in the next year. Given that EJB is still in its infancy these are the drawbacks of working with bleeding edge technology.
------------------
Ajith Kallambella M.
Sun Certified Programmer for the Java�2 Platform.
IBM Certified Developer - XML and Related Technologies, V1.

[Amanda Waite]

Hi John,
I think that your original post was very true. After reading some of these books it's probably tempting to go out and use EJB's for everything, tempting but not terribly practical. I feel that EJB's have a lot of value when dealing with persistence data and Transactional Processing and I don't think that you lose much of that value even if you have to manage transactions and persistence in the bean.
In the end it's important to analyse the problem and use appropriate technologies to solve it. I guess that this is what makes a good architect, someone who can use the right tool for the job and not go throwing the latest technologies at a problem just because they are en vogue.
The Blueprints book does go on from the point that you quoted to describe several scenario's that don't involve EJB's although again it might be said that these are just separate paths through the larger model that they show.
Thanks for an interesting discussion.
Amanda

[Anil Vupputuri]

Originally posted by John Davis:
The Blueprint contains the following statement:
"In the J2EE Platform, middle-tier business logic is implemented in the middle tier as Enterprise JavaBean components (also referred to as Enterprise Beans)".
My questions is: Isn't this statement incorrect because it is too limiting? Rationale: The J2EE Platform is flexible enough to allow for a complete implementation of application business logic using the Web Container technologies (i.e. Servlet API, and JSP pages). This approach could be used whenever an application's requirements and user community are local and limited (in other words, it is not part of an Enterprise Architecture and therefore does not require universally available distributed object technology).

Yep, i agree with the Blueprint..
In a middle-tier, until EJB there was no technology which provides secured high performance components.
Servlets/Jsp differ from EJB Components in that the breadth of server-side component features that EJB offers is not readily available to servlets. Servlets are much better suited to handling simple request/response needs, and they do not require sophisticated management by an application server.
U can say both EJB and CORBA share much functionality.But EJB is best suited in middle tier business logic with a better secured,transaction and persistable features and obviously with the support of RMI/IIOP ,lifts the restriction that EJB must be solely Java-based. U can expose EJB components as CORBA objects which generalizes EJB and makes it well suited for cross-language interoperability.
So EJB is a very powerful in a middle-tier.
Anil

[John Davis]

I agree with you! EJBs are very powerful! But I disagree with the Blueprint statement because it incorrectly states that
"middle-tier business logic is implemented in the middle tier as Enterprise JavaBean components"
This is untrue because sometimes the optimum design involves servlets/JSPs only for business logic implementation.
There are successful architectural patterns which utilize servlets/JSPs and (NOT EJBs!) and implement business logic. An example (taken from my own experience) is a production web application which uses servlets to control the application (receiving browser client requests and forwarding to JSPS for the replies) JSPs for the model view functionality, and existing legacy applications on IBM big iron for transaction control and persistence. In this paradigm, EJBs are not required to provide transaction control and persistence because we utilize the servlet layer as a "request-response controller" which serves as a client of pre-existing functionality on a legacy platform. (i.e. in this example, asychronous messaging is used in the servlet to queue requests to legacy apps and wait for for replies from legacy apps.)
------------------

[Michael Chang]

I think it is simply a question of how you interpret the words "middle tier". servlet/jsp are more like the server side presentation layer. They are not supposed to have a lot of business logic in it. Their main functionality is to validate incoming requests, send requests to the components(EJB in this case) that have business logic, and present the results in proper format back to the client. Unless the application is really simple, usually a real world application needs to have some business components besides servlet/jsp. That's what EJBs are for. Of course, EJB may not be the best answer in all cases.

[Tony Chen]

Originally posted by Ajith Kallambella:
John,
I agree with you completely. EJB is certainly not a panacea and the choice of EJB should be justified...
...Given that EJB is still in its infancy these are the drawbacks of working with bleeding edge technology.

I agree with you guys! And this is one of the reasons our architect didn't choose EJB for our project. But to write those good "in build" things of EJB is not easy at all! Have anyone of you guys been involved in a successful EJB solution for large enterprise application such as financial/securities system? Would love to hear a good story from you!

[faisal mahmood]

Middle tier is for the main application logic for the whole system and they are implemented using EJBs in J2EE technology.
Faisal