I'll have to look at the Aries RSA as I'm not as aware of it. It doesn't
appear to be similar to DOSGi from my experience with it. I'll take a look
at them again tomorrow. Like so many things in our OSGi, ServiceMix, Camel
world there are about 10 different ways to do everything. Some are better
than others and most are better in certain circumstances. This design is
in reaction to consulting on a job that involves a company which is
integrating multiple smaller companies that it owns and they all have a
little different security, different ports, different web service
requirements but are commonly going to be talking to the same Fuse instance
in many (but not all) cases.
This uses the OSGi mechanics for registration only and it doesn't require
that the the interface itself be an OSGi service. Here is a listener on a
blueprint file for the MicroWebserviceManager. I'm not filtering on any
service property but but I certainly could. The manager has a
configuration associated with it for standard interceptors, etc.
<reference-list id="microserviceListener"
interface="org.enjekt.osgi.microserver.api.MicroWebservice">
<reference-listener bind-method="register" unbind-method="unregister">
<ref component-id="microserviceManager" />
</reference-listener>
</reference-list>
The simple Echo bundle I have in there has this in its blueprint.
<service interface="org.enjekt.osgi.microserver.api.MicroWebservice">
<bean class="org.enjekt.osgi.microserver.impl.MicroWebserviceRegistration">
<argument value="org.enjekt.osgi.api.echo.EchoService" />
<argument ref="impl" />
<property name="restRelativeURI" value="/resources/echo" />
<property name="soapRelativeURI" value="/services/echo" />
</bean>
</service>
That MicroWebServiceRegistration inherits from the same class that the
.MicroWebserviceManager uses for configuration. When this simple Echo
bundle starts it registers as a MicroWebService and the manager picks it up
and combines the configuration found in both. As you can see registration
isn't specifying the host/port information so the one used by the
MicroWebserviceManager will be used. However, if I did specify a different
host/port in the bundle's properties that would be used instead. The
manager itself never actually creates the server/endpoints. It
instantiates a container that it keeps in a map and that container
instantiates the server/endpoints based on the combined information.
Obviously if I uninstall the Echo bundle this particular MicroWebservice is
unregistered, the manager is notified and it tells the container to shut
down the endpoint. Those hard coded properties for restRelativeURI and
soapRelativeURI would normally be part of the blueprint properties and so
settable at runtime triggering a reload. That in turn triggers the manager
to tear down the old endpoint and start up a new one. Since the
MicroWebserviceRegistration can accept the same sort of interceptors and
providers that the manager uses I've used that as a way to register
error/exceptionhandlers as well and in one case to override the JSON
provider configuration. One department wanted badgerfish and another
wanted the root stripped and unwrapped. Just specifying those differently
in the sending bundle I could override the defaults. If I wanted to I
could also use different registrations to expose the same service on
different relativeURIs or ports with different configuration information.
Here's an example of a service adding in an exception handler.
<property name="addProvider">
<bean
class="com.foo.internal.exceptionhandlers.MyExceptionHandler" />
</property
If that's added to the manager's configuration then all endpoints that
register with it get that exception handler. If it is registered with the
bundle's MicroWebserviceRegistration then that only applies to it. In this
case it is in an internal package but gets provided via the web service.
The MicroWebserviceRegistration also provides a UUID so when it the bundle
is uninstalled and the manager gets notified of the fact it knows which
container to pull from its registry and shut down.
Just looking at that EchoService if I have three different divisions with
different security and REST/SOAP requirements I can have three managers
running via a simple blueprint set up of their service managers with
service property filters for company A, company B, company C and when I
register the EchoService I can specify different relative URIs but let each
of the managers determine how the interface is actually going to be exposed.
It works very well. In practice I have most of the properties relevant to
the bundle's requirements exposed in the cfg files making changes simple.
I'll take a look at RSA tomorrow and see how it works.
Brad
On Sat, Apr 16, 2016 at 1:42 PM, Christian Schneider <
[email protected]> wrote:
> Hi Brad,
>
> from what I understood it allows to expose OSGi services as SOAP and REST
> endpoints. This sounds very similar to Aries RSA and CXF DOSGi. Can you
> explain what it does differently?
>
> Christian
>
> 2016-04-16 17:39 GMT+02:00 Brad Johnson <[email protected]>:
>
>> https://github.com/Ranx0r0x/Enjekt-Microservice
>>
>> I've started a project that may or may not be of interest to the
>> community. I've been finding it of great benefit in my current projects
>> where I combine it with Camel for certain items. One change I plan on
>> making as soon as I can get to it is to change the BOM from importing Fuse
>> dependencies to Servicemix. That should be relatively simple but I'm
>> working with it in Fuse currently so it hasn't been a high priority.
>>
>> Any feedback is appreciated.
>>
>> Brad
>>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
>
