You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/10/24 18:37:00 UTC
What's next for SCA?
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What's next for SCA?
Posted by Jim Marino <jm...@myromatours.com>.
On Nov 2, 2006, at 4:37 AM, Andy Piper wrote:
> At 17:21 24/10/2006, Jim Marino wrote:
>> 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.
>
> FWIW if you want to drive adoption then I think this is more than
> nice-to-have.
> I think you need to seriously tackle the issue of the whole world
> not being Tuscany (see note below). This is not just the issue of
> providing a fully featured SCA implementation in hosted
> environments, but interacting with other SCA runtimes that are not
> Tuscany and other services that are not SCA at all. I think this
> probably means a much clearer separation between the parts of the
> Tuscany runtime that are core and those that are targeted to a
> particular implementation (standalone for example). Given clearer
> SPI access into the core I think you will have a lot more success
> in driving Tuscany into the real world.
I definitely agree we need to do a better job tackling the issue of
there being other things besides Tuscany :-) Up to now, I have viewed
most of the work we have been doing as concentrating on in-VM wiring
infrastructure. As part of next steps, I think we need to address
(for lack of a better term) the "service fabric". This definitely
goes beyond just providing a full-featured VM-based implementation
that we have been working on to-date.
I would say there are a number of issues here:
1. The ability to deploy Tuscany on a variety of runtimes
2. The need for a standalone environment to leverage all the
capabilities of SCA assembly
3. Interacting with non-SCA services
4. Better APIs/SPIs into Tuscany
5. Support for a service fabric/network or "SCA system"
1-4 basically involve dealing with the in-VM wiring infrastructure
that we have today. For example, (1) embedding Tuscany in Tomcat, (2)
providing a full-featured SCA standalone environment, (3) increasing
the number of supported bindings, and (4) management/extensions, etc.
We still have a lot of work in the above areas to do. However, for me
the real benefits of Tuscany will come to the fore when we provide
capabilities that allow us to support service networks. I was viewing
this as the ability to describe a logical service topology (services
and their dependencies, SLAs, policies, qualities of service) and
have runtime infrastructure that is able to provision and manage it.
A key characteristic of these networks will be that while there is a
unified logical topology, their physical manifestations will be
heterogeneous. For example, a service network could be deployed
across Tomcat instances, WAS clusters, WLS clusters, a Tuscany
standalone container, even potentially Microsoft WCF. In some
instances, the Tuscany in-VM wiring infrastructure may not be
present. In this case, a deployment agent would be responsible for
provisioning artifacts to a particular runtime. The job of Tuscany
will be to provide the fabric that ties this all together and
constitutes an "SCA system".
>
>> 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.
>
> The key here is pluggable. Any clustering infrastructure does this
> and to date they are all different (e.g. WebLogic, Geronmo, Active
> MQ, JBoss, WAS), datacenter managers will not thank you for more :)
Agreed that most of what we should do needs to be pluggable. However,
I was viewing "service discovery" as something distinct from
clustering. If the SCA system mentioned above is itself a composite,
then it could have various services such as deployers and
provisioners. There may be particular composites deployed in the SCA
system that run, for example, on an app server cluster and services
within those composites may use the clustering facilities provided by
that infrastructure. At the higher level of the SCA system, we need a
discovery mechanism that may work across a variety of runtimes as a
way for the SCA system to "auto-constitute" itself.
> It might also be worth looking at ActiveCluster since it does
> something similar here (I think it may use Zeroconf anyway),
> although I have to say that if I had my way everyone would use UPnP.
Do you think UPnP is better direction to go? I liked Zeroconf because
of its simplicity and support for discovery beyond the local link but
I don't have any strong opinion either way.
>
> Although don't you actually need something a bit higher level? E.g.
> UDDI or AD or something that allows you to publish all of the
> associated meta data as well.
>
I definitely think we need a metadata representation of the SCA
system/service network. I was imagining that would be done by other
services which could be segmented to handle particular areas of the
system. I'm not sure UDDI is the way to go as it may not capture the
relationships we need to but it is something we should look at.
There are a number of us interested in these areas so it would be
good for people to just post their ideas and see where they take us...
Jim
> My $0.02
>
> andy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What's next for SCA?
Posted by Andy Piper <an...@bea.com>.
At 17:21 24/10/2006, Jim Marino wrote:
>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.
FWIW if you want to drive adoption then I think this is more than
nice-to-have.
I think you need to seriously tackle the issue of the whole world not
being Tuscany (see note below). This is not just the issue of
providing a fully featured SCA implementation in hosted environments,
but interacting with other SCA runtimes that are not Tuscany and
other services that are not SCA at all. I think this probably means a
much clearer separation between the parts of the Tuscany runtime that
are core and those that are targeted to a particular implementation
(standalone for example). Given clearer SPI access into the core I
think you will have a lot more success in driving Tuscany into the real world.
>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.
The key here is pluggable. Any clustering infrastructure does this
and to date they are all different (e.g. WebLogic, Geronmo, Active
MQ, JBoss, WAS), datacenter managers will not thank you for more :)
It might also be worth looking at ActiveCluster since it does
something similar here (I think it may use Zeroconf anyway), although
I have to say that if I had my way everyone would use UPnP.
Although don't you actually need something a bit higher level? E.g.
UDDI or AD or something that allows you to publish all of the
associated meta data as well.
My $0.02
andy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What's next for SCA?
Posted by Jim Marino <jm...@myromatours.com>.
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 <jm...@myromatours.com>
>> Reply-To: tuscany-dev@ws.apache.org
>> To: tuscany-dev@ws.apache.org
>> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
> _________________________________________________________________
> Download the new Windows Live Toolbar, including Desktop search!
> http://toolbar.live.com/?mkt=en-gb
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What's next for SCA?
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
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 <jm...@myromatours.com>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>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: tuscany-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
Download the new Windows Live Toolbar, including Desktop search!
http://toolbar.live.com/?mkt=en-gb
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What's next for SCA?
Posted by Jim Marino <jm...@myromatours.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org