<snip>
> The Release 2 spec can be downloaded from the web site
> http://www.osgi.org/resources/docs/spr2book.pdf (There is no licensing
> involved). The next release, that is focused on the car industry but
> contains many more horizontal (optional) services (twice as much
> text), is due Q1 2003. It will likely add a component wiring model,
> start levels (similar to run levels), communication service,
> Jini, UPnP, architectures, positioning, measurements,
> xml parsers, namespace, and much more. A technical introduction can be
> found in http://www.osgi.org/news/osgi_news/marples_layout.pdf. There
> was also an article in Java Developers Journal this year called "The
> last mile of software deployment". (If you are interested, I can send
> you the PDF).
yes please =)
<snip>
> Why am I telling this? I would like to ask the Avalon group to take a look
> at the OSGi specification and see if some form of compatibility is feasible.
>
> I had a prior discussion with Leo Simons before this mail and I understand that are
> many legal concerns. Strangely enough, all his non-technical arguments
> were exactly the arguments that caused the OSGi specification to leave
> JCP and become an independent consortium. The OSGi members are very
> concerned for specifications that will contain licensed IPR and the whole
> structure of the OSGi is based on equal membership, statements of
> work, and a requirement to claim IPR to a specification before it is published.
I took a look at all the IP docs and long licenses on the OSGi site.
After a little discussion on this with Peter Kriens, I am quite puzzled!
It'd be cool if one of y'all could figure it out and offer insights.
> However, I am not a lawyer and the legal issue would require some
> of those. But maybe we can first have a technical discussion before we dive
> into the politics and legalities?
>
> About me. I have been heavily involved in the technical work of these
> specifications since 1998. However, I sent this mail personally, not as an
> OSGi representative. I am very interested in getting the specs implemented in
> Apache code. Obvioulsy because I have a stake in the success of these
> specifications, but even more because I think they are good enough to be
> used much wider. So I am willing to devote time to the
> development of Avalon if it is willing to consider implementing the
> OSGi specs. I know this is asking a lot, but I think it may create a
> very good synergy that helps the OSGi with more visibility and Avalon with
> a large chunk of ready made specifications and adopters. Better, we
> would not splinter the Java world with multiple service delivery
> frameworks, though there exists at least 1 company that would not
> mind :-)
>
> So, could we have a -technical- discussion about
> having Avalon implement the OSGi specifications? If we see
> possibilities, we can get the (professional) lawyers involved later :-)
=)
I took a look at the spec PDF. For one, it is long =)
I figured I'd throw some observations into the public....
General
-------
- the granularity of OSGi is coarser than avalon's. It's basic unit is a
jar file with additional contracts, which are called "bundles"; lots of
configuration is handled in the manifest.
- OSGi is more property-based than avalon. Services export an (array of)
string(s) pointing to the service interfaces they offer (similar to a
"public final static String ROLE" in avalon)
- OSGi is based around a central registry (I think (based on) LDAP)
- the strict Component/Container/Composable separation in avalon is not
there in OSGi. There is just Services/Framework; the Framework is the
only container; any Service is also "Servicable".
- OSGi has simple event handling (ie like Swing, not SEDA) integrated
into the framework wrt lifecycle management
Avalon Patterns and OSGi
------------------------
- OSGi does not promote IoC. A Bundle is an active entity.
- OSGi promotes seperation of interface and implementation, but I don't
think formally
- OSGi performs SoC on various levels (logging, management, security,
lifecycle management etc). I think they're a little less rigorous about
it than we are
- OSGi is also a COP/SOP framework
Bundle as opposed to Component
------------------------------
the Bundle interface (w/o exceptions and contracts):
public interface Bundle
{
/* possible lifecycle stages */
public static final int ACTIVE;
public static final int INSTALLED;
public static final int RESOLVED;
public static final int STARTING;
public static final int STOPPING;
public static final int ACTIVE;
public static final int UNINSTALLED;
/* current lifecycle stage */
public int getState();
/* meta info */
public long getBundleId();
public java.lang.util.Dictionary getHeaders();
public String getLocation();
/* jar contents */
public java.net.URL getResource( String name );
/* dependency mapping */
public ServiceReference[] getRegisteredServices();
public ServiceREference getServicesInUse();
/* security */
public boolean hasPermission( Object permission );
/** lifecycle methods */
public void start();
public void stop();
public void uninstall();
public void update();
public void update(InputStream in);
}
The Framework creates instances of Bundle, and exposes these to other
Bundles/Services hosted in the framework. ie, it uses proxying. On
calling start() or stop(), a special object of instance BundleActivator
is called to handle the call, receiving a BundleContext to know how to
do so. The BundleContext allows interaction between Bundle and
Framework.
The communication flows between component<->container are more similar
to servlets than the avalon setup.
Bundle as a .sar
----------------
Bundles seem most similar to phoenix .sar archives. Internal
organisation of the bundle is structured differently from
.wars/.ears/.sars though (I think it is mostly undefined).
OSGi Services
-------------
I believe OSGi Services are not very formally defined. One marks which
objects are services in the manifest file. One has the option to provide
a factory (ServiceFactory) to handle creation of the services.
Bundles themselves register/deregister services with the framework
(through the BundleContext), providing context information through
properties.
Additional OSGi Services, Specs, Bundles
----------------------------------------
OSGi is it seems in the process of extending their specs with lots of
new functionality. For example, there's a logging abstraction. This is
implemented as a regular Service upon which bundles can have a
dependency. There's also specs for component persistency and
configuration management.
The approach is a bit different from the avalon one. We provide a bit
more 'default' functionality through the lifecycle, where all but the
very most essential functionality is exposed as services in OSGi.
How Avalon and OSGi might interoperate
--------------------------------------
One of the fundamental avalon principles, making your
components/services completely passive, ie IoC, is not used wrt OSGi
bundles. Bundles are active entities which carry out operations,
interacting with the registry. They are responsible themselves for
publishing the services they contain.
I can imagine building OSGi Bundles and services by basing yourself
around an embedded avalon container like fortress. I can also imagine
building an OSGi framework implementation on top of an avalon container
like phoenix.
It might also be possible to provide some kind of mapping between
components hosted in OSGi and components hosted in avalon, and vice
versa (just like interoperability between avalon and EJB).
All of those could be really useful =)
OSGi @ Apache
-------------
If OSGi is going to be big (and it probably will be, looking at the
level of industry support!), it probably makes sense to have an
implementation at jakarta, no doubt. If it comes to that, there will at
least be very large overlap between any OSGi implementation project and
avalon.
It'd be nice to here some comments from PK (I mean Peter
Kriens....Peter, we have quite a few of your kind here, From Peter
Donald, PD, to Peter Royal, PR. :) on how OSGi fits in with specs like
serlvet, frameworks like struts, etc?
Whether we could/would adopt the specs
--------------------------------------
Some of the design decisions made in OSGi contrast with 'the avalon
way'. The seperation of concerns at the composition/dependency level and
the application of IoC are maybe concepts that are difficult to merge
with OSGi.
OSGi and .Net Framework
-----------------------
They are remarkably similar! The shared assembly directory is like the
OSGi bundle registry. An assembly is very much like a bundle. Both are
attribute-driven.
Standard disclaimer
-------------------
Just as people always confuse the parts of the avalon project, their
role, and their intent....I've probably misunderstood at least half of
what OSGi is all about and what it does. The above is merely intended as
a discussion starter =)
cheers,
Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
