Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Component-based architecture in Perl

by kvale (Monsignor)
on Jul 05, 2005 at 19:20 UTC ( [id://472570]=perlmeditation: print w/replies, xml ) Need Help??

There is a good article in the July issue of Software Development, entitled Thinking in Components by Ted Neward. It describes how components are a fundamentally different entity than classes, and advocates design principles for components that go beyond those used for class-based development. Here we ponder components in Perl development.

In the Java world, components are a set of (usually) tightly coupled classes coupled with a standardized API for the component itself. This API allows components to interact with each other in a standard way: initialization, registration of functionality, reflection, etc. The component idea is a next natural step in the hierarchical organization of a program:
  • statements group into blocks
  • blocks group into functions
  • functions group into classes
  • classes group into components
At each stage in this hierarchy, some data is hidden and/or encapsulated and there is some API to be used in programming the next higher level in the category.

What Perl components might be out there? At first I thought of the Tk set of modules for GUI development; those modules are surely a tightly-coupled set of classes. But the Tk API is very nearly a linear superposition of the individual class APIs, with no component level API in sight. Perhaps a better example is the set of POE::Component::* modules in the POE distributed computing framework. In POE distributed computing takes place by means of agents running on (usually) separate machines and interacting according to a common standardized protocol. In the Java parlance, the agents correspond to components with the protocol as a component API. Generalizing, web services or other service-oriented architectures implemented in Perl may effectively have components as their distributed elements.

Components are a nice organizing principle, but what can you do with them that you cannot do with classes? Well, the existence of a standardized container API allows containers to be incorporated into a program in a standard, uniform manner. This naturally leads to a plugin architecture for your program. In a program, one component is designated as a master control and serves as a container into which all other components plug in. A large application with amorphous bag of dozens of classes is transformed into an orderly set of containers corresponding the major subsystems, interacting in a uniform manner.

A well-known example of a component-based plugin architecture is the Eclipse project. Eclipse is an integrated development environment that is organized around a container into which editor, debugger, class browser, version control, etc. components are plugged in. Eclipse is highly modular and flexible. Although components were created initially for Java, components for C/C++ and even Perl are being developed.

In Perl, POE embraces the idea of plugins in the form of agents. There are other frameworks such as CGI::Application that allow for a component-based plugin architecture, but don't really require it.

If components are a reasonable idea and some Perl software is already making use of component ideas, why is there so little talk of component-based development in Perl? Is there something about Perl that obviates the need for multi-class structure? Is it just that most perl programs are below the complexity threshold needed for components to be compelling? Thoughts?

I think it would be cool for a Perl component API to be developed, akin to the Java spec, that would allow for multimodule components to be developed that would be as easy to use as CPAN modules are today.

-Mark

Replies are listed 'Best First'.
Re: Component-based architecture in Perl
by simonm (Vicar) on Jul 05, 2005 at 22:55 UTC

    I think that people tend to more often use the word "component" in cases like J2EE and ActiveX, where there's a dominant API and a standard GUI.

    Because of the many types of "plugin" APIs in the Perl world, we use lots of different names for them -- Apache modules, POE components, Mason components, DBD drivers, archivers, cache engines, etc.

    It's not clear to me what "the Perl component API" would look like -- wouldn't you need different kinds of component API for different purposes?

[reply]
      simonm ++

      The many "component API"s float around because of TIMTOWTDI.
      This means that every API differs form the other to allow the frameworks to be slim, targeted, and not so general.

      An unique API IMHO would not be so used because everyone would have to have the same mindset, or if it would allow for TIMTOWTDI it would be a big hard to mantain monster.
      Dodge This!
[reply]
Re: Component-based architecture in Perl
by perrin (Chancellor) on Jul 05, 2005 at 20:19 UTC
    Most CPAN distributions are components. They don't have a standardized API for running inside a container, but there is no standard container for perl, beyond maybe CGI/mod_perl/FastCGI.
[reply]
Re: Component-based architecture in Perl
by Jenda (Abbot) on Jul 05, 2005 at 19:37 UTC

    I guess ... in Perl you generaly have ten times less classes to do the work so there is less need to group them. Quite often what the Java folks would solve by a bunch of classes in Perl would be just one class whose methods accept some hashes and arrays, instead of forcing you to create the right kind of object before you can call the main object's method.

    Or maybe I'm just missing something.

    Jenda
    XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.

[reply]
Re: Component-based architecture in Perl
by Transient (Hermit) on Jul 05, 2005 at 20:21 UTC
    If I'm reading this correctly (as the terminology always seems to evade me) you're talking about specific design patterns. Request objects, transfer objects, interface design and abstraction.

    For instance, a controller class that handles incoming requests that are sent via a request object and passed along to an instantiated class (with the same interface) which handles the actual work and then returns a transfer object which is passed back to the client.

    Perl doesn't really need that many layers, or, more truthfully, it already has them. You can define hashes (or particular objects) to be transfer and request objects, dynamically instantiate and pool particular instances of that class, process it, manipulate the hash and return it in a specified way.

    There really is nothing new to component-level design, it's simply a new word on a practice which became more acceptable when OOP (and Java) elevated itself past the necessity to make "lightweight" code. It's quite memory-intensive, but highly maintainable and flexible.

    True "components" or "containers" in Java are really just lifecycle maintenance shells to be able to do things like having pools of objects available. (e.g. Avalon)
[reply]
Re: Component-based architecture in Perl
by crenz (Priest) on Jul 05, 2005 at 20:02 UTC

    I'm not quite sure how useful the component approach is, but that might be because I might not have fully understood it. If you have classes that all behave the same, aren't they subclasses of a common parent? And in that case, I can treat them all the same (where they share the same interface of the parent). So why is there a need to handle this case specially?

[reply]
Re: Component-based architecture in Perl
by qq (Hermit) on Jul 06, 2005 at 13:54 UTC

    And don't forget perl6 Roles, which will do a lot to break up class based design.

[reply]
Re: Component-based architecture in Perl
by zentara (Archbishop) on Jul 06, 2005 at 12:08 UTC
    I thought of Data Munging with Sprog when I read your post. Of course it could be much more powerful if Sun was behind it. :-)
    I'm not really a human, but I play one on earth. flash japh
[reply]

Back to Meditations

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?

www.com | www.net | www.org
Node Status?
node history
Node Type: perlmeditation [id://472570]
Approved by coreolyn
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? • Last hour • Other CB clients
Other Users?
Others scrutinizing the Monastery: (6)
As of 2024-04-20 02:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found