[news.eclipse.technology.ecp] Re: More on the project name, and relation

[aantonau@xxxxxxxxxx (Alex Antonau)]

Neil,

> I have some concerns about how necessary these layers are, especially when 
> they are defined in such woolly terms. For example "Bean Component Model" 
> conveys no information to me - all three words are so abstract as to be 
> meaningless. What are you actually building?

Things should have names, aren't they? May be "Bean Component Model" is 
not a perfect term but it is a name for the following specifications:
- Interface of BeanFactory Service
- Specification of XML descriptor for declarative definition of such 
BeanFactories
- Specification of Bean Component Runtime that parses the XML descriptor 
provides BeanFactory Service and reacts on changes in OSGi container. 

Another question is why we need these JavaBeans factories. Our experience 
shows that services are not enough to build an application. You need 
private, application-wide objects. So Bean Component Model introduces such 
objects.

> In my opinion, OSGi doesn't need any "Enterprise Platform" or "Framework" 
> on top of it. OSGi is already all the platform we need, and it doesn't 
> need all these extra layers - we just need some services.

May be OSGi does not need any Enterprise Platform but in order to write 
any simplest web application using OSGi Service Platform you need extend 
it to Enterprise-grade Platform. 

> For example look at things like Event Admin, Wire Admin, SCR, etc. They're 
> not "layers", which implies that things in the higher layers will only 
> work if all the lower layers are in place. They're just services. 
> Similarly, "enterprise" capabilities can be supplied as nothing more than 
> a bunch of services.

I agree it looks great. But unfortunately pure SOA approach does not work. 
Developers need an application state. When you have state in application 
you need manage it, provide a way services could work with the state of 
different applications. What I called "Application Layer" is the thing 
that provides such possibility. I agree it may be called Application 
Service.

> Unfortunately "enterprise" is another woolly, meaningless word. Here's 
> what I think it comprises:
We have what we have. Enterprise application development is what we are 
targeting.

> - Declarative security (mostly provided by OSGi User Admin and Conditional 
> Perm services anyway)
Agree. It's need to be developed.

> - Transaction management and 2PC
Agree on transaction management. What is 2PC?

> - Declarative transactions - best to do this with AOP techiques, need to 
> look at AJEER and AOSGI
Agree.


> - Asynchronous message delivery - eg the "message driven service" stuff 
> I've been working on
Agree.

> - Remote invocation - how do clients (paricularly RCP clients) call our 
> server?
Agree. We are looking at SOAP to avoid issues with Java serialization.

> - Web apps and servlet - lots of possibilities here including Wolfgang's 
> RSP work, Wicket, etc
WebApplicationService is an extension point for this direction

> - Persistence - developer choice is crucial with this one, it should be 
> possible to choose Hibernate, Toplink, iBatis or plain old JDBC.
Entity Component Runtime is our initial proposition. ECR provides 
declarative definition for EJB3 EntityManagers. Developers can use 
Hibernate or EJB3 OR mapping.
For plain JDBC we need just register DataSource service and that it.
For TopLink, iBatis or other ORM solutions new runtimes should be 
developed.

> - Anything I've missed?
Other topics which need to be discussed:
Clustered OSGi containers 
Portlets
export/import OSGi service as a WebService
Intergation with ProActive


> The above services should all work great together, but also any one should 
> be usable on its own, and they should also work well with bundles that are 
> not supplied by the ECP project. Ie, only standard OSGi facilities like 
> the Service Layer should be used for inter-bundle integration. 
No problem with that. Service Layer is enough. But when your service work 
with different applications you need a mediator - another service that 
manages the application state.

> Implementation details like Spring ApplicationContexts should NOT be 
> leaked between bundles.
It is not. We use Application Service/Web Application Service to provide 
Application Context for runtimes. But components are not tied to the 
Application Service API just runtimes are. And it is definitely not a 
Spring ApplicationContext.

> My preferred name for the project would therefore be something that didn't 
> include either the words platform or framework. How about:
> - Eclipse Enterprise Services (Eclipse ES)
Very good. I like it very much but it does not correlate with primary goal 
of that project - provide a way to develop reusable components what is 
stated in our proposal. Services just happens to be the best way to 
dynamically couple the components.

In my opinion the best names we have so far are:
- Enterprise Component Platform
- Eclipse Enterprise Component Services