I ran into an issue using Business Delegates (BDs) at the last place I worked, and it left me wondering if this
pattern is usable at all.
In our situation, we had
EJB developers writing an EJB layer for several different front end clients (each developed by a separate group of non-EJB developers). Now, as I understand it, one of the main advantages of using the BD pattern is that the front end developer doesn't need to know a lick about EJBs, how to look them up or work with them. This implies to me that the EJB developers should be the ones to implement BDs, and these BDs should be packaged in the EJB client jars and distributed. This also makes sense because each EJB accessible to the client has a corresponding BD, and each front end client doesn't have to write and maintain BD code that does essentially the same thing.
Here's the problem, though--by providing the BDs that do all the JNDI lookups, the EJB developers are mandating that all of the front end clients have their environment set up in exactly the same way. What if one client is using a different initial context factory than another, and they require different configurable information provided in different env-entrys?
To overcome this problem, we had to move the BDs out of the client jars and onto the front end. Now we have front end developers writing the BDs, and suddenly they have to know how to deal with EJBs anyway.
So, did I miss something, or do BDs actually rely that the declarative configuration set up in the client-side deployment descriptors be the same for all clients? Forcing this requirement onto different clients is not always possible, and even when it is, it doesn't provide the degree of decoupling that ought to be present in a robust distributed system.
I can't help but feel I must be missing something here...any thoughts?
sev