I'm working on my first app in Spring and I have a design problem. I've created a few services that I'd like to use through a few facades (is it good idea?).
I'd like to have structure like this
/services
/facades
/interfaces
**facades**
/implementations
**sampleFacades**
/interfaces
**services**
/implementations
**sampleServices**
with package-private services (interfaces and implementations). Is it possible or I have to put all classes to one package?
The Facade Pattern is meant to create a simplified and dedicated access to more complicated code.
Typically you would have an API created by someone else and you would then create your own custom API to consume the other.
In this case you seem to be creating façades to Services in within the same Spring Applicaiton, which to me does not really make sense.
Why create façades when you have control over the service definitions?
If there is a need for a façade for your own service, perhaps they are not defined at the right level of granularity?
Note that some of the complexity of the Services should be addressed by other patterns such as Data Access Objects coordinated by the Services.
Regarding your question on putting all the classes in the same package, consider the Bounded Contexts of Domain Driven Design and organize your code around the domain instead of implementation details.
I have been studying OSGi for a week now. I studied OSGi services but can't find out if every bundle which needs to be imported in another bundle has to be a service. Whether I can use them as simple JARs rather than as services?
If yes, then in what case I should make a bundle as a service?
I hope I made my question clear.
Services are the meeting points between bundles. In general, a bundle depends on a number of services and provides 0 or more services. Since services only specify the contracts, you are ONLY depending on the contracts. This way you separate your actual dependencies (the contracts) from the providers of those dependencies (the bundles).
You will find that your software becomes much more stable over time since it is not affected by all kinds of changes in the runtime environment: refactoring bundles, different implementations, different configurations. You should see services as the hinges of your architecture.
That said, you're not forced to use services. Bundle can import the classes of other bundles and provide classes to other bundles.
So when to use services? Usually a service is an abstraction: a Log service, an Event Admin service, a Geo Service, etc. You know what it should do for you, but you're not interested in the details. In general services can be implemented in different ways.
If the API and implementation collapse into one, it is not a service. A library like ASM (bytecode engineering) or Guava are not services since the API is the implementation and neither library holds state.
First some background:
I'm working on some webapp prototype code based on Apache Sling which is OSGI based and runs on Apache Felix. I'm still relatively new to OSGI even though I think I've grasped most concepts by now. However, what puzzles me is that I haven't been able to find a "full" dependency injection (DI) framework. I've successfully employed rudimentary DI using Declarative Services (DS). But my understanding is that DS are used to reference -- how do I put this? -- OSGI registered services and components together. And for that it works fine, but I personally use DI frameworks like Guice to wire entire object graphs together and put objects on the correct scopes (think #RequestScoped or #SessionScoped for example). However, none of the OSGI specific frameworks I've looked at, seem to support this concept.
I've started reading about OSGI blueprints and iPOJO but these frameworks seem to be more concerned with wiring OSGI services together than with providing a full DI solution. I have to admit that I haven't done any samples yet, so my impression could be incorrect.
Being an extension to Guice, I've experimented with Peaberry, however I found documentation very hard to find, and while I got basic DI working, a lot of guice-servlet's advanced functionality (automatic injection into filters, servlets, etc) didn't work at all.
So, my questions are the following:
How do declarative services compare to "traditional" DI like Guice or Spring? Do they solve the same problem or are they geared towards different problems?
All OSGI specific solutions I've seen so far lack the concept of scopes for DI. For example, Guice + guice-servlet has request scoped dependencies which makes writing web applications really clean and easy. Did I just miss that in the docs or are these concerns not covered by any of these frameworks?
Are JSR 330 and OSGI based DI two different worlds? iPOJO for example brings its own annotations and Felix SCR Annotations seem to be an entirely different world.
Does anybody have experience with building OSGI based systems and DI? Maybe even some sample code on github?
Does anybody use different technologies like Guice and iPOJO together or is that just a crazy idea?
Sorry for the rather long question.
Any feedback is greatly appreciated.
Updates
Scoped injection: scoped injection is a useful mechanism to have objects from a specific lifecycle automatically injected. Think for example, some of your code relies on a Hibernate session object that is created as part of a servlet filter. By marking a dependency the container will automatically rebuild the object graph. Maybe there's just different approaches to that?
JSR 330 vs DS: from all your excellent answers I see that these are a two different things. That poses the question, how to deal with third party libraries and frameworks that use JSR 330 annotations when used in an OSGI context? What's a good approach? Running a JSR 330 container within the Bundle?
I appreciate all your answers, you've been very helpful!
Overall approach
The simplest way to have dependency injection with Apache Sling, and the one used throughout the codebase, is to use the maven-scr-plugin .
You can annotate your java classes and then at build time invoke the SCR plugin, either as a Maven plugin, or as an Ant task.
For instance, to register a servlet you could do the following:
#Component // signal that it's OSGI-managed
#Service(Servlet.class) // register as a Servlet service
public class SampleServlet implements Servlet {
#Reference SlingRepository repository; // get a reference to the repository
}
Specific answers
How do declarative services compare to "traditional" DI like Guice or Spring? Do they solve the same problem or are they geared towards different problems?
They solve the same problem - dependency injection. However (see below) they are also built to take into account dynamic systems where services can appear or disappear at any time.
All OSGI specific solutions I've seen so far lack the concept of scopes for DI. For example, Guice + guice-servlet has request scoped dependencies which makes writing web applications really clean and easy. Did I just miss that in the docs or are these concerns not covered by any of these frameworks?
I haven't seen any approach in the SCR world to add session-scoped or request-scoped services. However, SCR is a generic approach, and scoping can be handled at a more specific layer.
Since you're using Sling I think that there will be little need for session-scoped or request-scoped bindings since Sling has builtin objects for each request which are appropriately created for the current user.
One good example is the JCR session. It is automatically constructed with correct privileges and it is in practice a request-scoped DAO. The same goes for the Sling resourceResolver.
If you find yourself needing per-user work the simplest approach is to have services which receive a JCR Session or a Sling ResourceResolver and use those to perform the work you need. The results will be automatically adjusted for the privileges of the current user without any extra effort.
Are JSR 330 and OSGI based DI two different worlds? iPOJO for example brings its own annotations and Felix SCR Annotations seem to be an entirely different world.
Yes, they're different. You should keep in mind that although Spring and Guice are more mainstream, OSGi services are more complex and support more use cases. In OSGi bundles ( and implicitly services ) are free come and go at any time.
This means that when you have a component which depends on a service which just became unavailable your component is deactivated. Or when you receive a list of components ( for instance, Servlet implementations ) and one of them is deactivated, you are notified by that. To my knowledge, neither Spring nor Guice support this as their wirings are static.
That's a great deal of flexibility which OSGi gives you.
Does anybody have experience with building OSGI based systems and DI? Maybe even some sample code on github?
There's a large number of samples in the Sling Samples SVN repository . You should find most of what you need there.
Does anybody use different technologies like Guice and iPOJO together or is that just a crazy idea?
If you have frameworks which are configured with JSR 330 annotations it does make sense to configure them at runtime using Guice or Spring or whatever works for you. However, as Neil Bartlett has pointed out, this will not work cross-bundles.
I'd just like to add a little more information to Robert's excellent answer, particularly with regard to JSR330 and DS.
Declarative Services, Blueprint, iPOJO and the other OSGi "component models" are primarily intended for injecting OSGi services. These are slightly harder to handle than regular dependencies because they can come and go at any time, including in response to external events (e.g. network disconnected) or user actions (e.g. bundle removed). Therefore all these component models provide an additional lifecycle layer over pure dependency injection frameworks.
This is the main reason why the DS annotations are different from the JSR330 ones... the JSR330 ones don't provide enough semantics to deal with lifecycle. For example they say nothing about:
When should the dependency be injected?
What should we do when the dependency is not currently available (i.e., is it optional or mandatory)?
What should we do when a service we are using goes away?
Can we dynamically switch from one instance of a service to another?
etc...
Unfortunately because the component models are primarily focused on services -- that is, the linkages between bundles -- they are comparatively spartan with regard to wiring up dependencies inside the bundle (although Blueprint does offer some support for this).
There should be no problem using an existing DI framework for wiring up dependencies inside the bundle. For example I had a customer that used Guice to wire up the internal pieces of some Declarative Services components. However I tend to question the value of doing this, because if you need DI inside your bundle it suggests that your bundle may be too big and incoherent.
Note that it is very important NOT to use a traditional DI framework to wire up components between bundles. If the DI framework needs to access a class from another bundle then that other bundle must expose its implementation details, which breaks the encapsulation that we seek in OSGi.
I have some experience in building applications using Aries Blueprint. It has some very nice features regarding OSGi services and config admin support.
If you search for some great examples have a look at the code of Apache Karaf which uses blueprint for all of its wiring.
See http://svn.apache.org/repos/asf/karaf/
I also have some tutortials for Blueprint and Apache Karaf on my website:
http://www.liquid-reality.de/display/liquid/Karaf+Tutorials
In your environment with the embedded felix it will be a bit different as you do not have the management features of Karaf but you simply need to install the same bundles and it should work nicely.
I can recommend Bnd and if you use Eclipse IDE sepcially Bndtools as well. With that you can avoid describing DS in XML and use annotations instead. There is a special Reference annotation for DI. This one has also a filter where you can reference only a special subset of services.
I am using osgi and DI for current my project, I've choosed gemini blueprint because it is second version of SPRING DYNAMIC MODULES, Based on this information I suggest you to read Spring Dynamic Modules in Action. This book will help you to understand some parts and points how to build architecture and why is it good :)
Running into a similar architecture problem here - as Robert mentioned above in his answer:
If you find yourself needing per-user work the simplest approach is to
have services which receive a JCR Session or a Sling ResourceResolver
and use those to perform the work you need. The results will be
automatically adjusted for the privileges of the current user without
any extra effort.
Extrapolating from this (and what I am currently coding), one approach would be to add #param resourceResolver to any #Service methods so that you can pass the appropriately request-scoped object to be used down the execution chain.
Specifically we've got a XXXXService / XXXXDao layer, called from XXXXServlet / XXXXViewHelper / JSP equivalents. So managing all of these components via the OSGI #Service annotations, we can easily wire up the entire stack.
The downside here is that you need to litter your interface design with ResourceResolver or Sessions params.
Originally we tried to inject ResourceResolverFactory into the DAO layer, so that we could easily access the session at will via the factory. However, we are interacting with the session at multiple points in the hierarchy, and multiple times per request. This resulted in session-closed exceptions.
Is there a way to get at that per-request ResourceResolver reliably without having to pass it into every service method?
With request-scoped injection on the Service layers, you could instead just pass the ResourceResolver as a constructor arg & use an instance variable instead. Of course the downside here is you'd have to think about request-scope vs. prototype-scope service code and separate out accordingly.
This seems like it would be a common problem where you want to separate out concerns into service/dao code, leaving the JCR interactions in the DAO, analogous to Hibernate how can you easily get at the per-request Session to perform repo operataions?
I have a Java EE based REST api application. It has a layered architecture like the following:
Resources (Jax-rs resources)
Object Validation
Object Mapper
Service Layer
Repository Layer
JPA Entities
Everything is wired using Spring dependency injection.
I need to design this core application in such a way that it allows other external developers to write extensions/plugins and override or extends any minor or major functionality in the core. Think of it like Wordpress CMS in Java EE if that helps. How would you design a plugin system around the current architecture?
One obvious way that I can think of is override or add new functionality to the proper resource (with validation, objectmapper), service, repository and entity and create a jar + xml out of it. But I want to make sure that the plugin developer has to write the absolutely minimum amount of code to get the new functionality working, while reusing mush of the core code.
Assume, you want to create a wordpress blog post extension that lets you create blog posts with few extra fields that don't exist in core yet. What would be the simplest and cleanest way to go about designing the current Java EE app, so its easy for the plugin/extension developers? Any patterns that could be useful like strategy or template method pattern?
Are there any open source Java CMS that follow the model using Spring/JPA and standard technologies?
I think you mean to extend the functionality, rather than override the core. Typical architecture examples define concerns which can be overridden (separate from core) and make provisions. Eclipse framework achieves this using a combination of plugin-extensions & extension-points mechanism. This is taken further using OSGI bundling.
Another alternative is to breakdown the application into smaller independent modules/services. All you need to do is host these modules over an ESB/Application Integrator (like Mule/Spring Integration) and allow users to configure their version of routing/transformation. Extension would mean creation of new transformers which get added to the message flow.
What is the difference between Declarative and Bluprint Services in OSGi? as both are aim to achieve Dependency injection in osgi.
Is blueprint services is alternative to declarative services?
or bluprint services fills the limitations (if any) of declarative services?
There isn't a trivial answer to that question, I'm afraid. I would recommend reading the specification of both to see the extent of the differences. Declarative Services is section 112 of the Service Compendium, Blueprint Container is section 121 of the same document. You can get the core and compendium documents here:
http://www.osgi.org/Download/Release4V42
For me though, the most significant difference is that (in DS terms) a Blueprint service can be made active without the services it depends on being present. The container creates proxy services which block until an actual implementation is made available. I believe this is akin to Spring's approach and that people who are used to using Spring's IOC/DI approach will get Blueprint instantly, though I could not comment from personal experience having never used Spring or Blueprint (yet).
Since we are dealing with OSGi services it is possible to mix and match DS and Blueprint as you see fit. So far I haven't found a need to do anything more complicated than can be achieved with DS, so am not sure what use case the Blueprint Container specification meets, though from the spec it does look as though Blueprint provides quite a lot of functionality in order to make component development simple.
I believe it has been added primarily because J2EE developers will find it familiar, but that is just my opinion. :)
I realize this is an old thread, but I think the question is still important.
I agree with the others who said that BS better hides dynamic nature of OSGi than DS.
Also, it looks like DS was meant for binding among bundles, while BS can be used to build object graphs "for internal consumption".