With M2 mostly behind us, I'd like look forward to things that we can
tackle next for SCA/Java.
I think there is still some cleanup to be done - fixing bugs that we
find in M2, cleaning up some of the compromises we made, and so
forth. As part of that I think we still need more coverage on testing
at all levels - unit, function, integration. I'd like to see us be in
a position to regularly publish development snapshots that can be run
through some form of test suite.
I also think there's quite a few improvements we can make to the
classloading infrastructure. The issues with Spring and SDO show the
need for a controlled way to share classes between application code
and the runtime; we also need to deal with the isolation issues in
the itest plugin (as in, dealing with the current lack of isolation).
This is part of a general issue related to packaging formats and how
composites correspond to physical artifacts in general.
This leads into the question of how we deploy things to servers. At
the moment we only support server functions by being part of a WAR
deployed to an application server; a user still needs to do quite a
bit of work to set up the war (although the plugin helps). To support
users in general and integration testing I think we need a way to
deploy/undeploy SCA applications to running servers in some native
form. We can do this either through extensions to existing servers
(like the Tomcat integration from M1) or by enhancing the standalone
environment.
Once we have the notion of multiple environments, I think we're in a
position to tackle the more interesting aspects of SCA dealing with
the composition of services across a network rather than locally as
we have now. Finding a way to map a logical SCA system onto a mesh of
servers and handling the interconnections between the system's services.
Tied into that we should also start to look at the policy and
intention parts of the specification, providing support for core
aspects such as security, reliability and transactions. We have the
hooks in the fabric for attaching policy but we need the
implementations of these policies and the mechanisms for ensuring the
right implementations get engaged.
We may also need to revisit the async programming model, both from
the spec side and our implementation. I have a gut feeling that there
are issues lurking there that don't make this as easy for users as we
would like. We also need to extend what we have to support async MEPs
on the wire rather than the simple sync MEP we have now.
Finally, there's a general issue with adding additional bindings and
containers and finishing what we have already (there were quite a few
in M2 that we didn't think were ready for binary distribution). There
seem to be quite a few in the pipe with talk of JMS and EJB, JDBC and
declarative DAS.
This is just of brain dump of where my thinking is at the moment, I'm
sure everyone has their own thoughts about things we should tackle.
It would be good to get to them all on the table :-)
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
