Sapia releases Soto 2.0: lightweight service framework


News: Sapia releases Soto 2.0: lightweight service framework

  1. Soto is a lightweight, modular service framework relying on Java's dynamic nature and presenting original characteristics: "layers", conditional instantiation, configuration supporting file includes and variable interpolation, etc.

    * Service implementations are configured through XML, and instantiated using the Confix API: this spares developers from manipulating DOM-like structures to access a service's configuration. The latter is rather directly assigned to service instances using Java Reflection.
        * Service implementations are "dynamically" associated: if a service needs another service to accomplish its work, this association is materialized through the XML configuration - no lookup through some naming service or "component manager".
        * Embeddable: a so-called "soto container" can be instantiated directly by the developer; it can be used in a servlet, in an EJB, in a main method, etc. Hence the "lightweight" container...
        * Comes with built-in "layers": one that allows services to be automatically published as MMeans, through simple configuration; another that implements a simple AOP framework - others are planned.
        * Sports a state machine API that allows removing coarsed-grained logic from Java code.
        * Supports file "includes": configuration can be split into multiple configuration files that can be "included" in other ones. This is very essential in cases where configuration becomes "large" and difficult to manage in text editors.
        * Conditional instantiation: services are instantiated (or not) based on runtime parameters.

    Get it at:

    Also, Sapia OSS has announced Ubik 2.0, which brings you feature-complete, easy remoting, without the burden of an app server. Read more about Ubik remoting.
  2. Sounds alot like IOC[ Go to top ]

    I suppose SOMEONE had to go commercial with IOC :-)
  3. Next time around I'll read the target site :-D
  4. Recently i use JAMES(from jakarta project),and i find some samliarlity with Soto .
    1,Both use xml configuration file to express component dependency.
    2,Link between component is not direct,use ComponentManager,which self is a common componet.
  5. Ubik/Soto activity[ Go to top ]

    How active is Ubik/Soto? I had sent a question to the mailing groups yesterday and still havent received a reply. One of the pre-requisites of using an open source framework is the amount of activity among the developers
  6. Ubik/Soto activity[ Go to top ]

    Both projects are active.... I replied to your post on the list; I wonder why you have not received my reply... Have a look at:
  7. Hi,

    that ComponentManager thing is what is not necessary in Soto; you associate components (or, rather, services, in Soto's case) through the XML config - the buzzword for it is "dependency injection" (sounds more like treatment for highly contagious viral disease...).

    For example:

    public void ServiceA implements Service{

       public void someMethod(){}

    public void ServiceB implements Service{

       public void setSomeService(ServiceA aServiceA){}

    And in the config:

    <soto:service id="services/a">
      <sample:serviceA />

    <soto:service id="services/b">
          <soto:serviceRef id="services/a" />



    James is using Excalibur (or Avalon?) from Apache. The following are differences between Soto and James:

    1) Excalibur/Avalon as many lifecycle interfaces; Soto only mandates a single Service interface

    2) Excalibur/Avalon are assumed to be pooled (Soto services aren't); this forces the following programming model:

    SomeInterface comp = (SomeInterface)componentManager.lookup(SomeInterface.ROLE);
      // use comp...

    3) Soto has a powerful config format supporting:
      - file includes (allows separating single, huge application config into smaller parts);
      - conditional instantiation;

    4) Soto has a neat feature called "Layers" (OK, you might not use it, but its there anyway). There is a JMX layer, an AOP layer, etc.

    5) Soto's AOP is small, non-nonsense and does the trick in losts of cases (see

    6) Powerful, customizable resource resolving mechanism: supports file:/..., resource:/..., http:/...; plug your own...

    7) Powerful, intuitive config format.

    Instead of something that looks like this:

    <component class="net.acme.myorg.SomeComponent">
      <property name="maxPoolSize" value="10" />

    You something that looks like this:



    To tell you the truth, I think all sums up to the details (of the framework) and your personal preferences. The essential thing: I could live with Excalibur/Avalon, Spring, Hivemind much better than with EJB!!!

    In the long run, it is also about the direction that a framework takes. Soto will have a much more XML/SOA feel to it in the future (at least, we hope so).

  8. Oups, points #3 and #7 should be under the same bullet... Sorry; it's morning...