On 10/26/07, James, Steven <[EMAIL PROTECTED]> wrote:
>
>
> Does anyone know if Tuscany has any Redundancy support? For example
> imagine a component has a dependency on another service but this service
> is remote. Later the dependant service becomes unavailable for whatever
> reason and you need to use the redundant service. Does Tuscany provide
> infrastructure to enable this, such as through a service broker that can
> be tailored or is this an application issue?
>
> Many thanks.
>
> Steve
>
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Hi Steve

There isn't explicit redundancy support just yet but I'm interested in
seeing some basic support added. The distributed domain support we have at
the moment has a simple registry of the service endpoints that are available
in the domain. The nodes (the Tuscany runtimes that run components within a
domain) can be moved about and the services will register their current
location.

There is a slight snag with this that components that reference remote
services won't revisit the registry to find out where a service has gone
when a request fails. It's on my todo list and is a simple fix.  We could go
some of the way to adding more redundancy support quite easily by using
existing technology.

For example, it would seem sensible to be able to bring up tuscany in a
cluster of web app servers. We could do this in two ways.

We could represent the whole cluster as a single Tuscany node and defer to
the cluster to manage how components are replicated across the cluster.

A more general and initially easier approach is to allow a tuscany node to
be brought up on each server in the cluster and then deploy the same
contributions to each node. To make this work we then need to make sure that
the domain understands that all of these nodes are working as one and should
receiver the same management events and also that any services that these
nodes expose should have and endpoint that is consistent with the endpoint
on the cluster, typically the ip address of the request sprayer.

You could probably make a lot of this work manually in the first instance
without using the distributed domian support by deploying nodes manually.

The tricky bit with all of this is deciding what to do with any running
components that have a scope wider than an individual request. If these
components are managing any state, for example, if they have conversational
semantics, them this state would need to be available to any redundant nodes
that take over when a node fails. The pragmatic approach of course is to
take small steps first and tackle the easy scenarios.

Hope this helps. If you have any thoughts about what's required or how to
make this work then let us know. Even better if you want to help out making
it happen;-)

Regards

Simon

Reply via email to