[news.eclipse.technology.ecp] Re: Proposed project name

[Igor Shabalov <ishabalov@xxxxxxxxxx>]

Neil Bartlett wrote:
> > 1. Do we expect some of our bundles to run in a non-osgi environment?
>
> This should come naturally from the principle of minimizing 
> dependencies. If certain bundles contain code that can run outside OSGi, 
> then they would quite naturally not have a runtime dependency on OSGi 
> interfaces.
>
> I think it's important not to reinvent the wheel however, so if a bundle 
> doesn't deal specifically with OSGi then we should question whether it 
> belongs in ECP or would be better brought in from elsewhere. For example 
> rather than reimplementing a JDBC framework we should use Spring's.

I think we need some common ground to define what is a component and 
OSGi bundle give it to us. The essence of ECP is a component definition 
and the way how to assemble components together to create applications.
Our idea is to extend OSGi implementation from Eclipse to handle 
different kind of services, but, frankly, a component model itself we 
takes from OSGi almost intact. So, it will be hard to me to say that we 
MAST support non-OSGi environment. And I agree with Neil, we better 
avoid re-invention of wheels.


> > 2. Will we have integration with other platform environments like JEE, 
> > JME and Portals?
>
> There are two issues here. One is embedding of OSGi/ECP in other server 
> products, the other is the ability to run legacy code such as EJBs 
> within ECP.
>
> I think that the first of these should NOT be a priority. Firstly there 
> are some hard technical limits such as the fact that (inside J2EE) we 
> are forbidden from creating ClassLoaders, SecurityManagers and threads, 
> and we're not allowed to access the filesystem. It's hard to see how to 
> run OSGi given those constraints.
>
> Secondly, as I understand it, this project is all about a break from the 
> past. ECP offers a substantially simpler (and yet more powerful) 
> platform than J2EE. Early J2EE servers did not have to be embedded 
> within a CORBA product, so ECP should not have to live inside 
> JBoss/WebLogic/whatever.
>
> However I do think it would be a great to allow some kind of 
> compatibility layer to run customers' legacy EJBs, MDBs, etc. This would 
> significantly reduce the risk of adoption and the cost of migration.

My opinion - we better not worry too much about legacy here, looking 
more to the future, than to the past. Our initial intention was - to 
abandon compatibility issue at all, at least for the beginning of the 
project. We mast concentrate on component model and services assembly 
first giving an alternative to existing approaches. We a potential in 
OSGi and Eclipse and this is why we are here, not because we need some 
new way to use existing JEE server implementations.

Speaking about JME - this is different issue, unfortunately I do not see 
too much of ME around, however, OSGi model initially was developed with 
embedded applications in mind, I do not see any problem with 
applicability of our ideas to ME world, except some limitations of ME 
itself. And, for upper-level, it hard to distinguish ME from SE. And we 
are in SE now, basically extending SE with stuff that is missing, like 
modules, dependency management, services definition etc.

Speaking about postals. I think if you define postals strictly as a web 
application deployed into JSR-168 portlet container, with some portlets, 
I think we are not there, simply because this is too mailed down to 
specific. Modern AJAX-based approach allow actual "portlet-like" 
experience without of using JSR-168 portlets.

But if we are talking about "expendable integration infrastructure" 
where new functionality units can easily be deployed, activated and 
delivered to end-users - than ECP is exactly that. We define 
"components" that are "deployable", may have a "sleek" user interface 
and define exactly there dependencies. In that terms ECP IS a portal, 
much more flexible and functional, than existing JSR-168 portal engines.



> > 3. What Eclipse tools or other projects are we looking to build on to 
> > bring about Enterprise Components world domination 2.0 (patent pending)?

We are familiar with WTP and some other eclipse tools, we definitely are 
going to use all Eclipe tools platform to create tools for ECP, I just 
do not have more specific plans yet.


> I can't comment on this as I'm not familiar with WTP.
>
> - Neil

Best regards,
Igor.