[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.ecp] Re: Proposed project name
Please, don't take my opinion as a "definitive", I do not want limit our discussion and the question "to go or not to go with JEE" is important for sure.

We need to understand what does it mean - to provide level of interoperability between JEE and ECP. For example, JEE specify such technology as JSP or JSF or Entity Beans and we are already using it in our ECP prototype code, we already have special compatibility layer in place. If you are talking about EJB (or MDB) - that different story, do we need to re-implement container in order to be able to use legacy EJB? Or we can just "package" JBoss in a way how we already packaged Tomcat as a OSGi bundle, and consider it a "interoperability" layer. May be we can create sort of "bridge" between our Beans Framework and JNDI to allows directory-binded EJB to be exposed as a Beans and vice versa? This is just an ideas.

About portal. What is portal if not a framework for dynamic components which have rich behavior and UI? And these components must be easily activated/de-activated, rearranged, put into some screen positions etc, without much of interference to internal component structure? And what is ECP if not the same thing?

Best,
Igor.


Wendell Beckwith wrote:
OK, if the goal is to drop all legacy infrastructures and do something new and better, in theory at least, then that's fine. Mainly what I was commenting about was were we going to provide some type of integration layer to ease people over to the OSGi way. And as for the environments, I don't do anything in JME so that isn't a loss for me, and your thoughts on OSGi as a portal infrastructure is an interesting take that I haven't thought of.

Wb

Igor Shabalov wrote:

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.