here it goes.... http://bazinga-unit.blogspot.de/2012/08/replacing-google-cloud-endpoints-... On Tue, Aug 14, 2012 at 8:30 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

Hey Marko, all, So this is indeed cool stuff! A few comments: As you say, it's AppEngine-specific. While it's true that the blogger Matthias pointed to is trying to replicate the server-side with Jersey, that's very much not baked, nor is that approach sanctioned by Google as yet. At the least we certainly want the AeroGear stuff to work on OpenShift. It also looks kind of Eclipse-specific. Not sure if they expose command line tools for doing the codegen/etc for use with other IDEs or maven builds - but hopefully they do. Eclipse-specificity isn't necessarily a huge problem but we definitely need to support other IDEs/workflows as well. ("right?" -- says the die-hard IntelliJ user :) ) All in all this seems to be rather a lot like what AeroGear (and Parse/Kinvey/Stackmob/etc) is trying to actually become, so perhaps it's more another competitor in the ecosystem as opposed to something we really want to use as foundation. That said, if there are useful pieces we can borrow, that'd be dandy - i.e. if we're really happy with their wire-level API and codegen tools then perhaps there'd be a way to leverage those things with a JBoss backend. Finally, their stuff isn't public yet, so it would seem somewhat challenging to hitch to their wagon in the near term even if we wanted to. Thoughts? Thanks, --Glen On 8/14/12 2:22 PM, Marko Strukelj wrote:

----- Original Message ----- There's a JBoss project called CapeDwarf Blue (https://github.com/capedwarf/capedwarf-blue) which implements a big portion of AppEngine runtime, and it runs on JBoss AS7. So if one wants to port an application from AppEngine to AS7 for example that's quite possible. That might also mean that you could use the same or almost the same Eclipse tools to generate client libs for example - once you have additional services that provide metadata info in the same format ... Although as far as I understood the generate those libs in the cloud via some service, so tooling just triggers generation and downloads the result. 'wire-level' API covers things like HTTP communication helpers, JSON marshalling, OAuth2 ... One layer higher are probably client libraries for basic REST services used to gather metadata about the deployed service endpoints, and on top of that is probably your service. Client native libraries are platform specific (js, java, objectivec). For basic HTTP/HTTPS communication you either use standard native library part of the platform i.e. HXR in browser, java.net or HTTPClient in java ... Or you use some even higher level library that provides a nicer API to these, or some extra functionality. Then there's JSON. Again the same story - either use something provided by the platform, or a popular alternative. Higher you go up this stack of libraries the more your higher layer library dictates by way of its dependencies what you'll have to use for your lower layer. So, what you need to do is decide where your stack begins. Where you will not use an existing library, but write your own and chose your own dependencies. The key thing I wanted to point out is the approach, not to replicate the solution in exact way (although at some point there may be good interoperabilty reasons to wanna do that). Rather let's do a mental simulation ... Let's say there's a REST service exposing some resources. You open a browser go to resource endpoint and get JSON response with a list of entities. You can do this from code - open a connection, do a GET /myresource ... set request headers, get back response which you parse in a tree of maps using JSON parser. No problem, you can connect to any rest point this way, and after you have connected to a few you start noticing a lot of plumbing code in your application. Also you start noticing a lot of typos that you make, that cause many iterations before you get things working smoothly. If you had some schema describing what you can expect in the result, you could use that to generate POJOs and code to automatically mashal / unmarshal these. You can also wrap the mechanics of HTTP calls away and after done with all that what you have is just a class representing a remote service with methods taking POJOS that wrap all the mechanics of the remote call and return deserialized POJOs back. I think that's where we're trying to get to.

On Wed, Aug 15, 2012 at 5:19 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: I have to say (I guess b/c of XDoclet and EJB 2.x :-)) I am not too much a fan of code generation dynamic binding, based on metadata (e.g. WADL) -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

My 2 cents, I was watching that video tonight, is a great approach, assuming that we'll only use app engine for it, already mentioned in this thread. So, we're discussing endpoints generation without app engine. We're assuming that our backend will be only Java right? So how could I do the same with torquebox and ruby? Can I generate client source code to ring endpoints on immutant? OpenShift doesn't run only Java, right? http://tb-aerogear.rhcloud.com/ <- aerogear + torquebox + ruby I would rather to go with well defined endpoints on the server side and build nice APIs to the client side, is just my opinion. -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Wednesday, August 15, 2012 at 12:41 PM, Marko Strukelj wrote: