Versions Compared

Old Version 1

changes.mady.by.user Zhaohui Feng

Saved on

compared with

New Version 2

changes.mady.by.user haleh mahbod

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • This is similar to the local deployer, however registers
    itself with the discovery service for receiving physical model updates
  • The federated deployer doesn't use the loader framework
  • The federated deployer accepts serialized physical model
    information in XML, rather than raw SCDL as with local deployer
  • It uses the current builder framework to build, prepare
    and start the components

Work outstanding

  • Define the physical model in Java
  • Define the corresponding XML infoset
Note
titleA note from Jeremy on federated deployment Feb. 9, 2007.

The design is that there is a "master" node that is working out which"physical" nodes components are going to run on. It then
passes PhysicalComponentDefinition's to the worker nodes to get them tocreate the component and any transport bindings it needs
to talk toother nodes. The PCDs are portable, independent of the type ofruntime, instead tied to the type of component.Picking on
Ruby as an example as we know we can run that on Java andNative runtimes, there could be one common PCD for a Ruby componentthat
was supported by all container implementations. The master couldsend that to any node to have it run a Ruby component. A runtimecould
also offer "enhanced" Ruby support with additional featuresthat required additional configuration. If would offer support for adifferent
PCD with that additional metadata. Which one is selected bythe master would be part of its component allocation algorithm.So basically,
any runtime that can connect to the federated fabricand handle a PCD can join the SCA domain. We picked JXTA and XML forthe fabric and
PCD encoding as there is support for those in bothJava and C++. Adding support for that to the Native runtime wouldalso be good if you
were skeptical of all the Java stuff.

Work outstanding

  • Define the physical model in Java
  • Define the corresponding XML infoset

Supported Extensions

Spring

1) it allows a Spring application context to act as the
implementation of an SCA component - this allows users to bring
existing Spring applications into an SCA assembly
2) it allows SCA components to act as Spring beans so that users can
use services over SCA from their applications.