Niclas:
Just a short note to let you know that I printed out the four pages, went to
cafe, ordered a bottle of wine, sat back, and read your email in detail.
General comment - what your thinking is in scope and of interest. I'm not
yet ready to provide a constructive reply (at least not immediately) - but
I am ready to say that you should push forward on this here at Avalon. I
have a bunch of thoughts bubbling away - but way to early to do anything other
than scare you, me, and a bunch of others. The killer question is the
abstract an seperation of concerns relative to the right abstracion - but
I'm not going to go into this now because my brain would probably though an
IllegalStateException.
Cheers, Steve.
Niclas Hedhman wrote:
Hi all,
IMHO, Avalon is concentrating too much from the POV of the Container and not very much from POV of the Application Integrator (AI).
Perhaps this is so due to the perception that AI have a lot of time to create an application using the blocks available, and that he/she doesn't really need any powerful tools. I beg to differ, as I have expressed many times before.
In order to be able to create tools for the AI, we have to define a specification on how the Component Author (CA) is to package the component(s), and it is my intention with this RT to kick off such a discussion.
Eventually, once this specification is nailed down, I and/or others can start on powerful tools, not only for the AI but also for the CA. We will kill two flies in one go, so to speak.
So, what is the problem??
Avalon today is 100% about CODE and METADATA.
Avalon shy away from all kind of RESOURCES, whether they are pertinent to the Avalon context or not. I don't know if this intentional or not.
In any event, a COMPONENT consists of all of the above, and if one or the other is completely missing, it is not a component anymore.
From my perspective I see the following resources and metadata (some metadatacould be considered a resource and vice versa, so I klump them together), being fairly central to most components;
1. Naming and Identification 2. Versioning 3. Dependencies 4. LifeStyle 5. Container/Environment Requirements 6. Third-Party Requirements 7. Javadoc and other documentation. 8. Internationalization & Localization 9. Management Interface
I don't intent to elaborate on these at this point in time, but would like to mention that item 2-5 is pretty much nailed down as it is today.
Also, item 6, refers to stuff like jars/classes and resources have to be packaged into WAR file in a particular way.
Item 9, I am a little bit split over myself. Sometimes I feel that the container should be able to provide a Management Interface automatically, but how would it know what is part of management, and what is part of the components normal function. TBD.
First of all, I would like people to recognize that we actually have 3 different packages to deal with;
1. Component APIs 2. Component Implementations 3. Support Implementations. 4. Assembled Applications 5. Container Extensions
Existing examples; Example of a Component API = Generator Example of an Implementation = FileGenerator Example of an Application = A configured Cocoon instance
Imaginary Examples; Example of Support Implementation = Web interface to Calendar Example of Container Extension = JINI based lookup
I always get the objection that, for instance, the Generator is so simple that we don't need to separate it out.
Not to get too deep into that discussion again, let me just say, yes the code is simple, but look at the list above.
Component API
============
The Component API specifies the programmatic interfaces and sometimes provides some value objects, but very little else code.
It should (must), however, provide extensive documentation, javadoc and others, about the semantics, explicit or implied, of the API.
It should probably contain I18N and L10N resources where appropriate.
Component Implementations
=====================
A lot of code typically goes into creating a component.
An implementation can often reuse chunks of the Component API documentation. In fact, it feels almost like documentation should be inherited, albeit we don't have such a mechanism.
I18N and L10N are big issues.
Implementations will support one, few or all LifeStyles.
They Depend on at least its own Component API (but this dependency is different from the dependency in Avalon), but often on many other Component APIs and sometimes Component Implementations. This also refers back to Identification and Versioning.
Often the Component Implementation have many specific requirements from the Container/Environment and often 3rd Party requirements as well, such as JDBC drivers, external config file entries, user authentications and what not.
Support Implementations
==================
The Support Implementation does not implement the Component API, but provides some explicit additional service to a particular Component API.
An example of a support implementation is a Web User Interface to a particular Component API (or even Component Implementation).
Container Extensions
================
In rare occassions a Component Implementation may require a particular Container Extension to be present.
Container Extensions are slightly outside the scope of this RT, so I leave it as a special dependency case.
Assembled Applications
==================
I have been struggling with the question "Does an Assembled Application have its own code?" The argument is that you need some level of GLUE between the Components to make them work.
The counter-argument would be that, that GLUE is in itself a Component Implementation, that implements an "Application Component API".
The more I have investigated the "counter-argument", the stronger I believe in it. One would establish a few "Application Component API"s for different similar applications.
That would then mean that an Assembled Application is ONLY the components, and the "configuration" and "wiring" of these components (Merlin terms; block.xml, Phoenix terms; configuration.xml + assembly.xml ).
So where does all of this bring us??
==========================
I strongly believe that for each of the above sub-system, we need to SPECIFY a packaging format that are tool-friendly.
I have a vision, using Eclipse/Netbeans;
File->New->Avalon->Component API
All the parts that the Component API should have is managed by the IDE. I can right-click and ask for the documentation window. I can ask to create a JUnit based validation test, to be used by Component Implementations.
Tools -> View Components -> APIs
A browser to view the APIs that are available. Which versions I have. Mount repositories and download new components or versions. For each API, I can easily access the documentation, view code and validation tests.
"Component API" -> Create Implementation
The IDE creates stub(s) for me, and sets up all the I18N/L10N resources, and manages the declarations of dependencies.
"Component API" -> Create Support Implementation -> Web
I imagine that the IDE PlugIn supports a couple of standard Support Implementation systems, or even allow extensions to be plugged-in. For instance, a Web User Interface is perhaps a typical Support Implementation.
A SOAP access wrapper may be another.
File -> New -> Avalon -> Application
Allows me to pick and choose Component Implementations, and the IDE plug-in will track missing dependencies, will include the Component APIs required and package it all.
This is just the beginning of such a vision. I hope everyone can see the elegance if/when we could reach such a state.
I have started on such a tool several time, and I think others have also thought about it, and I bet the reason why it doesn't exist by now is the lack of packagin specifications. It is not possible to start on such a IDE plug-in, since there is no standard on what constitutes a component.
I hope we can spend a little bit of time defining exactly that.
1. How is a Component API packaged?
2. How is a Component Implementation packaged?
3. How is an Assembled Application packaged?
This will already give us plenty of room for fantastic tools to be developed.
Answering the 3. question first should be the easiest, since that is related to the Container where we deploy.
Well, that is not entirely true, because the container is only interested in the runtime aspect of the Application, and doesn't care about installation, versioning (of entire app), documentation and to some extent configuration handling.
Phoenix was more explicit about the packaging than Merlin is, but we need to nail this one down more precisely. Not because we need to satisfy Merlin, but to satisfy tools' need for a specification in this area.
I would like not to go into specifics about what _I_ believe to be a good packaging specification for the above 3 (I haven't been thinking too much about Container Extensions and Support Implementations), but let everyone digest what I have just written.
At the end of this discussion, I would like to see the following exit-conditions;
1. Packaging specifications for at least the 3 core packages (api, impl and app).
or
2. The community decides that this is not a concern and should not be part of Avalon core.
And in the event of 1., the follow-up question would then be, Is it in Avalon's interest to host IDE tools for Avalon development?
I hope I have provided some food for thought.
Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
