Hi,
I have been having few thoughts on federated deployment as well. Currently
we wire services to references statically. However, I think this is more of
a runtime concern rather than a build/package/deploy time concern. An SCA
system could be realised as a set of federated heterogenous JVMs each
hosting a different set of components. Each component would publish the
services it provide based on supported MEPs, IN/OUT parameters, supported
transport bindings and policy intent. Based on the published information, an
adminstrator should be able to wire this services to a compatible reference
for a consumer component at runtime. This wiring should be dynamically
amendable to cater for such requirements like meeting SLAs, policy changes
etc. I am not sure how much this currently fits into the SCA spec. However,
as a user this is something I have looked for in ESBs. I would say a
consumer component only need to know about the contract and MEP (to a
certain extent) of the service it use. The assembly of an available
prospective service instance is more of a runtime concern than deployment
time.
Another thing I am curious about is scope containers, instance pooling and
thread confinement. This is kind of related to the JPA integration work I
have been doing. Certain resources that are injected into components may not
be thread safe. In such scenarios, how do we make sure the components
themselves are thread confined to avoid race conditions. Is instance pooling
for stateless components a possible solution?
Ta
Meeraj
From: Jim Marino <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: What's next for SCA?
Date: Tue, 24 Oct 2006 10:21:45 -0700
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]
_________________________________________________________________
Download the new Windows Live Toolbar, including Desktop search!
http://toolbar.live.com/?mkt=en-gb
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
