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