I don't think Avalon is a competitor to Turbine. Here's why. Avalon's mission is stated as encompassing all of software engineering whereas Tomcat/Turbine is focused on Servlets/Web-Apps. One of Avalon's main technologies is Phoenix, which it describes as a Services Kernel. It can be compared/contrasted with Tomcat. Tomcat is also a Services Kernel, but it is a Web Services Kernel. Phoenix's kernel is not limited to Web Services. Consider the fundamental architecture consisting of two pieces: a Service Layer(Kernel)/Block(User). Just like Unix has two modes: Kernel / User. In Tomcat, the Kernel is a Web Service Layer and the User is a Web App (ServletContext). In Phoenix, the Kernel is a general Service Layer and the User is generically called a Block, of which there can be many types. For example, HTTPServlet Block, SOAPServlet Block, SMTPMailet Block, Bean Block.
Avalon's services/user architecture, similar to HP's e-speak, is envisioned as a hierarchy of [service kernel / user block] layers. What it seeks to provide is a set of patterns (Framework) and reusable components (Excalibur) that can be shared across service/user layers and across blocks (user types?). So how does Turbine fit into this? I think simply by taking the Web-App "Block" and introducing a Service layer designed to make Web-App programming convenient inside what Phoenix would call an HTTPServlet Block and Tomcat would call a Web-App. So really it is to do what it is already doing with TurbineServices (Fulcrum) but using the patterns/toolkits of Avalon's Framework and Excalibur. Since it will run in Tomcat, it cannot really be an Avalon block since those are based on Phoenix. So right now all of the frameworks out there now are what I would call basic Kernel frameworks. HTTP-Servlets/SOAP-Services/EJB all are Kernels with its corresponding User "Block". None take things to the next level and decompose the User block into further refinements of Services. Turbine/Fulcrum does this and that is very important. So really it is not much different than what Turbine has been doing. A radical change would occur if Turbine wants to promote a good Servlet block in Phoenix (they're using Jo I believe which appears stagnant??) and work directly in Avalon, which it doesn't appear you have any intention of doing. But I think I agree with you that T3 should be firmed up because I got into this because of Scarab and as a potential Scarab user, I am frightened by all of the Turbine changes. I hope this is an accurate picture. I've been studying it all week. Pat Monardo -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Henning P. Schmiedehausen Sent: Thursday, July 25, 2002 10:14 AM To: [EMAIL PROTECTED] Subject: Re: Turbine 3 direction James Taylor <[EMAIL PROTECTED]> writes: >On Thu, 2002-07-25 at 12:38, Henning P. Schmiedehausen wrote: >> Daniel Rall <[EMAIL PROTECTED]> writes: >> >> >> You have many services that we don't yet have, and IMHO we could make >> >> a common repository for these Components... >> >> >+1, a common repository would be useful. How about a >> >jakarta-avalon-components module in SVN/CVS? >> >> Hm, >> >> while the idea is cool, I'd prefer to get the fulcrum stuff to >> actually work with T2 and T3 and then migrate a stable code base. The >> current fulcrum code base is "preliminary" at best... :-) >> >> Please allow us to make at least one Fulcrum release before migrating >> to yet another platform... >I'm a little confused about the direction of fulcrum right now. My Just like all of us. :-) >understanding was that Turbine 2.2 is going to be released _without_ it >(just decoupled torque, not other services), and we've been talking >about Turbine 3 using Avalon for its component needs. Yes. Turbine 2.2 will be with coupled services in o.a.turbine.services. It will work without Fulcrum. You can, however, use Fulcrum as a component with the ComponentService ( :-) ) and then use the fulcrum services with the T2 framework. T3 currently has no own services and uses Fulcrum. There is no T3 and no Fulcrum release yet, so I'd like to see a Turbine 3 release and a Fulcrum release to get a stable base for post-T3 development. ATM there doesn't seem to be too much T3 development at all, because all of the main developers went off to other projects. T3 needs the pipeline polished and documented so more people start using it. After this release (T 3.0), we should decide on a direction, where to go with T3 and Fulcrum. Some developers seem to prefer that T3 should be "service compatible" with avalon (which in my limited understanding seems to be a generic application framework while Turbine is a supercharged servlet). So T3 will be some sort of "avalon light for servlet based applications"? Fine, as long as we don't scare the current Turbine users away. Personally, I'm a little scared about "being run over by Avalon". :-) And in search of docs, I'm upset by links like this: http://jakarta.apache.org/avalon/phoenix/what-is-a-block.html ... %-) (So, can anyone actually tell me what a block really is?) >Thus, my expectation was that fulcrum would be disolved, and the >services there that need to / should be retained would be converted to >components for Turbine 3. ATM I don't see no reason why any component of Fulcrum should be dropped. Maybe the db service, because it is no longer necessary. Personally I'm more interested to give people already using T2.1 and wanting to migrate to T2.2 and T3 an easy way to go ahead without having to rewrite large gobs of their code. Small changes, fine. Large changes, there we need migration pathes. >Am I off base here? No. I think the Avalon Framework ideas are really cool. I just consider them much "larger" than the Turbine framework project. And I don't want our small user base being flattened by it. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
