Well, my "all about the enterprise" friend, this is only somewhat true. Beans, by definition, are a java contruct. They are classes that can theoretically be reused and are 'easy' to connect to. EJB's are an extension of that which adds persistance among other things.
Beans have the capability (given the correct container to run them in), to connect to other languages via CORBA/IIOP. So, essentially we do not require 'beans'. In order for this idea of modules to connect to outside programs (someone likened beans to modules, and that is about the closest perl construct) we need a CORBA implementation (there probably already is one) and a handler series in order to make things work smoothly.
| [reply] |
Well, as a Perl programmer, I really dont know about Java's EJB. If you could give a short summary of what it is, how it works, and its benefits, I would be in a better position to comment.
| [reply] |
JavaBeans are very simillar to Perl Modules. They are small pieces of code that are maintained separately and usually serve a simple purpose. For example, say I have a web page that accesses a database. I can put all the specifics for that database conection in a bean. Now my web page can use JSP to run that code without having to know/expose the details of the database connection to anyone. You can accomplish the same goal by writing your own modules. | [reply] |
But EJB has this design objective of location transparency.
It's based on some RPC and naming service. I don't see
a basic Perl module mechanism would be able to support
this.
| [reply] |
| [reply] |
