On Oct 24, 2006, at 4:48 PM, Meeraj Kunnumpurath wrote:
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.
+1
An SCA system could be realised as a set of federated heterogenous
JVMs each hosting a different set of components.
Yes, I think this is a key difference between what Tuscany is trying
to do and more traditional application server environments that have
a more homogenous 2- or 3-tier topology. Some nodes may not be VMs.
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.
I think it will fit. In SCA we identified a couple of roles (they may
be the same person sometimes, or different individuals), one of which
is an "assembler". This person is responsible for resolving unbound
or dangling wires, configuration, etc. Also, one of the changes being
considered is the introduction of "intents" which could correspond to
the things you mentioned above. As part of these changes, we were
also considering autowiring by intent. This will provide even more
flexibility since it will allow the runtime to choose wire targets,
bindings, etc. based on a set of constraints. I believe these changes
will make things a lot easier as having to "manually/explicitly" wire
can get tedious (as well as result in globs of XML).
So my picture of how things would work at a high level is:
1. Tuscany nodes come up
2. The nodes can either be pre-configured to know about themselves or
would autodiscover each other through a protocol such as zeroconf. We
should look at other protocols as well but I am currently interested
in zeroconf since it is language-neutral, works with existing TCP/IP
infrastructure and does not require a central registry (the service
discovery part which Tuscany would use can be run over multi-cast or
uni-cast DNS), works in small devices (e.g. printers and cameras),
and is an IETF standard. Nodes could be different Tuscany instances
running on a variety host environments, just an agent talking to a
middleware instance with no Tuscany runtime, or represent some
middleware cluster.
3. An SCA system would be constituted from these nodes, and would
itself be represented as a composite.
4. There would be a provisioning infrastructure responsible for
mapping and deploying SCA assemblies to physical nodes. This may
entail breaking a composite apart and deploying child components to
various nodes according to some (pluggable, extensible, etc.)
algorithm, which itself could use intents to determine where to
deploy (or it could explicitly be told where to go).
5. During the deployment, unbound wires would be resolved. This can
be done explicitly or through autowire.
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.
It may depend on the definition of "deployment". For me, deployment
occurs when someone (an assembler) takes an assembly and instantiates
it in an SCA system. As part of that process, all dangling references
and outstanding configuration must be satisfied. Prior to that, a
developer could create components some of which were composites that
had local services "statically" wired. The key is there may be
reference targets which are only resolvable during deployment into a
live system and those targets may vary depending on whether the SCA
system were a production, staging, or QA environment.
Does this fit with your thinking?
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?
Maybe we can kick off a separate thread on this? I'm not sure thread
confinement for component implementation instances is something we
want in all cases, particularly for session and module scoped ones.
In cases where the resource being injected is not thread safe, we may
want to inject a proxy that resolves to the correct instance on every
invoke (similar to what we do when a service is injected, e.g. a
session-scoped service injected on a module-scoped component). This
would allow us to have different scopes such as thread-confined or
transactional or re-use existing ones (request) which may correspond
to the lifetime of a Hibernate session or JPA context more closely.
This would allow us to confine the specific resource as opposed to
the entire component. This will not solve the issue of race
conditions but sometimes the best thing to do is not try and do too
much.
The Java spec is also going to include some revised wording on how
client code should behave with respect to threading (e.g. spawning
threads and calling into SCA code may yield unpredictable results;
use WorkManager).
Jim
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
