Re: [aerogear-dev] SwitchYard/Camel Integration

Hi Dan, looks nice and simple. One quick question, is there more as a guide, or is there a plan to have some "plugins" (e.g. an additional JAR containing something like you described for the CamelController.java)? Greetings, Matthias On Wed, Jan 2, 2013 at 2:16 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com > wrote: > > AeroGear Camel/SwitchYard Integration > > There have been inquiries about how existing services could be exposed > using AeroGear Controller, and this document will try to sort out why > someone would want to do this, and also try to come up with some possible > solutions. > Why would you want to do this? > > Currently one can already expose a service as a RESTful endpoint in Camel > using Camel's CXFRS Component <http://camel.apache.org/cxfrs.html>;. The > same goes for a service in SwitchYard that can be exposed using the RestEasy > Component<https://docs.jboss.org/author/display/SWITCHYARD/RESTEasy+Bi... > . > > So, a few reasons why users might opt to expose their services through > AeroGear controller: > > - Consistent way of exposing enterprise services externally for mobil > developers > - Security > > Camel Integration > > Using Camel to integrate with existing services is a great option as > Camel has a huge number of components<http://camel.apache.org/components.html>;. > There is a SwitchYard Camel component too, so integrating with SwitchYard > would also be possible using Camel. SwitchYard also has a new > RemoteInvoker<https://docs.jboss.org/author/display/SWITCHYARD/Remote+... which > could be used for SwitchYard specific services and would be a separate > controller class. > > The goal here is to make things as flexibile as possible as it is > difficult to try to account for different types of services. As a > suggestion, an AeroGear Controller route that invokes a service using Camel > might look like this: > > public class Routes extends AbstractRoutingModule { > > @Override > public void configuration() throws Exception { > route() > .from("/cars/{id}") > .on(RequestMethod.GET) > .to(CarServiceController.class).getCar("direct://input", param("id")); > }} > > CarServiceController.class might look something like this: > > public class CarServiceController extends CamelController { > > public String getCar(final String endpointUri, final String id) { > return (String) producerTemplate().requestBody(endpointUri, Long.valueOf(id)); > }} > > CamelController is very simple and gets injected with a CdiCamelContext > and creates the ProducerTemplate. > > public abstract class CamelController { > > @Inject > private CdiCamelContext camelContext; > private final ProducerTemplate producer; > > public CamelController() { > producer = this.camelContext.createProducerTemplate(); > } > > protected ProducerTemplate producerTemplate() { > return producer; > }} > > We are simply making an instance of ProducerTemplate<http://camel.apache.org/maven/current/camel-core/apid... available > to users, and they have access to all the methods of that interface. This > will enable users to send one way messages, request/response messages, and > also prepare the arguments to the service and process the result if needed. > > A ProducerTemplate is created from a CamelContext. One can have multiple > CamelContext's per application/deployment but the most common is that each > deployment has one CamelContext. In this case we are injecting > CdiCamelContext. > > We could also add additional methods from ProducerTemplate to > CamelController which just delegate, for example: > > public abstract class CamelController { > > @Inject > private CdiCamelContext camelContext; > private final ProducerTemplate producer; > > public CamelController() { > producer = this.camelContext.createProducerTemplate(); > } > > protected ProducerTemplate producerTemplate() { > return producer; > } > > protected Object requestBody(final String endpointUri, final Object body) { > return producer.requestBody(endpointUri, body); > } > //...more methods like requestBody} > > This would save subclasses from having to call producerTemplate(). > SwitchYard Integration > > As mentioned above, SwitchYard has a RemoveInvoker that could be used for > invoking services from a remote client. This could be used in an AeroGear > route: > > public class Routes extends AbstractRoutingModule { > > @Override > public void configuration() throws Exception { > route() > .from("/server1/{id}") > .on(RequestMethod.GET) > .to(SwitchYard.class).invoke( > "http://localhost:8080/switchyard-remote", > "CarService", > pathParam("id")); > }} > > SwitchYard is again very simple: > > public class SwitchYard { > > public static final String REMOTE_SERVICE = "urn:com.example.switchyard:remote"; > > public Object invoke(final String url, > final String serviceName, > final Object payload) throws IOException { > return new HttpInvoker(url).invoke(new RemoteMessage() > .setContext(new DefaultContext()) > .setService(new QName(REMOTE_SERVICE, serviceName)) > .setContent(payload)) > .getContent(); > } } > > The original gist can be found here: https://gist.github.com/4152998 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev