Do we hava a complete step by step tutorial on how to implement a full fledged REST (whether JAX RS or CFX-DoSGi) in OSGi/Enroute? If so, the link would be really helpful..Thanks..
From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] On Behalf Of Christian Schneider Sent: 06 November 2016 23:13 To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Subject: Re: [osgi-dev] RS/RSA for exposing JAX-RS resources ** This mail has been sent from an external source ** CXF-DOSGi + Aries RSA is not really more complicated than any other alternative. For example the JAXRS connector from Holger Staudacher works in a very similar way and is similarly complex. If you only use DOSGi on the server side then it simply listens for OSGi services with the magic properties and calls CXF to instantiate the endpoint. There is not much more to what Aries RSA does if you do not use discovery and the client side and you do not have to. The two additional properties will not really make it more complex. In both cases DS does the full lifecycle management of the service. The main difference is that with the JAX-RS connector you are stuck with an implementation created by someone and no real community and commercial support. Remote Services is a standard and Aries RSA, CXF-DOSGi as well as ECF have good communities behind them. About the complexity of CXF-DOSGi... Look into that code and tell me it is complicated: https://github.com/apache/cxf-dosgi/blob/master/provider-rs/src/main/java/org/apache/cxf/dosgi/dsw/handlers/rest/RsProvider.java https://github.com/apache/cxf-dosgi/blob/master/common/src/main/java/org/apache/cxf/dosgi/common/intent/impl/IntentManagerImpl.java These 400 lines are almost the complete code of CXF-DOSGi on the JAXRS side. The Aries RSA code of course is also involved but it is also not complex and very well tested. CXF-DOSGi is able to support almost all advanced features you need like exception handlers, message body writers and readers, ssl, ... The performance of CXF is amond the best in any JAXRS implementations. So I think for beginners the jaxrs connector might provide a little faster start but you soon hit a dead end while RSA allows you to start with REST but then grow with your needs. In the end it is your own choice but I could not leave all these assumptions and conclusions you did uncommented as I think many are not true (anymore). CXF-DOSGi has come a long way in the recent years and I think it is worth another look. If you want to try it I will try to do my best to help. Christian 2016-11-06 15:05 GMT+01:00 Ancoron Luciferis <ancoron.lucife...@googlemail.com<mailto:ancoron.lucife...@googlemail.com>>: On 05/11/16 16:49, Scott Lewis wrote: > On 11/4/2016 9:38 AM, Ancoron Luciferis wrote: >> <stuff deleted> >> Simply looking at the DOSGi architecture [1] (which just follows what >> the specs demand) is an absolute overkill for the use case of simply >> having a DS-annotated JAX-RS resource being exposed via HTTP service. > > I assert that a full understanding of the RS/RSA architecture is largely > irrelevant to using RS/RSA for your and many other use cases. As an > alternative approach to understanding what's necessary, consider the > tutorial at [1]. From an operational perspective that's simply not true. As a developer you might simply take the tutorial and you might be good to go - functionality-wise. But: How do you ensure that what you have developed will also work in all stages/production? How do you ensure that you can guarantee that the ReST endpoint will be available? How do you ensure that troubleshooting doesn't reveal that you don't know much about the technology you're using? Without (at least) knowing about the full concept (specs) and at least some of the internals of the actual implementation you cannot be serious about the service you're about to develop/publish. At least I wouldn't. One of the key concerns in a software life cycle is risk management. Each library/tool that is used at runtime which I don't know much about is a risk factor and represents a point of failure. > > I think that the approach taken by RS/RSA provides the necessary balance > between having a general and flexible architecture able to handle more > than a few use cases, but also providing a simple, well-integrated > api...(i.e. a Remote Service is just an OSGi service with some standard > service properties, and so can be used seemlessly with DS, any/all code > written for local services, etc). That's completely true. However, the word you've used describes it pretty well: 'balance'. What this essentially means is: trade-offs. In the end, what I have seen so far (only having used CXF DOSGi and Karaf Cellar DOSGi) was not enough for my use-cases: * (de-)serialization (JSON/XML/... - MBR/MBW) * performance * integration with standard JAX-RS aspects (interceptors/filters/...) If you already have picked an implementation (Jersey) and the use-case doesn't demand a node-restricted service within a cluster (which for me would be the only use case to consider the overhead for RS/RSA), I'd look for a tool that was build for that purpose. That's how I found about the osgi-jax-rs-connector, which doesn't require my services to include any specific stuff (e.g. service properties) but still allows me to go as implementation-specific as I want/need (tuning, integration, monitoring, security, ...). And best is it doesn't introduce new infrastructure pieces (for RS/RSA: Topology Manager, Service Discovery, ...) which I have to learn about, operate and troubleshoot. I have learned that myself the hard way: Simple is better than complex. Complex is better than complicated. And RS/RSA is not simple as it's major concern is about addressing some problems (or claiming to) in the domain of distributed computing. As a result, implementations must take that complexity to enable a simple user-/developer-experience. This complexity must either be understood and actively managed by all parties (administrators/dev-ops/tester/developers) or represents a risk for the software component as a whole otherwise. So, if your use-case does not make use or require the distributed computing feature of RS/RSA, then what's the reason for taking the risks? Even if it is possible to simply not use the remoting/clustering features of an RS/RSA implementation but only use the JAX-RS integration feature (remember that RS/RSA is not about ReST - just about remoting), then what's the reason for taking the additional footprint? You'd still need the basic infrastructure services up and running - even locally in a single JVM which is just waste and (from my perspective) goes against the principles of OSGi. Cheers, Ancoron -- -- 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> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
