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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
