OSGi

[Maz]

I saw a lot of topics talking about Flex modules and how to use them along with PureMVC... but nobody has ever coined the term OSGi

I haven't used PureMVC yet but read thoroughly docs and samples.. and it appears that it is very neat and close to level of industry. For big projects it is very useful to have the separation of concerns PureMVC adresses but OSGi could come in to make Flex apps architecture even clearer, separating program functions amongst different plugins.. and seeing how those plugins talk to each other.

There is quite everything needed to do a fair implementation of OSGi with the Flex framework so... has anybody thought about that ? Is there a seperate framework for that out there ?

I believe OSGi along with PureMVC would lead to a very mature framework able to fit any enterprise need.

What do you think about that ? Any volunteer ?

[puremvc]

Hi Maz,

Pardon my ignorance of that particular technology.

I just did a quick google to see exactly what you were talking about.
I see what appears to be a good page on wikipedia about it.

Looks like a dynamic component model for Java that implements modules?

So you're suggesting we build a PureMVC based implementation of part or all of OSGi?

How compatible would the approach be with Flex Modules?

Please do post more of your thoughts here.

-=Cliff> 

[Maz]

Hi again,

Yep this technology is well known in the Java world. Eclipse IDE is based on an OSGi implementation : all the plugins mecanism, services discovery and such are done thanks to this OSGi framework.

Let me explain a bit what is OSGi. OSGi is a way to build modular applications. Those applications are made of modules... so far we are very close to the Flex modules API. But the OSGi defines a language or logic to describe those modules (descriptions known as plugins manifest). With that language you are able to say that a module can extend a program functionnality (known as an extension-point EP).. and such EP are defined in another module...

Take an example : Eclipse has a view that let you explore your project and their files. That is a view amongst many others... this view is defined by plugin. When the user double clicks on a file inside this view,   an editor for this kind of file has to be opened. Rather than defining the mapping table inside this plugin and defining all editors for every kind of file extension inside this plugin, the plugin will simply say "I can be extended by any plugin who is able to edit a file of any extension..."
And then you will be able to define as many plugins as you can... and so on...

That's really a great techno, and as you see YES it is very compatible with Flex 2.0.1 Modules... Flex Modules are rather the native-required levels to enable OSGi.
Flex modules are great but alone they are quite hard to use... What does this module contains ? Where does it fit in my application ?

> So you're suggesting we build a PureMVC based
> implementation of part or all of OSGi?

Hmm no, I am not talking about using PureMVC to implemetn OSGi. I am rather talking about extending PureMVC with OSGi capabilities. PureMVC would be MVC + OSGi. One could argue that they are not really related functionnally speaking. But when we talk about enterprise level developement and expectations, those two really make life easier... that is why I see them in the same architect toolbox.

And I am not speaking of implementing all OSGi specs. OSGi is big... Only a part of it would already be really useful.

Thanks,

Maz

[puremvc]

Maz,

We're on the same page.

Currently, behind the scenes, we're filling the repositories not only with ports and demos, but with utilities.

For instance, the CodePeek demo for AIR is being refactored to yeild two off-the-shelf utilities for AIR: the persistent xml database handling and the window metrics persistence and retrieval mechanism that let's the app be a good desktop citizen and remember its size and location when you maximize,move or resize it.

So the new demo will not only be showing how to use PureMVC, but how to mix and match these utilities in your apps.

So I see what you are proposing as having direct bearing on the PureMVC + Modules problem discussed elswhere in these forums.

Since there are several people thinking about the problem, what I'd like to propose is this:

We take this discussion offline into a working group in a protected forum. This is how the ports are being handled. Eventually these boards will be made public, but only once we've arrived at a solution that is recommendable as a best practice.

I don't want anyones ideas squashed or not given because the discussion seems to be going a particular way.

We need a working group to propose and evaluate ideas and research and analyse the prior art (such as OSGi) before the community can evolve demos, utilities and best practices to properly support Modules.

Eclipse is solid and extensible because it was well thought out and clearly OSGi played a part in that success. To not investigate the applicability of their patterns would be an oversight.

BTW, with the Java.version of PuerMVC working, perhaps we could see how well the two frameworks nuzzle up together by writing an eclipse plugin in Java with PureMVC? Maz, would you be up for that as a first step to guage what might work and which parts to try and tackle first for AS3 if it looks good?

I'm going to create a task force board for this and add everyone contibuting to the modules discussion thus far.
If anyone would like to be added, let me know by private message.

-=Cliff>

[Maz]

A task force would definitely be great. I'm in.

And you are also right, we should have a look on how MVC+OSGi behave in Java (e.g. Eclipse plugins) to elaborate best practices.
I will have a look at that.

Let me know where this thread goes on.

{Maz}

[Radu Cocieru]

I am very interested in this subject, can you please post an update on where it is going maybe open the boards as readonly to the rest of us ?

Thank you.

[Maz]

AFAIK nothing has been done... No task force / topics.

Interesting is this : Matt Chotin has called for open source projects on OSGi - as "part" of the Flex4 roadmap :
http://opensource.adobe.com/wiki/display/flexsdk/Suggested+Projects

Maz

[puremvc]

Thanks, raducocieu for waking this thread up and Maz for still being there

Sorry this one fell through the cracks folks, but good that the interest is still here. Now that we have MultiCore and a couple of demos showing different ways to make modules talk to each other, I'm thinking we're probably a little closer to having something to work with here.

Its a public board under Architecture where anyone can post, but I'm hoping some people will commit themselves to the project here and use this as the home for their discussion. As Maz mentioned, Adobe is making a call for an OSGI implementation, and we can do it. It's already rocking the Java world and there's no reason not to lead the way in AS3 with what we know to be an already solid framework for applying MVC to modular programming.

So, Maz, you're knowledgable on this subject and were the originator, so, I'm adding you as moderator.

Let's do this!
-=Cliff>

[Radu Cocieru]

Here is a good starting point for inspiration.
http://api.arcwebservices.com/devguide/awx/v4/index_Left.htm#StartTopic=flex/osgi_api.htm#|SkinName=aws

[andres]

I recently discovered this thread and I have to say, I've become very interested. I'm not familiar with OSGI, but I just Google'd some information and think I have a rough idea. I still have questions though that perhaps Maz or anyone else could answer.

As I understand it, an OSGI compliant application is broken down into so called "bundles"/components each with specific jobs. A developer can write code to interact with a bundle via an interface it exposes, calling methods on it. But the most important point here is that bundles are not compiled into the main application (PureMVC MultiCore modules ARE compiled in), but are instead installed at run-time. So my question is, are bundles basically RSLs in disguise (run-time shared libraries)? In Flash, you can create SWFs whose sole purpose is to hold AS3 class code and then import them into a Main SWF via the flash.display.Loader class. You can then access their class definitions as if they were RSLs. The advantage of this is that your main swf is smaller in size and is also faster to compile.

So my questions are:

1. Are OSGI bundles similar to RSLs?

2. What sort of advantages do bundles have over RSLs?

3. Could I, for instance, use bundles to modularize a Physics Engine. It would be a Physics bundle that I could import at run-time and have Mediators interact with it to update the View. Basically, are OSGI bundles intended mostly for business service access (XML, REST, SOAP, AMF etc), or are they also useful for bundling UI functionality (ex file structure list view) and business logic (ex. physics engine)?

[puremvc]

These bundles would be executed as Flex Modules or loaded swfs.

And PureMVC modules are not compiled in, its just that the multicore demos that are up right now do so for expediency.

Can you imagine trying to deploy the Modularity or PipeWorks demos as separate projects for their main apps and modules and explaining how to set them all up and compile them separately and move the compiled modules to a place where the main app can load them? Nah. The point of those demos is not loading but module interaction at runtime.

-=Cliff>

[andres]

Hmm, I guess I sort of jumped the gun on this one then .

Yea, I totally understand how that would be hard to explain, in Flex at least. I do have some experience with Flex development, but not as much compared to my experience in CS3. I would think building a "true" modular demo in Flash CS3 would be much much easier to explain and setup. Now that I think about it, I could probably contribute a very simple one seeing as how Flash CS3 only has 1 demo. And hopefully it would serve as a reminder to our current OSGI development team to make sure any planned PureMVC OSGI implementation is not only Flex compatible, but CS3 compatible as well. Don't forget about us CS3ers

[Radu Cocieru]

We are experimenting porting Knopflerfish OSGI implementation to Flash/Actionscript3 and keep it compatible with pure AS3 without depending on the Flex framework. This is just an experiment it can go both ways but so far it looks very promising.

Will put updates when we have a working prototype, since it's a port of Knopflerfish it will be released under the same license.

[andres]

We are experimenting porting Knopflerfish OSGI implementation to Flash/Actionscript3 and keep it compatible with pure AS3 without depending on the Flex framework. This is just an experiment it can go both ways but so far it looks very promising.

Will put updates when we have a working prototype, since it's a port of Knopflerfish it will be released under the same license.

This is great news! I've tried searching the web for initiatives like this, but couldn't find much.

I'm wondering how you guys are going to implement the OSGI Module layer though. I've done some research on the web and read the OSGI R4 specifications for the module layer and one key feature in OSGI is the ability to have modules import/export packages and hide packages using constraints (such as versioning). In Java this is accomplished through ClassLoaders, in AS3 you have ApplicationDomains, but there's one problem. In Java you can extend the ClassLoader class and redefine your own findClass(className) method, whereas in AS3 you cannot extend ApplicationDomain in order to redefine the getDefinition(className) method, which is vital in order to manage where the AS3 VM should look for package or class definitions. By default, the AS3 VM always looks in either the parent Application Domain and then the current Application Domain, and there's no way to change that behavior. We'd need to be able to implement our own getDefinition() method in order to change the class lookup path so that it can search in whichever ApplicationDomain we tell it took look in.

One solution is to simply place ALL installed modules into one ApplicationDomain, that way all class definitions will be available to all modules, but then you wont be able to hide class definitions in one module from other modules anymore or have multiple versions of a class definition (ex. x.y.Logger [v1.0] in ModuleA and x.y.Logger [v1.3] in ModuleB cannot both exist in the same ApplicationDomain) which are 2 keys features in OSGI.

[Radu Cocieru]

You are right about the limitations of the OSGI Module Layer, it will not be a solution as elegant as the Java one (unless Flash API gets extended). But there are ways to do this using separate ApplicationDomains and the classes should be resolved using the BundleContext (if I am not mistaken this is how it's specified by the OSIGI).

The prototype version will only have the framework as a proof of concept and the package resolver, rest of the layers would come later on.

Anyway Flex SDK has the OSGI implementation on it's road map, so I am sure if we hit the wall Adobe will help

Hope for the best