At 11:19 PM 10/26/2001, Matthew Kennedy wrote:
>J2EE uses a component model that builds on CORBA. I have been wondering
>what P5EE should be built upon. I think CORBA is a natural fit for this
>as long as all the CORBA details can be hidden. ORBit or Mico could be
>used (ORBit might be the faster). Both have corresponding Perl bindings
>in CPAN.
I don't know if the Perl CORBA library bindings actually support all the
CORBA features quite so well and would make the mismatch quite obvious if
we actually started using them.
The last time I played with CORBA Perl was 2 years ago though and back then
it was quite the rudimentary thing in Perl. Has there been advance in CORBA
+ Perl?
>Another approach might be SOAP, though HTTP for communicating between
>components seems like a step back in performance/scalability IMHO.
SOAP is not just HTTP.
>Regardless, I think a good CTM is very important for P5EE.
I'm a bit ignorant. What is CTM stand for? Core Transport Model?
>Opinions?
In principle I think this is a correct thought. If you look at Java
evolution, first there was the key ability to develop multithreaded network
servers easily, serialization (we have this in Perl), then RMI (Java
specific communications) which uses the prior two features.
Likewise, I would see the core of P5EE being serialization (Whcih we have),
a good base Daemon framework for building a server and a client that
communicate using Perl serialization.
Then, to plug on top of that mechanisms for adding CORBA and SOAP bindings
easily so that a given Perl server can easily expose it's API as services
instead of just an application server.
Likewise, the transactional, messaging and servlet container stuff could
just be enhancements in the Perl daemon. The Perl daemon could optionally
sit on top of another transport layer (eg as a plugin to mod_perl on Apache
instead of using it's own).
Later,
Gunther
