[teiid-designer-dev] [teiid-dev] REST Interface to TEIID

Ted Jones tejones at redhat.com
Wed May 4 09:07:56 EDT 2011 

What I have prototyped is a REST war using RESTEasy that exposes procedures for a Teiid relational view. It consumes and produces XML. If we want to go with that I just need the GUI component in place to generate the war. I should be able to have that for 7.4.

----- Original Message -----
From: "Steven Hawkins" <shawkins at redhat.com>
To: rareddy at redhat.com
Cc: "Ted Jones" <tejones at redhat.com>, "teiid-designer-dev" <teiid-designer-dev at lists.jboss.org>, "teiid-dev" <teiid-dev at lists.jboss.org>, "Randall Hauch" <rhauch at redhat.com>
Sent: Tuesday, May 3, 2011 8:46:44 PM
Subject: Re: [teiid-dev] REST Interface to TEIID

I think we may be going at this the wrong way.  What I'm mostly interested in is what we're doing for 7.4.  I had been given the impression by Ted that he had some basic mechanics in place for rest enablement of procedures, but I'm a little short on details.  My suggestions were built upon that assumption.  So my question for Ted is, what has been done and what in his estimation is doable in a short time frame out of the options discussed thus far.

----- Original Message -----
> For quick win, I would take current Web service model, and expose them
> as REST. Since these procedures already expose XML, that should be it.

What you are suggesting here would primarily remove soap enveloping.

> Exposing as JSON data should be done through some XML JSON converter
> based on some URL flag. 

Given an existing mapping approach, such as our jsonToXml function (which is based upon the logic from json.org) that conversion is straight-forward.  The webservices model however does not really buy you anything here other than ensuring that the procedure results are xml (there is a little bit of messiness though in that web service operation procedures return result sets that could in theory return multiple documents).  Any procedure that returns xml is just as valid of a starting point - and doesn't have to drag in any notion of xml document models. 

> I would even consider adding this on to the
> existing SOAP WAR generation stuff as an addon. 

Maybe Ted can comment on how what he has will be generated/delivered.

> I do not see any need
> for us to use any REST frameworks for this either. Just come up with
> simple schema included REST like URL and intercept and convert to same
> execution object the SOAP stuff is doing.
> 
> Going after generic model with extension metadata not valuable at this
> point IMO. Once we put the data binding on it, someone will say they
> want it based on schema then goes back to the web service model
> anyway.

Lets be clear on separating our concerns.  As I see it there is primarily: 
-rest protocol behavior - verb/uri/query string binding to sql
-a data binding for results/parameters/payload

To sum up.  We just need to be aware that if we dictate the terms of the protocol behavior, then we're asking people to target new development against our rest solution.  While I'm not saying that we can't do something novel in this regard, I just having a hard time separating out what's being proposed in the near term.  I also want to make sure that we're not reusing web services models for the wrong reason.

As for data binding, I similarly don't want us dependent upon xml document models.  There are plenty of other ways of generating xml through Teiid (sql/xml, xquery, direct from sources, etc.).  We can also add a general purpose inverse to jsonToXml regardless of the rest efforts.  

