On Oct 24, 2006, at 9:37 AM, Jeremy Boynes wrote:
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.
Yes I think this is critical, especially in multi-VM environments. In
the spec group we are dealing with the issue of deployment and
packaging now so I think our work on this would correspond nicely to
that.
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.
Existing server integration is a nice-to-have but IMO we require a
standalone environment that can support the full range of SCA
features which is not easily done in the former.
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.
Yes this will likely entail some type of service discovery. I've been
looking at zeroconf and perhaps UPnP as ways of doing this (support
should be pluggable) and when I have a better idea I will post a
write-up to the list.
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 are going to need to deal with how intents are mapped to policy
sets and then runtime artifacts. I see this "intent engine" as a key
subsystem moving forward. I was discussing this the other day with
Felix and I'll kick off another discussion on the list related to
that since it is a broad topic.
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.
Yes plus handling of stateful conversations
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 :-)
It may make sense to start to categorize these in buckets. My brain
dump would be:
1. SCA fabric, a.k.a. "SCA system"
- How an SCA System is (auto)constituted
- Service discovery
2. Deployment, provisioning and Management
- How to get things into an SCA system, how logical artifacts are
mapped to physical runtime artifacts, and how to manage what is going on
3. Spec alignment
- Refactoring of core to support pending spec changes around services
and references
4. Host environments
- A "real" standalone container, particularly to support 1 & 2
- OSGi support
5. Programming model
- Our programming model needs to support "high-value" SCA features
- Stateful conversations
- How databinding is specified
- Complex property support
- Improved autowire capability, including the ability to autowire by
intents and exposure of autowire to applications
- Better web application support
6. Policy and intents
- We need to support the use of intents for allowing the runtime to
apply policies as well as select wire targets
- Intent mapping engine
- Transactions
7. Extensions
- Classloader isolation
- Complete (or prune) existing extensions, add new extensions such as
JMS and AMQP binding support (we may want to use AMQP as the
"default" SCA binding)
8. Integration test harness and integration tests
9. Better across-the-board test coverage
10. Better samples that demonstrate the features mentioned above and
show why SCA makes things substantially easier
I'm planning on getting involved in service discovery, stateful
conversations, improved autowiring and integration testing...
Jim
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
