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 metadata
could 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]
