Project Home

News

Forums

Manual

Wiki

Downloads

Browse Source

Welcome to Surinam

This project lies in the squarely in the area between highly-decoupled SOAs and localized, static compiled applications. As such, it introduces a new twist on a utopian view of software, including the concept of "Hyper-Dynamic Sofware" (TM) based loosely on an SOA model. This view states that software should retain the ability to morph and change over time, and in some cases, grow capabilities far beyond its original design... all without stopping the application or sacrificing formalism. Once you change some of the fundamental assumptions and rules about how software is built, you open the door to a cascade of new ideas that is a natural outgrowth of such freedoms. Should you choose to delve deeper, you will discover Temporal Design disciplines, Service Semantics, Blueprints, Graphs and Class Versioning.

SOA in a Thimble TM

Surninam is a framework that strives to take the best of what you get from a Service Oriented Architecture and makes it small. This approach includes a "cradle to grave" mindset that supports you through all the phases of the software lifecycle rather than just helping you do the design or just the implementation. The cornerstone of the framework is to allow you to break up your Web application into discrete services that have well-defined Software Contracts that deploy in a highly decoupled environment; the big difference is that this all happens inside your application where everything remains local (i.e. efficient). You are still making local invocations but your applications are free to become granular at a level that is best suited for your needs (that happens at design time and at runtime). As with SOA architectures, you gain the ability to create your Service Definitions and implementations completely independent of the application that consumes them. This level of independence is a boon as it gives unprecedented development scalability; for example, getting the New York development team collaborating with the San Francisco team; you can throw in a Croatian team for good measure.

Technical Overview

Surinam allows you to embed a container called a Service Block in your application to which you deploy your individual services, which are then woven into a Service Graph. Each service can be as big or small as you like and they can be added and removed at runtime. Service Blocks also include an invocation framework (using a routing interceptor), a directory service and a few managers.

An important feature of Surinam is how it allows you to manage your Service Graph; for this, you have two options. You can do it programmatically if you like or you can use a wrapper called a Commander that lets you apply "Action Documents" to it. Action Documents are schema-compliant XML docs that allow you to modify your Service Graph at runtime. They can contain incremental changes or complete graph descriptions which are essentially a set of service "Blueprints" which describes how a particular service is to be built. Furthermore, there is a Blueprint Manager inside each Service Block which maintains a meta-data view of the current state of the graph and can generate a valid Action Document that comprehensively describes the whole graph. This feature effectively captures a consolidated view, even in the case of having made several incremental alterations to the Service Graph. Again, since Action Documents are XML, they can be persisted and/or broadcast over a network.

Overall Goal

Once you have the ability to build composite applications as an aggregation of local services that avoids all the tight coupling that is normally required, it changes everything. One way Surinam tries to get you to think in new ways is through Temporal Design; time now becomes a new dimension to how you design, build, deploy, and manage software.

Additionally, Surinam tries to capture something that is largely missing from all application APIs and SOAs alike... Service Semantics. Through its optional suggestions for managing and versioning your services it is possible to introduce new versions of Services and to capture semantic changes in your service definitions.

It is an important point that neither Service Definitions, nor their implementations need to have been written by you. You can leverage the pantheon of third-party libraries out there by wrapping and deploying them behind formal vendor-neutral API of your own creation or use the ones that are already in existence. You can componentize your application and reuse individual services or license these service components to others; this is similar to the benefit you get with an SOA except one is big and distributed while one is small and embedded.

It is possible to imagine other supporting projects that could be created just for the development of all these reuseable services so that developers can reduce the risks of pulling other technologies into their applications. All those services will be embedded but kept at arms length preserving the ability to swap something out in the event that the library turns out to not be what you needed.

About OSGi

OSGi and Surinam have some aspects that are stunningly similar, however the overall gestalt is different. In fact, Surinam embraces philosophies that are strikingly different with regard to the nature of software and how to manage it. While it's appropriate to applaud the work the OSGi group has done (along with the Open Source projects like Equinox and Felix), this is probably a good opportunity to point out some areas where the two approaches diverge. While I am sure that their efforts will remain a moving target; hopefully, by calling out issues with the OSGi approach, we will help discriminating readers tell these technologies apart. Whether they will migrate closer together in the future is anyone's guess.

• Parent Context Pollution
  Since the client can instantiate their own implementations and register them, it means that implementation classes come from the current class loader which pollutes the parent context. You can register and unregister a service but it never goes away; this approach does not allow you to upgrade an existing class with a new version at runtime; once an implementation class is loaded, it cannot be unloaded.
  
  
• Client Coding Issues
  Because services come and go on the fly, lookups return 'null' if a service doesn't exist. With Surinam, an exception is thrown when a service is unavailable which makes more programmatic sense since the code that follows acquiring the service is most likely to pertain to consuming that service; throwing the exception allows clients to wrap that code in a try/catch block that easily skips that code in classic exception-handling fashion. In OSGi, the calling code has to keep checking for nulls everywhere, which hurts readability and complicates the flow. Also, Surinam supports Dependency Injection via annotation for service implementations, effectively eliminating this code completely.
  
  
• Extra Baggage
  You must unregister your usage of the service since clients are tracked. Surinam bypasses this problem through the use of default implementations for registered services so that dependencies matter much less. With OSGi, even if you use ServiceTracker, you still need to check for nulls and you still need to call tracker.open() and tracker.close(). This is also a philosophical issue with Surinam that no matter what you do to check that a service is available, it is not atomic so by the time you make the call it may not be there. Therefore, you need to handle that failure anyway.
  
  
• Service Dependency Management
  To get around the issue of deployment dependencies, you can try using a ServiceListener but this can fail if not done exactly right. The recommended way is to override the ServiceListener and write additional code to manage this service explicitly... along with the whole business of closing a service. Surinam requires none of this due to a more straightforward solution which makes this design problem irrelevant.
  
  Also, where you would employ a ServiceListener to detect updates or new registrations, Surinam doesn't require notification when using injected services. Instead, when reshaping the Service Graph, all services are reinjected with all required services. This can result in extra work but serves to synchronize the graph along with the meta-data and tranparently updates a service that may have been partially functional due to a missing resource that is injected when it becomes registered as part of reshaping.
  
  
• Programmatic Management
  While an interactive CLI is very useful, there is nothing that compares to Surinam's Action Documents for managing interaction in a schema-validated and formalized manner while maintaining portability. The Equinox OSGi CLI is step-by-step, whereas Action Document processing is atomic within a Service Block. This allows you to perform complex reshaping of the service graph that would otherwise be impossible. For situations where the service graph is sufficently complex to take a long time to reshape, you could simply apply the Action Document to a second instance of the Service Block at the parent level and switch the invocations over in your software after everything is set up.
  
  
• The Focus of OSGi
  It is not fair to try to compare apples and oranges and while the goal of OSGi and Surinam may be roughly the same, the focus is a bit different. The following is an exerpt is taken from the Felix site describing the project specifically and OSGi generally:
  
  "OSGi technology originally targeted embedded devices and home services gateways, but it is ideally suited for any project that is interested in principles of modularity, component-oriented, and/or service-orientation. OSGi technology combines aspects of these aforementioned principles to define a dynamic service deployment framework that is amenable to remote management."
  
  This is taken to mean that the focus is dynamic service deployment; you can deploy and undeploy (which never goes away). They do have strengths in their lifecycle processes and their model for service visibility. What seems to be missing is a solution for runtime upgrades, formalized service contracts and a management solution akin to Action Documents. In the end, there is room in the industry for more than one solution to this common problem.