Fabric3 can be deployed inside a WAR, which allows it to run on any servlet container. However, some of the capabilities such as dynamic deploment of policies and extension configuration are limited in this deployment mode.
To address this, we are planning on releasing app server specific runtimes similar to Fabric3's Tomcat support. These runtimes will take direct advantage of native features of the host environment such as clustered communications, JMX, and messaging. Initial plans are to start with JBoss, WebLogic and Websphere. Current plans are for the first two to be available in our next release. We are open to supporting other app servers such as Glassfish and Jonas based on demand.
Also, one of the areas where we put in significant work for the 1.3 release is in support for BPEL process engines. We have not advertised this since the capabilities are not surfaced directly to end-users at this point. However, there is a partner that is currently using these features to integrate their BPEL engine into Fabric3.
Supporting Websphere Process Server would be interesting since it would allow end-users to replace IBM's "SCA" runtime (SCA in quotes since what ships in Process Server is actually a proprietary runtime that does not implement the SCA standards). However, based on our experience with the BPEL engine integration mentioned above, doing so would entail low-level integration, something that would require support from IBM. It would also involve integration with BPEL tooling for a good end-user development and deployment experience. We are open to doing this if there is demand, but it would also require cooperation from IBM.
In terms of OSGi, Fabric3 modularity is built on SCA's model, which derives in part from OSGi modularity. For example, Java package visibility is managed via OSGi directives. SCA extends modularity to encompass non-Java artifacts as well as services. Non-Java artifact visibility is controlled by import/export mechanisms similar to OSGi. For example, WSDLs and XSDs can be shared using a qualified name-based import/export scheme. SCA also supports the ability to controll the visibility of service endpoints through "composites". Composites are application building blocks that define services and references to other services. Composites can be nested (i.e. contain other composites) where the internals of one composite are isolated from its peers and parents. David Chappell has an excellent article on this at http://www.davidchappell.com/articles/Introducing_SCA.pdf
. At the risk of self-promotion, there is also a chapter covering this in the book I co-wrote with Mike Rowley at http://www.amazon.com/Understanding-Component-Architecture-Independent-Technology/dp/0321515080
Because of these additional requirements, Fabric3 implemented its own modularity support (including OSGi classloading) rather than rely on application server support for OSGi (which is spotty in some products). This provides consistent behavior across all runtimes.