tag:blogger.com,1999:blog-2287707115804603350.post5700006873553847579..comments2010-08-21T10:47:37.635-07:00Comments on thought-burp: OSGi and SCATim Diekmannhttp://www.blogger.com/profile/14767809531097448373noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-2287707115804603350.post-61512347204263227362009-12-22T03:42:32.529-08:002009-12-22T03:42:32.529-08:00Tim
You forgot to mention the Paremus Service Fa...Tim <br /><br />You forgot to mention the Paremus Service Fabric - which as you well known was the first distributed OSGi / SCA platform and was first released in 2006! Well before the vendors you mention. <br /><br />Cheers<br /><br />RichardRichard Nicholsonhttps://www.blogger.com/profile/00742964822004119760noreply@blogger.comtag:blogger.com,1999:blog-2287707115804603350.post-43879449198258004602009-01-28T08:02:00.000-08:002009-01-28T08:02:00.000-08:00Interesting blog, Tim!I do however believe the que...Interesting blog, Tim!<BR/><BR/>I do however believe the question is not what OSGi and SCA have in common, but rather how SCA can complement OSGi to make it an even more attractive platform (and vice versa). <BR/>Instead of wrapping OSGi in SCA, make use of SCA assembly ON OSGi following an Extender Model approach - just like other frameworks extend OSGi. In order to make bundles part of an SCA domain, you would enrich them with SCA assembly meta-data and be done.<BR/><BR/>After all, OSGi's deployment and management model is one of its strongest selling points. Why would one want to hide this behind another model, such as SCA's? SCA's notions of assembly, policy, and its ability to go cross technology should extend the OSGi platform rather than encapsulating it.<BR/><BR/>Thanks,<BR/> HenningAnonymoushttps://www.blogger.com/profile/08493666394262907523noreply@blogger.com