What is the correct way to get a service, hopefully using Declarative Service if possible, when you don't know the attributes of the service to request until after runtime?
The use case is analogous to having 3 bundles providing services version 1.0, 2.0 and 3.0 but not knowing which one will be consumed until the user chooses one in the UI. If the user chooses 2.0 the consumer will consume the stuff from bundle 2.0
We are using BND annotations, so something with them would be ideal, but i have a feeling that we need to use the OSGi API directly instead of using annotations or declarative services injection.
Finally, if it is relevant, this is more to get different versions of a resource (XML schema) rather than about different behaviour/implementations. The idea was that the service would be providing its internal resource, which would be different in each version, even though the code in the service itself would be the same
I've worked in a similar system before and we had our own "routing" system. Basically when you register the services add the version number in the meta-data. Then in this routing mechanism pick the correct service. Your services will need to implement a common interface and in the router inject a List of them.
The declarative model of the Declarative Services specification is a build-time model, not a run-time one. To do run-time dependency management, you either need to do it yourself with a ServiceTracker, or use a different dependency management solution.
As one of its authors, I have a preference for the Apache Felix Dependency manager [1] which allows you to "declare" dependencies in Java code (at run-time, for example based on a choice made by a user in the UI like you say).It does not use Bnd annotations, but the code still allows you to use a declarative style and provides features like injection and/or callbacks.
Another solution that allows this is Apache Felix iPOJO [2].
[1] http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html
[2] http://felix.apache.org/documentation/subprojects/apache-felix-ipojo.html
Related
For an application written using OSGi specifications
A service is a java object that represents a feature, recording a voice call for example
Every service has a number of packages associated with it, for example, service interface, service implementation, and slick.
I can't get the relation between the above and OSGi bundles, as bundles contain services does that mean they contain the service packages or something else
An OSGi service is a mechanism for bundles to communicate over a well defined Java interface known to all parties. OSGi acts as a broker where one party can register a service under the interface name, and other parties can get it under this interface name. I.e. the actual implementation class is decoupled from the users of the service. This allows the use of different implementation classes while the user of the service is unaware. I.e. for example, if you want to set up a voice call, there could be an PhoneExchange service that would provide you with the functions to setup the call and maybe record it. You can then write your code against the PhoneExchange interface. In runtime, you might be coupled to an Ericsson PBX or a Nokia one.
This decoupling is also present with Java factories. However, Java factories have many disadvantages, and tend to be very static. The OSGi broker is a dynamic broker. A service can be registered but also unregistered. The dynamism in OSGi is seen by many as hard to handle but the Declarative Services makes that more or less trivial. When you really get the dynamism of OSGi services you will find out that many complex dynamic scenarios, like for example communication channels, map extremely well.
The bundle is the module in OSGi. It contains all the Java code and resources. A bundle will export and import Java packages. In a well designed system, these are only the Java packages that hold the service interfaces. It is a bad pattern to export implementation packages. At startup, bundles are wired. This means that exporters get bound to importers. OSGi is unique in that it can handle the same package in multiple versions.
Bundles have their own life cycle. They get started and stopped. In both cases, they can run their own private code.
The aforementioned Declarative Services provide yet another layer. When a Java class declares it is a component with an annotation, it can also declare on what services it depends. When these services are registered, they are injected and the component is activated. Declarative Services allow you to eat your cake and have it to. You get the incredibly powerful dynamics without the associated complexity.
I'm currently using aspectj to handle transactions in my Jersey RESTful classes. But I want to dump it for simplicity and consistency reasons (less technologies -> more transparency, better IDE support). I also want the REST get method implementations to return a w3c document class, ie. having a post-exec hooks that transforms results.
Does Jersey provide pre- and post-exec hook that allow me to initiate and close transactions and perform transformations on results returned to the remote end?
Assuming you're using version 2.x, Jersey has built in support for this, using Event Listeners. You can use a RequestEventListener, and the RequestEvent give you access to all the goodies. Matter of fact, for transaction handling, this is actually the way Dropwizard handles it.
If the event handlers doesn't suit your needs, there is more of a "natural" AOP support from HK2 (which Jersey uses for DI). Check out this article for a complete example integrating with Jersey.
I am writing a library which contains a domain model and uses the Bean Validation API. My goal is to have minimal amount of dependencies. Hence, without CDI, Java EE and Spring. Allowed Dependencies are to APIs only like JSR-349 and JSR-330 API.
I can not make any assumptions about how my library is going to be used. It might be within a container or as desktop application. Forcing the library user to have an CDI, Spring, or validation implementation is not an option.
Right now, I use the bean validation API to allow the user of my library to validate the model itself. But I would also like to use Method Validation in some cases.
My questions are:
What options do I have if I want to use method validation within a
library project?
Do I have to ship my library with an aspectj runtime dependency?
Does it make sense to use Method Validation in a domain model?
How is your library going to be used? Chances are that applications using it are running within CDI, Spring or another kind of container anyways, then delegating method validation to the same would be sensible.
If you really want to go for your own solution, it really depends on how the instances of your domain model are created. If you have interfaces and the user obtains instances via a factory, you might have a look at JDK dynamic proxies. Alternatively, you could check out Javassist or Cglib if you don't work with interfaces but with classes. That'd still require that your domain model nodes are obtained via a factory in order to return properly proxied instances.
Whether it makes sense or not surely depends on your specific model and its use cases. When it comes to validation of a model, property (and class-level) validation surely is the more common case, but if you provide business methods on your model and want to validate their parameters or return values, it may make sense.
1) without CDI I would recommend apache BVal or any jsr303 specific implementation that does not require being container managed.
Since the jsr targets the java-ee platform it seems some container must manage it. what container you choose depends on the extra dependencies that must be shipped with the application.
Bval itself does not require anything other some core apache helper libraries.
2) Bval and other implementations of the jsr303 spec will need some kind of java ee container. It is a backing principle behind java ee. If no java-ee enviroment is present, bval will require a di framework to hook into.
If guice is chosen as the container; it uses cglib for its bytecode and it uses aop alliance interfaces for its aop (implemented internally with the help of cglib).
Spring does require aspectj.
If CDI is chosen, it would depend on the CDI implementation used.
3) If you are attempting to simply do method level validation, it does make sense to simply do the validation by hand in the class setter/getter itself. Specially if you want to remain platform independant.
Method level validation through the use of third party libraries only makes sense when you are using third party containers. If you are trying to have a base simple java se application, it does make a great deal of sense to put the validation in the data objects themselves and have your exception handling strategy take care of issues to the user.
The answer to three will always be rather subjective, but if you really are not looking to use a mass amount of frameworks, I don't think its bad practice to do the validation in the methods themselves.
My (perhaps all-too-simple) understanding of EJB3 is that its a way of turning a POJO into a Java EE-compliant unit of business logic. It is reusable and can be "plugged in" to different backend architectures spanning multiple projects. It's a step in the direction of true component-driven architectures. If any of these assertions are untrue, please begin by correcting me!!
If I am correct on these items, then I'm wondering how/where/when/if EJB3s snap into an ESB like Apache Camel. With Camel each endpoint typically implements some EIP like WireTap, Filter, or Transformer. I'm wondering which of these EIP/SOA patterns the EJB (specifically EJB3) fits into. Is it a simple Filter? Something else?
I guess at the root of my question is this:
If I'm building a Camel Route, when does it makes sense to make an EJB3 an endpoint, as opposed to some other EIP? What are the use cases for EJB3s in an ESB and when are they preferable over other EIPs?
There is no right or wrong in this case.
EJB plugs very well into JavaEE application servers and are built to provide an architecture to encapsulate the business logic as Java code inside EJBs and let the application server handle scaling, throttling, fail over, clustering, load balancing etc, as well as exposure of the EJBs to communication protocols (Web Services or JMS for Message Driven Beans).
I see no real point in introducing EJBs as business logic containers in Apache Camel, unless you already have a full stack Java EE application that you want Camel to work with.
Camel has a great set of features to connect to "real" pojos through bean-binding.
I would recommend using simple java beans/pojos for business logic, and you can easily plug them in at any other application through camel's rich set of connectors. There are multiple options for implementing the different camel EIPs. One common way is with java code, but XSLT for transformations and groovy for filters is just as common. I would never use EJBs for simple filters, but rather invoke some complex logic inside a Java EE app. server, or typically avoid all together (except MDBs) and look at JMS communication with the application server instead.
Basically an EJB is a service. The idea behind a service is that it can simply be used without needing to create it as a consumer. Additionally services often can be looked up in a registry.
So my advice is to use the simple bean integration for cases where it is easy to instantiate the bean impl and to use services where it is difficult. So you can encapsulate the initialization inside the component that provides the service.
I am not using EJBs regularly but often use OSGi services which are very similar in concept to EJBs.
In addition to previous answers I'd mention that SOA is rather approach with specified requirements than a concrete technology stack. Make your EJB3 beans or OSGI services be operable via network regardless to operations systems, platforms and languages at least and you will have service-oriented system. So EJBs and OSGI or Spring-powered applications do fit to SOA when they do fulfill its requirements.
For instance, I am using JSF + custom framework developed in our company. Now I want to use a third party validation framework that can be used as an plug-in and it should not create any dependency what ever may be the technical stack.
So my question is does spring provide any framework of that sort or if it's available how can I use that?
I am expecting a validation framework something like, which is configurable through XML.
Spring does have a validation framework, but if you want minimal dependencies, then I'd suggest that you go with a Bean validation provider. It's a new(ish) official validation standard, defined in JSR-303.
There are several implementations at the moment. I'd give Hibernate Validator a look.
I disagree. Hibernate Validator is an awful piece of software (at least the versions that were current about a year ago). Spring Validation is a nice piece of software, that goes together well with the BeanWrapper interface.
But it's true: Spring Hibernate resides inside the Spring Context jar, which is unnecessary overhead. Hopefully there will be a separate version sometime.