Hey Bruno,
I totally agree. I should have been more clear regarding these controller
classes, they would not be part of AeroGear-controller but as separate
projects.
Controller to our enterprise scenarios, but now would be important to
finish our pagination support on Controller, at least for CR1.
The paging support is completed and just needs to be reviewed and merged.
I'm not sure that this integration is a requirement for CR1, only that we
look into it like we have done. The actual work might be for a later
release perhaps.
measure how hard would it be to add PicketLink support.
I was thinking that AeroGear Security could be used as sort of a front-end
security layer when used with AeroGear Controller. If the target Camel
"service" uses Spring Security or Apache Shiro that would have to be
configured in the Controller class. So the two would be decoupled from each
other.
I might be missing something here and need to look into it more
carefully...more thinking out loud at the moment :)
cheers,
/Dan
On 2 January 2013 15:02, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Hi Dan, Camel support on controller is a good idea, on the other hand
we
must keep AG controller simple as is to cover of our developers' case with
simple needs, I guess. Would be nice to have Camel support as an additional
plugin on AG Controller to our enterprise scenarios, but now would be
important to finish our pagination support on Controller, at least for CR1.
Maybe file a JIRA or add it to our AG Controller roadmap? On security,
Camel will only support Spring and Apache Shiro, we need to measure how
hard would it be to add PicketLink support.
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, January 2, 2013 at 11:41 AM, Daniel Bevenius wrote:
> Hey Matthias,
>
> there has been a discussion about having something like what you
describe for this.
> At the moment there is not much to it, and if I was going to do this
sort of integration I think I'd use the Camel/SwitchYard APIs directly, but
having this as a reference or as a starting point would certainly help.
With the examples in the post hopefully we can decide if we should provide
an implementation, or if we should just have this more as a guide.
>
> cheers,
>
> /Dan
>
>
>
> On 2 January 2013 14:27, Matthias Wessendorf <matzew(a)apache.org (mailto:
matzew(a)apache.org)> wrote:
> > 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 (mailto:daniel.bevenius@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+Bindings).
> > >
> > >
> > > 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+Invoker) 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/apidocs/org/apache/camel...)
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 (mailto:aerogear-dev@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 (mailto:aerogear-dev@lists.jboss.org)
> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev