OSGi

[Peter Kriens <Pe...@aqute.se>]

The Avalon framework seems to address the same area that the
Open Services Gateway Initiative (OSGi, www.osgi.org) addresses. This work,
which started as one of the first JSRs in 1998, has
resulted in a comprehensive specification for a services framework
initially targeting the home network/automation but became much more
horizontal in the past 2 years.

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).

There are already several open source versions in the making, search on
www.sourceforge.org for OSGi. OpenSugar (a member) promised last week on the
OSGi world congress to submit their framework for compliance after
which they will make it OSS as well (www.objectweb.org).

The result is component framework that is applicable in many different
areas. Some of these areas can be found in http://www.osgi.org/about/OSGi_Fact_Sheet_SeptFINAL.pdf
So far, 11 companies, among which the big guns like IBM and SUN, have a
compliant framework including the optional services. The spec has been
serious work by very experienced people over a significant amount of
time. with many f2f meetings The feedback that technical people
give about this spec is almost without exception very positive.

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.

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 :-)

Kind regards,

   Peter Kriens

-- 
Peter Kriens                              Tel. +46 30039800
Finnasandsvägen 22                        Fax. +46 30039805
SE-43933 Onsala                           Mob. +46705950899


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re[4]: OSGi

[Peter Kriens <Pe...@aqute.se>]

I admit that I did not have a thorough look through the Avalon code
and are still a bit overwhelmed with the jargon I encounter. However,
I assume I do the same thing to this group :-)

I will try to have a deeper look into Avalon during the weekend so I
could come up with some kind of idea how to OSGi could fit
in/on Avalon.

PD> I also seem to recal that OSGI also defined a set of "work" interfaces for
PD> services such as HttpServers and like.
We have developed well documented interfaces for the
following areas in R2:

        - Logging
        - Http service (it is trivial to include servlets in the
          bundle)
        - Remote management of Java permissions and Java packages
        - Device Access (loads code on detection of external devices)
        - Configuration Management
        - Preferences database
        - User Admin
        - Metatyping

In R3 (due somewhere early next year) the OSGi alliance probably adds interface
specifications for:

        - Wire Admin (a dynamic component wiring model)
        - Dynamically extending URL stream and content handlers
        - Communications and messaging where bundles provide
          difference schemes.
        - Finding a suitable XML parser
        - Start and shutdown ordering
        - Measurements, Position
        - Jini
        - UPnP

PD> However I think you will find that the legalese and licensing will be the
As said, I am not a lawyer, neither do I want to become one. The way I
understand it, it is possible to implement the spec without any
licensing. Obviously, there may be unknown patents involved in the
spec, but the same can happen to your current work. It is today
impossible to write software without infringing on someone's IPR. For
the OSGi specs, at least the members have not declared any IPR on the
specifications. Anyway, if there is some technical enthusiasm we
should get lawyers involved.

I think it is in the OSGi's interest to get a group as Avalon
involved. I can try hard to make this impossible because I think I
understand why OSS developers are not going pay for this :-)

-- 
Peter Kriens                              Tel. +46 30039800
Finnasandsvägen 22                        Fax. +46 30039805
SE-43933 Onsala                           Mob. +46705950899


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Re[2]: OSGi

[Peter Donald <pe...@apache.org>]

Hi,

Don't worry I don't think it came through to the list because it was too big 
or something. I wouldn't mind seeing a copy of this aswell if you got a URI 
or can send it to me ;)

I have looked at OSGi before. I actually spent a couple of weeks going through 
OSGi, HPs CSF and comparing to Avalon ages ago. I am probably going to have 
another look at OSGi but probably wont have a chance to do it justice for a 
week or so so don't worry if there is no response for a while.

Anyways, from my memory OSGi actually is a slightly different style of 
framework and solves a lot of problems that Avalon has yet to handle (ie we 
have no consistent deployment or library format, nor do we have standards for 
native librarys access). 

It would be great to see Avalon adopt a format that was at least interoperable 
with OSGi. IIRC OSGi had ServiceFactorys for each bundle that would allow 
"foreign" component models like Avalon to be exported from a Bundle.

Avalon currently does not have the infrastructure to gracefully support OSGis 
Bundles. However it is likely that our next generation architecture will be 
able to use OSGi bundles as easily as current Avalon code. It would be an 
interesting exercise to support it. 

I also seem to recal that OSGI also defined a set of "work" interfaces for 
services such as HttpServers and like. Depending on their exact 
characteristerics they could definetly be useful to us (Lack of such 
interface specifications was actually discussed on Phoenix-dev today).

However I think you will find that the legalese and licensing will be the 
major block to adoption. RAND patent licensing effectively cuts off our 
ability to implement something. Inability to aquire TCKs except by forking 
out $ is also a problem with most of us as many of us work on Apache stuff 
out of our own pockets. Inability to participate in specification process 
except by forking out $ is another feature that is likely to discourage 
adoption.

-- 
Cheers,

Peter Donald
*------------------------------------------------*
| You can't wake a person who is pretending      |
|       to be asleep. -Navajo Proverb.           |
*------------------------------------------------* 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re[2]: OSGi

[Peter Kriens <Pe...@aqute.se>]

Excuses for the large file. The main mailing list I use has a reply to
the sender and CC to the group which meant I replied to send Leo
Simons the files he asked for.

Hmmm, bad start :-)

Kind regards,

     Peter Kriens


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: OSGi

[Leo Simons <le...@apache.org>]

<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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>