I think the main feature of the MicroWebServer approach you show is that you can define multiple endpoints for the same impl. This is indeed a niche that Aries RSA does not fill and does not try to fill. So it might be a good case for people to use it.
About blueprint without OSGi.. I think it is great for testing but if your application really is not OSGi based I would not bother with it and just use spring or another non OSGi dependency injection. Microservices and docker are indeed very popular at the moment. Still I think it makes sense to use OSGi. On the other hand it would also be overkill to use a full blown karaf server for it as you will only host one application per process. We are currently working on karaf boot which attempts to support this style very well. It will support a mainly annotation based developement model like spring boot. On the packaging side you can use the static karaf profile to package your application using karaf features into a fixed set of bundles at build time. So at runtime you still have karaf but without the feature service so the runtime is simpler and nicely suited to host one single application. Christian 2016-04-17 17:14 GMT+02:00 Brad Johnson <brad.john...@mediadriver.com>: > I took a look at RSA and DOSGi again. I'd forgotten the RSA acronym so > didn't recognize that I had looked at it before. My conclusion is very > similar to your own. They are orthogonal concerns with a small amount of > overlap.. I think what would make the determination of which one to use, > for me, would be a very explicit context. Obviously what I made isn't > really about remote management or distributed architecture. It is more > tactical than that and related to specific bundles. So if someone were to > ask me about a solution for a server farm the MicroWebservice would NOT be > on the candidate list. The MicroWebservice does use the OSGi whiteboard to > listen for the MicroWebservice registration events. Because it always uses > the same OSGi registration service interface 1 .. N MicroWebservers can > listen for the same events with their list-listeners and you could filter > on service properties. I forget the LDAP filtering syntax off the top of > my head. > > I just got tired of having to set up and re-set up so many different > blueprint configurations fro different endpoints. And if you try to > centralize that in something like gateway bundle now you have an issue that > when the provider bundle is undeployed the web service is still hanging out > there in space disconnected. With this mechanic if you undeploy your > bundle all the standard Aries blueprint mechanics trigger the removal of > the web services associated with a given bundle. But all of that relies on > your Aries OSGi mechanisms with blueprint to function. It can't exist > without it. That's part of why I thought of mentioning it here first as it > might actually fill a niche need for Aries or Aries users. If folks here > got interested in it then maybe you'd adopt it some day. Who knows. But > at least I'd get more eyes and thoughts and solidification to it as well. > And if folks don't find it fits any need for them, then I won't waste a lot > of time on it either. > > For better or worse microservices are the fashion today. As a consultant > I don't get to make the call and don't even bother fighting the trends or > fads unless they make specifically bad fits for specific situations. > > > It's sort of like the library you have that I was looking at a little last > night that bootstraps blueprint files without OSGi. That is simply another > way of doing something that Spring, Guice, etc do it but it doesn't make > OSGi or Spring obsolete. But it is nice to have in the toolbox. I've been > using blueprint for the past 4 years or so and being able to use a modified > form of it for wiring up and booting little applications is nice. I don't > have to switch to a different dialect like Spring (although I used to use > that heavily in the olden days). So the MicroWebservices is just another > way to use the standard CXF, Blueprint and OSGi mechanism to ease the pain > of web service set up and configuration. > > As I get more, uhm, mature it is fun to watch how new fads come into > being. Docker and Kubernettes are the rage and I certainly understand the > underlying technologies. But how often do you see folks just grabbing hold > of them because they are the latest, coolest thing? I like Docker > conceptually but working in karaf/blueprint/OSGi I'm not sure I have that > many instances in my enterprise applications where I'd have a great need > for them. On the other hand, if I have a client insistent on them then > seeing a tool like your blueprint without OSGi becomes far more > interesting. > > > On Sun, Apr 17, 2016 at 7:01 AM, Christian Schneider < > ch...@die-schneider.net> wrote: > >> 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 < >> <ch...@die-schneider.net>ch...@die-schneider.net> 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 < <brad.john...@mediadriver.com> >>> brad.john...@mediadriver.com>: >>> >>>> 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 Schneiderhttp://www.liquid-reality.de >> >> Open Source Architecthttp://www.talend.com >> >> > -- -- 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>
