Thanks for the explanations. I think I now understand better.
In effect it does a similar thing but with a different focus. Aries RSA
and the CXF provider focus on the whiteboard pattern to kind of
transparently export/import a service. Both do not have strong out of
the box support for managing and centralizing configurations. It can be
done but it less prepared than in your framework.
This is an example of how to export a rest service:
https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist-ds/service/src/main/java/net/lr/tasklist/service/TaskServiceRest.java
Your framework is more similar to the CXF blueprint namespace as you
have to explicitly export a REST or SOAP service using blueprint. It
focuses on the configuration aspect by managing a system wide and per
service configuration. Something l really like there is the do a lot of
the config system wide this is something I would like to add for Aries
RSA too.
I really like the whiteboard approach of RSA as it allows to have no or
minimal dependencies from the user code to the framework. So maybe you
are interested in combining the capabilities of both.
RSA now has a custom service provider interface ExportPolicy. This is a
hook where you can do system wide configuration and also things like
auto exporting services based on annotations.
I think you can achieve the same level of manageability in RSA as with
your framework but it is not there already. If you are interested in
helping out there I can help you to get into the code.
Christian
On 17.04.2016 01:08, Brad Johnson wrote:
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] <mailto:[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] <mailto:[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>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
