Just a quickie (more later) I still really like the phrase "separation of concerns" (not out of date yet I hope).
I think it should be used more in conjunction with the phrase "reintegration of concerns" I'd love to see Cocoon become the perfect instrument for separating and then reintegrating concerns, and I think this RT is a good step towards this. What I'd really like to see would be _comprehensible_ reintegration of concerns (check the aspectJ/HyperJ syntax for this - v bad; eg looking at a piece of code, you're not told whether some aspect/concern area applies to it). Only one logical conclusion AFAIcan see...C3 is going to be a literate programming system. Written in C2! Allan -----Original Message----- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Sent: 03 February 2002 15:35 To: Apache Cocoon Subject: [RT] Componentizing Cocoon Applications Cocoon is currently a publishing framework, meaning that is somewhat more powerful for stateless resources than for stateful ones. I strongly believe that Ovidiu's work on Schecoon will (sooner or later) bring balance to this picture, allowing Cocoon to be as powerful with stateful resources than it is today with stateless ones. This considered, the concept of 'cocoon application' is to be extended to include all possible sums of stateful and stateless resource serving. These RT are based on the assumption that the above is true and try to address the future needs for cocoon application design, programming, debugging, refactoring, maintenance, installation and deployment. - o - Cocoon has been described as a 'framework', a 'pipeline engine' and even as a 'web operating system'. While one can disagree with these metaphors, one thing is common between these descriptions: cocoon runs your applications. Well, to be honest, today Cocoon runs 'one' application, or, in some circumstances, a disorganic collection of independent applications sharing the same URI space. This reminds me of the trend that appeared on software system: the first systems were monolithic monotasking environments, then started to appear multitasking environments, preemptive multitasking (IoC anyone?) and more recently, component based environments and distributed component based environments. In order to grow architecturally, I strongly believe that cocoon must allow (not force, allow!) the componentization of the applications it is capable of running. Why this? in order to allow easier reuse of modules, both in different applications running at the same time, both in different applications developped in different times. I also believe that Cocoon should wait to enter the 'distributed' realm until this componentization effort is finished. Doing it *before* might be extremely dangerous (this is the same pattern we followed for Avalon: get strong locally first, then think of growning distributed) - o - Cocoon is an avalon application and avalon applications are componentized and avalon forced you to design your applications thinking about the components that make it up. I would like to do the same with Cocoon applications, just at another level: Avalon concentrate on modularizing the programming logic, Cocoon must induce cocoon application designers (I can't talk of programmers since it should not be a programmer to design a cocoon application but an entire team sharing different concerns) to modularize their stuff. But how is a component model for cocoon applications useful? 1) components can be defined behaviorally: in Avalon, if you need a Store, a Logger, a ThreadManager, a Clock, etc... you just ask for a component that performs that 'role'. Avalon takes care of everything else, just hands you the component that you need to do your job. In short, it reduce concern overlapping between the composer (who uses the component) and the component. I would like the same to happen in Cocoon: a webmail written as a cocoon application will require user authentication and authorization, mail transport facilities (both to IMAP and to SMTP), skins, a persistent repository for user preferences, a persistent repository for addresses or a connection to the addressbook storage (LDAP, for example), a connection facility with the server side filter engine (Sieve, for example), etc... Being a programmer (like it or not), the 'axis' I use to componentize a web application is normally the functionality (the logic concern realm). My personal experience tells me that this is almost never the case for other types of individuals: graphic designers will divide components depending on graphical attributes, wording editors will divide components depending on verbosity and other word attributes (informative, activity, indications), usability engineers will divide components depending of the complexity of their flow. The question is: since these diffenent componentizations *always* cross-cut, can Cocoon make it possible to have all these coexhist? I believe so. The only price to pay is an increased number of contracts between the different realms and a consequent higher frequency of redesign and refactor (which might also turn out to be healthy) Let's make an example: suppose you have three concern realms A,B,C each with a different 'component' view of the problem and some overlap. A [ | | | ] B [ | | | ] C [ | | | | ] the idea is to have a higher granularity of componentization [ | | | | | | | | ] and then somewhat glue togheter the components in the same realm A [ * * * | | * * | ] B [ | * | * * * | * ] C [ * | * | * | | * ] An example of such a 'glue' is content aggregation: things that were componentized at the 'logic' level are glued back together at 'content' level. The drawback is that we have a higher number of 'marks' in the picture (both '*' and '|') and each one of them is a contract, so eventually requiring changes and possibly impacting more than one concern island. - o - Now that we have identified the theory, let's try to dive into the practice. Suppose we have a simple web site and we want to make it skinnable. We decide to have a higher order modularization separating 'content' from 'style' and using the markup schema and the location of the sytlesheets as a contract between the two components. The flow of composition is that 'content' requires a 'skin' in order to be functional. So, we have component 'MysiteContent' that implements 'Content' and requires an instance of the component 'Skin'. We deploy 'MysiteContent' on top of Cocoon, indicating where we want to mount it (let's say '/' which is the root of the addressing space handled by Cocoon). The deployment descriptor of 'MysiteContent' will indicate that it requires an instance of 'Skin' in order to operate. Cocoon will prompt for a list of components that implement the 'skin' role and allow you to choose between them. if none is present, you will be asked to provide one. Of course, this is just an example of functionality: it could be entirely possible to deploy an entire application with all the required components inside, but this is just implementation details. But what does it mean, in practice, that the 'CoolSkin' component implements the 'Skin' role? Let me make a sitemap example to see what I envision: <match pattern="*.html> <generate src="docs/{1}.docbook"/> <transform src="[skin]://docbook/docbook2html.xslt"/> <serialize/> </match> where the absence of 'protocol' information indicates that the component should look into its internal addressing space, while the [***]: virtual protocol indicates that you should connect to the implementation of the 'skin' role that you have choose at deployment time. So, what is the contract here? the location of the stylesheet in the internal addressing space of the 'skin'-implementing component. The above gives us: 1) complete separation: components are totally independent as long as their contracts are not touched 2) polymorphism: I can have multiple implementations of the same role and decide (even at runtime!) what to choose. 3) total reuse across different apps: I could use the same module for different installations and webapps (think of authentication/authorization module Last but not least, these components must have the ability to install new java components into cocoon without having to modify the cocoon installation. if a webapp requires a special hand-written transformer, this should be installed along with the deployment descriptor and might even be little as having one cocoon app component as one cocoon component. Ok, enough for now. Awaiting for your comments! Ciao -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
