At 09:45 PM 10/23/2001, Perrin Harkins wrote:
>Matt Sergeant wrote:
>
>>OK, so what are we missing?
>
>
>Based on the comments I've seen here over the years, and some on Slashdot,
>the thing that seems to worry people the most is the lack of an obvious
>message queue API in Perl. I've seen plenty of implementations, but there
>isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order.
I think it's more than that. It's more of a general all around 'feeling' as
I've said before. It's about people and it's about the standards.
The thing about "Enterprise" applications is that there are many components
to what "enterprise" means.... J2EE compromises a lot of standards and
frameworks all in one and to read the books about them all would take
several weeks at least.
But at least I know that when I read a book on EJB, I know this is the plan
and it's stable etc... whereas someone's particular idea of a transaction
engine in Perl is just someone's idea of a transaction engine in Perl. It
may be a good idea, but it's really quite scary to build a large system
around something that may not have a lot of success stories around it.
This is why Perrin's article is so good. Because it starts getting more
high profile success stories out there. There really are otherwise not that
many about Perl when compared to Java.
And even then, let's also consider the programming base. When I advertise
for Perl programmers, they generally just know how to do Web apps and it's
pulling teeth to even get OO and Mod_perl capability. It has to be taught
after such programmers are brought in.
But with Java, it's quite rare to find a Java programmer that hasn't
programmed at least their own minimal RMI server before. I have little
doubt that this is because of the sheer amount of documentation for making
an RMI server plus the fact that it is a true "standard" so people feel
comfortable that it is supported in a large community.
Remember that my email said, I "feel" better about coding middleware in
Java than in Perl. Just as I "feel" better about coding front-end in Perl.
This is a "feeling" and isn't necessarily something that can be quantified
-- it is also about perception which is something that cannot be ignored.
And part of it is about "soft" issues like knowing that I can find Java
programmers at a dime a dozen who have done middleware coding before in Java.
I think more success stories would help. I also think official endorsement
by key members of the Perl community (eg Larry) would help certain
projects. ie I believe SOAP::Lite is now the defacto standard SOAP Library
for Perl that people would recommend anyone to use no? So why is it still
SOAP::Lite and not moved and advocated into the SOAP namespace where it
belongs and make it the defacto standard SOAP engine for Perl if it's
proven itself?
Of course, choice is part of what makes Perl fun. But fun isn't for everyone.
eg when it comes to such niche libraries as middleware tools, it's not so
fun to have choices if none of the choices are very easy to evaluate. It's
much nicer for a programmer to be able to reliably choose a tool they feel
is backed by a strong community beyond just the immediate few people who
may have done X middleware for one project or group of projects for one
company.
I really would like to see a generally endorsed P2EE project which includes
SOAP::Lite as an interoperable webservices engine, a messaging engine, and
transaction engine. Authentication engine and Session engine would be quite
useful to include as well. Oh and Moseley's (sp?) servlets in Perl project
would be a cool one to include as well. That would make it compete pretty
much head to head with J2EE.
And then success stories on top of P2EE.
Later,
Gunther
