I have now created the Aries Remote Service Admin project. See http://aries.apache.org/modules/rsa.html
It has similar features to what you described but also is an OSGi standard. So you can nicely extend it while not needing to implement all yourself. Christian 2016-03-14 15:37 GMT+01:00 Ranx <brad.john...@mediadriver.com>: > Christian, > > I'll take a look at that. > > The nice thing about using the white board as a webservice registration > mechanism is that I can define all my interceptors, handlers, and security > in a single project. Then when a bundle is installed it registers itself > for exposure. My new server project picks it up an creates JAXWS and JAXRS > servers/endpoints for the bundle and exposes it. > > When the bundle is uninstalled the unregister method gets called on the > manager and that then undeploys the related endpoint. No dangling > resources > or proxy time outs. > > My manager project keeps a map of the registered microservice and as a > convenience in my basic implementation of the microservice I instantiate a > UUID to a final String on it and return that as the unique identifier. So > when the bundle is uninstalled and the manager receives that notificatoin > and simply calls to get the unique identifier to pull the container object > that holds the JAX WS and JAX RS servers in it. It calls stop/destroy on > them and nulls the handles out in the container as well as removing it from > its map/regsitry. > > Now when the microservice installs it gets auto deployed with all my > security and logging and badgerfish settings. It is also automatically > invoked by a web service call without having to configure routes. As for > the use of Camel routes, I've now inverted that so that the routes I use > live only in the bundles and don't talk across them. The service > interfaces > are for cross bundle talking. So all my projects now have a "connector" > class and I'm using @EndpointInject to inject the camel routes. > > So when the bundle gets deployed, it is auto installed as a webservice if > it > exposes itself via the whiteboard/service registry. When the service is > called it invokes the implementation class which holds a handle to the > connector. That endpoint can then call 0..N camel routes. In a way it is > like using an inverted Camel Java DSL. > > Because that connector class wraps the camel routes any casting or fishing > of references out of lists (like MessageContentList or BeanIO arrays) can > be > done inside that object and not be visible to the calling class. The > caller > is just invoking a method on a POJO and getting a response back. > > The only downside is I'm now having to use the JAX WS and JAX RS service > factories directly and creating the endpoints myself as the Camel or at > least Camel/blueprint wouldn't permit that sort of dynamism. > > Because I'm using that service registration mechanism I can also > instantiate > multiple managers bound to different ports with different > security/transports and simply filter on the OSGi microservice registration > to determine if it should expose it or not. So if I have different > security > requirements for invoices, supplier look up, etc. I can set that up in one > project and then whatever bundles get installed and register themselves > correctly will get picked up and exposed automatically. > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/CXF-cross-cutting-concerns-tp5778798p5779020.html > Sent from the Camel - Users mailing list archive at Nabble.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>
