General
Development
AOP
Operation
Swarm-One is aimed at being the lowest common denominator in technologies. It doesnt rely on any Third party software and as such need to adhere to the infastructural standards such as JNDI, LDAP, JMS. Instead it presents an ideal platform to develop and/or integrate those technologies (see our demo applications). Like some of the latest J2EE architectures, Swarm-One is AOP based, however unlike them it offers a series of innovations that can only be achieved through leveraging the fundamental bias change in technology with AOP.
Spring provides an excellent means of doing what we want to do today...it doesnt deal with mobility and networking
JXTA provides a means of cross platform peer networking, however it doesnt get to the realms of adaptive components and mobility...
http://www.majitek.com is perhaps the most similar technology, although it is aimed at networking lightweight devices as swarms.
Probably...however they platform is not open and extensible where you can develop your own distributed applications (downto and including the interceptors and services)
Probably...but its not opensource, or as extensible, or an OpenArchitecture that can be moulded to suit application needs
Swarm-One is a principle of development, like CORBA it offers a series of services, however unlike CORBA the internals of the architecture are open and extensible. At the core its an AOP Container, however the functionality derived from AOP containers is a new field. Future versions will be developed in C# and then C++.
AOP provides a powerful method of cross cutting code functionality, i.e. oblique abstration - the benefits are touted widely. Most AOP savy people are concerned primarily with language features, several J2EE vendors have rewritten their container using aspects and the core framework. However.... there is much more that can be determined through using aspects. Primarily that they provide a unique means of separating code from infastructure. In doing to the container can set about the code and be (mostly) invisible. Furthermore, Intercepting and leveraging the knowledge about an invocation provides the ability to change the nature of the call, gleen metrics, or even change the application architecture in response.
Different invocation models are supported through the pipelined construction of invocations via the use of aspects. As standard it provides a regular SyncConnection and an AsyncConnector. The AsyncConnection provides a simple, asynchronous, buffered one-way invocation model and basic support of SEDA semantics.
Absolutely, the whole point of this project is to provide an extensible environment where application developers make their own invocation pipelines to develop a rich environment that is extensible, highly testable and reusable. The best place to start is to look at the SyncConnection example.
Services provide part of the infrastructure in any environment, chances are you will be developing your own services. Browsing the existing services will provide a good starting point.
Looking at the AsyncConnection will provide a good starting point for developing your own SEDA aspects. There are 2 levels that SEDA can play at, firstly) - only during the current invocation pipeline where throttling or a QOS control is applied to incoming invocations. Secondly) In a federated environment where a application health service is integrated into health checkpoints.
Mobile Agents are supported through a distributed classloading service and the standard serialization service. In order to develop mobile agents you need configure the JVM to use the DistributedClassLoader to locate remote bytecode. Java provides a high degree of support for mobile agent semantics, future developing involving cross platform agents will require a non-java centric version.
in progress.
The process is called Binding - currently there is support for a StaticBindingService where the IP addresses are known, DynamicBinding uses multicast to locate and bind containers.
Yes, see the jxta Services and Aspects (work in progress)
Yes, (work in progress)
This is a concept that is developed for Swarm-ONE. Perspectives allow for different Aspect classification on components, i.e. a remote, local, secure perspectives. Perspectives can also be used to layer aspect groups on top of each other i.e. Remote(Local(Secure))).
Yes, the AOP Alliance APIs provide a great mechanism for sharing and unifying aspect development
Serialization issues mainly apply to Remote Perspectives as they represent a remotable version of the object. The Remote Perspective is passed between containers the largest issue is control of object serialization and rebinding into containers
ATM support is being done to integrate AspectWerkz
This is a relatively unknown domain and we needed the freedom the grow our aspect requirements
The easiest approach is to copy a demo application. In short, you choose the configuration factory, register your application components and use the Container to retrieve all application components.
MX4J support is implemented in using an JMXAspect. All this aspect does it register as a regular Aspect to manage user components AND as an orthogonal Aspect to manage other aspects.
Yes, you get that for free when using the MX4J aspect to automatically generate MBeans
Highly recommend for application management - see SourceForge