General
Technical Details
No. You can create a ServiceBlock as a Spring bean and use it as a fine-grained hyper-dynamic module.
There are too many variables for there to be one answer. It depends on the type of project you are building, how much hyper-dynamic behavior you want, the lifecycle plan for the software, etc.. We can talk about the extremes; on one hand, you could put all of your business logic inside of ServiceBlocks making nearly the entire code base hyper-dynamic and on the other, you just have a single pluggable Service that you want to be able to upgrade over time. In the latter case, your ServiceBlock would only have one service in it.
Like other frameworks, most of the processing is front-loaded whenever possible (during initialization). However, graph reshaping is currently performed atomically so that service calls into the ServiceBlock will block while this occurs. However, the introduction of Service Assemblies makes it possible to perform fine-grained optimizations of the performance characteristics of your application. In human terms, reshaping occurs fast enough to seem instantaneous.
Surinam Services are intended to be completely decoupled from the software that is leveraging that service just as if it was written and maintained by an external developer. Many other frameworks allow for intermingling of classes and paths which often pollutes the runtime environment. When Surinam makes a service implementation go away, that loader is released for garbage collection and once that happens... it's truly gone along with any classes it may have loaded.
No, the root directory is just the base location and is optional although highly recommended, you are free to create any organizational scheme under the root that makes sense. It's even possible to not use the root designation for some deployments; see the FAQ about environment variables for more information. If you are familiar with Maven repositories, this concept should already be familiar to you since they have already developed a repository structure that is comprehensive; in fact, you would use a local Maven repository if you wish. If you have questions about how you could manage your service jars, that would be a great place to start.
Surinam and OSGi take two different views of the question of how to make software more dynamic. The two approaches are trying to solve similar problems that lie at different levels of granularity. Surinam tries to make things dynamic by fixing the small problems first, whereas, OSGi tries to work at a broader level. Surinam tries to avoid forcing you make either/or choices; in fact, the two approaches are compatible and could be combined in the same system.
Yes. The project collateral almost exclusively talks about how to work with a single Service Block but the isolation provided by the framework correctly implies that you could build as many as you would like. The idea of collections of shared Service Blocks presents whole new vistas of possible architectures; how useful that might become is left to the community.
Actually, you are not required to define one. Surinam needs to be able to build paths to the service jars in a machine independent way in order to allow for the case where ActionDocuments are transmitted to multiple machines that might differ in their local setup. This lets each machine specify where it will store the service jars as a root location so the ActionDocument only contains the relative path from that root. You are free to build your own paths when controlling things programmatically but when using ActionDocuments, the given paths in the XML are appended to the SURINAM_DEPLOYMENT_ROOT variable if it is defined. If not defined, you simply get the paths in the ActionDocument as given; this can be awkward if you are deploying to a server which will have its own organizational scheme to contend with or on multiple machines. Environment variables have the benefit of being standard across technologies and they can be defined in launch scripts as opposed to having to do it globally in the OS.
Yes. Since they are XML, they can travel easily over networks, presumably between Surinam-aware processes. Be aware that Dependency Injection data will travel with the ActionDocument, which can be a good thing but if it is not what you want, you need to account for that.
Yes. Managing a Service Block programmatically will give you ultimate control over a block but you will greatly increase the amount of code you need to write.
No. You can use ActionDocuments to deploy and manage services in a block.
Yes. As of version 1.1, there is Dependency Injection support for primitive data types along with arrays, lists, maps and other Managed Services.
Yes and No. If you want all your deployed services to use the same versions of libraries, include them at the parent level outside of the Service Block and make sure that those classes do not exist in your included jars at the service level as the greedy loading mechanism will prefer those. This behavior also makes it possible to override global classes to use different versions of a class as they will be loaded locally in the Implementation Loader if it is on that Implementation's classpath (called out in the ActionDocument if you are using them). While this might seem less than optimal, memory is no longer as expensive as it used to be and allowing multiple copies of a library is a far better trade-off than the complexity and inter-dependencies that come out that type of resource sharing. It is in this that Surinam most accurately mimics an SOA where the services are on different machines, physical or virtual.