2 EJB or not 2 EJB?
The question is really not so simple. Many things have proven to be myths:
- EJBs are inherently slow. Slow means nothing in programmer's world and given a server cluster with a high load of users I want to see your JDBC code performing this well
- EJBs are buggy. Not anymore - the technology has matured.
- EJBs are difficult to debug - not really. But not as simple as plain Java standalone code.
- there is not enough functionality in EJBs that I need from my persistence layer. This is true. If you are absolutely sure there is not enough, you might be right.
Because EJBs in particular and J2EE as a whole follows 80-20 rule: try to satisfy 80% of the programmers out there, while 20% will wait. Who are these 80%-people? I have no idea, but it seems to be they are not satisfying half of the real world customer requirements simply because there is no feasible way to implement it in the current architecture. I know, I know, it is a bold statement and you want examples. Ok. Customers (almost all of the customers) want customizable EJBs. By that I mean they all have their own idea on what is an entity. If it is a user demographics, every customer wants a different set of properties. Like some want pet's name while other's want the buzz number and no wanna hear about pets. What is worse, they want to be able to decide later, what they want to persist. I am not saying there is no way to implement it with J2EE. But either way looks ugly.
They also want off-site synchronization with a central storage. At least with their PDAs and notebooks. And there is a requirement for the whole thing to be 100% secure with paradigms worth starting a new branch of mathematics. As an example: the creation date of the record should not be visible to the user, if he has lower security marking than the topmost folder that holds this record. Here security markings are 'public' - 'confidential' - 'secret'. And the requirement is not stated just for UI, but for possible third-party components as well.
I am probably too negative. In fact, I like J2EE. And I like EJBs. But even EJB 3.0 is far from the cutting edge. At least if one talks to the customers. It looks more like a teenager for the job where I need a senior professional. My problem is - Hybernate does not pretend to be a senior professional. It is free, it is simple and powerful to the extend, but it remains a library one will or will not use. EJBs, however, pretend to be THE way to think, while in reality they are not flexible enough.
Anyways, next time I should start with Tiger. The J2SE 5.0. At least there I will be positive :)
- EJBs are inherently slow. Slow means nothing in programmer's world and given a server cluster with a high load of users I want to see your JDBC code performing this well
- EJBs are buggy. Not anymore - the technology has matured.
- EJBs are difficult to debug - not really. But not as simple as plain Java standalone code.
- there is not enough functionality in EJBs that I need from my persistence layer. This is true. If you are absolutely sure there is not enough, you might be right.
Because EJBs in particular and J2EE as a whole follows 80-20 rule: try to satisfy 80% of the programmers out there, while 20% will wait. Who are these 80%-people? I have no idea, but it seems to be they are not satisfying half of the real world customer requirements simply because there is no feasible way to implement it in the current architecture. I know, I know, it is a bold statement and you want examples. Ok. Customers (almost all of the customers) want customizable EJBs. By that I mean they all have their own idea on what is an entity. If it is a user demographics, every customer wants a different set of properties. Like some want pet's name while other's want the buzz number and no wanna hear about pets. What is worse, they want to be able to decide later, what they want to persist. I am not saying there is no way to implement it with J2EE. But either way looks ugly.
They also want off-site synchronization with a central storage. At least with their PDAs and notebooks. And there is a requirement for the whole thing to be 100% secure with paradigms worth starting a new branch of mathematics. As an example: the creation date of the record should not be visible to the user, if he has lower security marking than the topmost folder that holds this record. Here security markings are 'public' - 'confidential' - 'secret'. And the requirement is not stated just for UI, but for possible third-party components as well.
I am probably too negative. In fact, I like J2EE. And I like EJBs. But even EJB 3.0 is far from the cutting edge. At least if one talks to the customers. It looks more like a teenager for the job where I need a senior professional. My problem is - Hybernate does not pretend to be a senior professional. It is free, it is simple and powerful to the extend, but it remains a library one will or will not use. EJBs, however, pretend to be THE way to think, while in reality they are not flexible enough.
Anyways, next time I should start with Tiger. The J2SE 5.0. At least there I will be positive :)