> 
> Ramesh..
> 
> On Tue, 2011-05-03 at 13:41 -0400, Steven Hawkins wrote:
> > ----- Original Message -----
> > > What is the legacy support for Restful service we are talking
> > > about? I
> > > thought MMX not Teiid never exposed data through REST before. Am I
> > > missing something here?
> > >
> >
> > By legacy I mean someone has an existing RESTful service not
> > implemented through EDS, but wants to do it through EDS - the common
> > virtualization use case.
> >
> > > Second, trying to mimic and come up with our own htsql like
> > > functionality is lot of work (it took them 6 years). We need to
> > > see if
> > > we can re-use their framework or something similar framework and
> > > integrate with Teiid. HTSQL have port for Postgres, unfortunately
> > > their
> > > implementation is all Python based, we need to bridge the gaps to
> > > deploy
> > > into JBoss. This would be very nice long term goal.
> > >
> >
> > Sure, a long term goal would be to provide some general restful
> > interface to relational that can include all sorts of novel querying
> > capabilities. Whether someone else has a license friendly way of
> > doing that or we develop it ourselves is an open question. My
> > concern however is still around the next EDS feature release. There
> > are all sorts of things we could do, but we have a rather short
> > window to hit that release.
> >
> > > I agree with you that we are not going to implement query like
> > > semantics
> > > the procedure approach is quick hitter, however I am opposed to
> > > the
> > > idea
> > > of creating a new REST-model in the Designer for this (That is
> > > what I
> > > understood is required).
> >
> > No I am not in favor of introducing a rest meta-model. I would
> > either be in favor of starting off with just the assumed URI
> > /{catalog}/{schema}/{procedure} mapping (it would still be open what
> > the data binding would be), or using the pending generic extension
> > metadata feature to set properties (similar to resteasy annotations)
> > on the procedure/params/results as to what their restful mapping
> > should be.
> >
> > > We should probably just work on enabling the
> > > current Web service models through Rest, instead of SOAP
> > > interface. In
> > > this scenario only issue really is how to covert the XML into JSON
> > > or
> > > alike. This will take us to same expectations as with SOAP. May be
> > > this
> > > what you are saying?
> >
> > Since the web services model at it's core is just a set of
> > procedures the only difference with any other procedure is that the
> > output is known to be xml.
> >
> > >
> > >
> > > Ramesh..
> > >
> > > On Tue, 2011-05-03 at 11:25 -0400, Steven Hawkins wrote:
> > > > Just to be clear, what I am getting at is that I would rather
> > > > see us
> > > > focus in the near term on a narrowly scoped enablement of
> > > > RESTFul
> > > > services for EDS. The more we attempt to invent or define a lot
> > > > of
> > > > new query semantics (like ht:sql) the more we are pushing out
> > > > implementation and ensuring that the usage is only for new
> > > > development.
> > > >
> > > > ----- Original Message -----
> > > > > ----- Original Message -----
> > > > > > Steve,
> > > > > >
> > > > > > Yes... delete /{catalog}/{schema}/{table}?column1=value
> > > > > > becomes
> > > > > > "DELETE FROM catalog.schema.table WHERE column1=value"
> > > > > >
> > > > > > Also, by allowing procedures to be exposed RESTFully as
> > > > > > well, we
> > > > > > can
> > > > > > handle more complex processing.
> > > > > >
> > > > > > With regards to:
> > > > > >
> > > > > > -update change sets: Are you asking how will updates be
> > > > > > handled?
> > > > > > I
> > > > > > am
> > > > > > thinking for the input we will expect JSON only and build
> > > > > > our
> > > > > > SQL
> > > > > > accordingly. Not sure if that's what you meant though. :-)
> > > > >
> > > > > The question is how will the change set be sent. Your
> > > > > indicating
> > > > > as
> > > > > JSON, i.e. {column1:value}. Does that also imply only literal
> > > > > values,
> > > > > or would you also support expressions?
> > > > >
> > > > > > -null values: We can candle null values via the JSON
> > > > > > provider
> > > > >
> > > > > Can you provide an example for a GET predicate?
> > > > >
> > > > > > (RESTEasy support Jackson).
> > > > > > -non-equality predicates: This could be handled in a
> > > > > > procedure
> > > > > > -output mapping: We would support JSON only
> > > > > >
> > > > > > By legacy restful services, do you mean our current rest
> > > > > > support? I
> > > > > > don't see that changing.
> > > > >
> > > > > No I mean what we seem to be doing here is a very open ended
> > > > > design of
> > > > > a completely new project (see also Ramesh's suggestion of
> > > > > ht:sql
> > > > > or
> > > > > the servlet based project that you were referencing). That is
> > > > > well
> > > > > and
> > > > > good for new development, but the primary use case for
> > > > > EII/virtualization is providing the ability to easily match
> > > > > existing
> > > > > interfaces. If someone already has a RESTful dataservice
> > > > > defined
> > > > > and
> > > > > wants to have EDS handle it, what is the recommended approach?
> > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Steven Hawkins" <shawkins at redhat.com>
> > > > > > To: "Ted Jones" <tejones at redhat.com>
> > > > > > Cc: "Randall Hauch" <rhauch at redhat.com>, "teiid-dev"
> > > > > > <teiid-dev at lists.jboss.org>, "teiid-designer-dev"
> > > > > > <teiid-designer-dev at lists.jboss.org>
> > > > > > Sent: Monday, May 2, 2011 4:18:13 PM
> > > > > > Subject: Re: [teiid-dev] REST Interface to TEIID
> > > > > >
> > > > > > Can you provide more detail about the verb to SQL mapping?
> > > > > >
> > > > > > I'm assuming something like:
> > > > > >
> > > > > > delete /{catalog}/{schema}/{table}?column1=value
> > > > > >
> > > > > > becomes "DELETE FROM catalog.schema.table WHERE
> > > > > > column1=value"
> > > > > >
> > > > > > Can you confirm and provide more detail on the handling of
> > > > > > things
> > > > > > like:
> > > > > > -update change sets
> > > > > > -null values (in both predicates and in insert/update
> > > > > > changes)
> > > > > > -non-equality predicates
> > > > > > -output mapping (are we binding to xml and in what format,
> > > > > > or
> > > > > > json,
> > > > > > etc.)
> > > > > >
> > > > > > Also I'm assuming that this approach is only for new
> > > > > > development.
> > > > > > What
> > > > > > about matching the expected behavior of legacy restful
> > > > > > services?
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > > We have been wrestling with the best way to implement a
> > > > > > > RESTFul
> > > > > > > interface to a VDB. Here are the options we have come up
> > > > > > > with
> > > > > > > to
> > > > > > > date:
> > > > > > >
> > > > > > > 1. Create a hook to procedures to allow a mapping from
> > > > > > > HTTP
> > > > > > > verbs
> > > > > > > to
> > > > > > > procedures in a model within a VDB. This war would be
> > > > > > > generated
> > > > > > > from
> > > > > > > Designer and there would be one war per VDB.
> > > > > > >
> > > > > > > Example... if I have a procedure name rgetBooks() the
> > > > > > > procedure
> > > > > > > would
> > > > > > > map to a GET at URI=/books and would return all books
> > > > > > > (assuming
> > > > > > > that
> > > > > > > the procedure was written correctly)
> > > > > > >
> > > > > > > 2. Create a single war that would have pre-defined URIs
> > > > > > > for
> > > > > > > table
> > > > > > > access for any JDBC connection. Multiple connections could
> > > > > > > be
> > > > > > > supported within the same war based on the URI. The JNDI
> > > > > > > names
> > > > > > > would
> > > > > > > be entered by the user in a properties file or some
> > > > > > > analogous
> > > > > > > mechanism.
> > > > > > >
> > > > > > > Example URI=/{dbschema}/{catalog}/{table}?column1=value
> > > > > > > would
> > > > > > > return
> > > > > > > the record corresponding to "value" in the target table
> > > > > > >
> > > > > > > Procedures could also be supported in this manner.
> > > > > > >
> > > > > > > 3. Another option would be to generate the war discussed
> > > > > > > in
> > > > > > > option
> > > > > > > 2
> > > > > > > from Designer to eliminate the need for the user to hand
> > > > > > > edit
> > > > > > > a
> > > > > > > properties file.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > There are pros and cons for all the options. 1 puts more
> > > > > > > onus
> > > > > > > on
> > > > > > > the
> > > > > > > user but 2/3 are definitely the more complicated solutions
> > > > > > > and
> > > > > > > they
> > > > > > > require intimate knowledge of the underlying metadata.
> > > > > > >
> > > > > > > Please respond with your feedback on these proposed
> > > > > > > solutions
> > > > > > > and
> > > > > > > feel
> > > > > > > free to add other alternatives.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Ted
> > > > > > > _______________________________________________
> > > > > > > teiid-dev mailing list
> > > > > > > teiid-dev at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/teiid-dev
> > > > _______________________________________________
> > > > teiid-dev mailing list
> > > > teiid-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/teiid-dev

More information about the teiid-designer-dev mailing list