New SqlQueryWebService SVN Repository Location
by Ted Jones
In Teiid 6.2, the SqlQueryWebService was removed from the Teiid project. In an effort to continue to provide such a web service capability to current customers that are using it 5.5.*, we have placed the source code in the following repo location: http://anonsvn.jboss.org/repos/teiid/sqlquerywebservice
NOTE: This code has been modified from the 6.1 branch (the last release of Teiid it was included in) to remove references to mmx. It still needs some work to be compatible with Teiid 7.0.
Please let me know if you have any questions.
Thanks,
Ted
15 years, 3 months
Re: [teiid-dev] what should a translator-ws look like?
by Steven Hawkins
It would be good to have a map, but we have no such construct in calling a stored procedure. The best you can do is have default values for parameters and used the named parameter calling syntax. In a system function we could have whatever syntax we want, but then we have the problem of how to encapsulate the connection information (base url, username/password, ws-security, etc.).
The request document is always put together by the user (which may be assisted by tooling). Only in the case of http are we trying to force fit the query string to be a document. For SOAP you would just provide the message body. The proposed document for http is probably too restrictive since the parameters names would need to be valid element names.
The other considerations are really along the lines of offering better/explicit syntax that would be especially suited for rest -
clob http('url', 'path' [, querystring(expr [as name], ...)] [header(expr [as name], ...)] [GET|(POST [expr])|...])
but you still like to have username/password, url, and even details of https handling (which is not even currently handled in the ws resource adapter) encapsulated outside of the vdb so that it could change per environment.
As a side note, I'm not sure what the previous use-case was, but allowing the user to pass in the endpoint address seems like a leaky abstraction.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Tuesday, June 8, 2010 7:57:57 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] what should a translator-ws look like?
This is similar approach you have taken with the File translator, so
looks good.
I would rather like to see generic map kind of parameter with known keys
for the "endpoint" and "soapaction", that we way if there are any other
headers we need to add then it will stay the same.
In this new calling semantics, who is putting together the request (for
soap) document? The engine? or the user's transformation? I am little
confused about flow of things from before. If requests always came in
the form <params><param_name>.. and translator converted them to soap or
http requests, then it makes sense to me.
I do not think I follow your comments in other considerations. Can you
give some examples.
Thanks
Ramesh..
On Mon, 2010-06-07 at 16:15 -0400, Steven Hawkins wrote:
> Hello all,
>
> Based upon the features of the translator-xml, we need a comparable translator-ws that has a job of simply invoking a service and returning a document (which can then be processed with xmltable or any other mechanism). I was thinking of exposing the procedure:
>
> XML invoke(XML request, String endpoint, String soapaction) - both endpoint and soapaction default to null and the result is available as the return parameter.
>
> With the HTTP mode:
>
> -with parameter invocation the request document is expected to be in the format <params><para_name>value</para_name><param_name1>...</params>. The simplest way to form such a doc is with xmlforest - xmlelement(params, xmlforest(value as param_name, value1 as param_name1 ...))
>
> -Path info will be taken from endpoint if it's specified and will be expected to be a relative path.
>
> -soapaction would not be used.
>
> Basic usage would then be:
>
> call ws-model.invoke(request = value)
>
> Other considerations:
>
> We may also want to add system function(s) with nearly the same approach to allow for ad hoc, non-JCA based service calls.
> We may want to add more explicit calling functionality for http to support rest.
>
> Steve
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
15 years, 3 months
Re: [teiid-dev] what should a translator-ws look like?
by John Doyle
I agree with Ramesh's suggestion about the map type parameter. There seems to be no end to the tweaks needed for the SOAP services people deploy, and this seems like a strategy to begin with.
~jd
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> This is similar approach you have taken with the File translator, so
> looks good.
>
> I would rather like to see generic map kind of parameter with known
> keys
> for the "endpoint" and "soapaction", that we way if there are any
> other
> headers we need to add then it will stay the same.
>
> In this new calling semantics, who is putting together the request
> (for
> soap) document? The engine? or the user's transformation? I am little
> confused about flow of things from before. If requests always came in
> the form <params><param_name>.. and translator converted them to soap
> or
> http requests, then it makes sense to me.
>
> I do not think I follow your comments in other considerations. Can
> you
> give some examples.
>
> Thanks
>
> Ramesh..
>
> On Mon, 2010-06-07 at 16:15 -0400, Steven Hawkins wrote:
> > Hello all,
> >
> > Based upon the features of the translator-xml, we need a comparable
> translator-ws that has a job of simply invoking a service and
> returning a document (which can then be processed with xmltable or any
> other mechanism). I was thinking of exposing the procedure:
> >
> > XML invoke(XML request, String endpoint, String soapaction) - both
> endpoint and soapaction default to null and the result is available as
> the return parameter.
> >
> > With the HTTP mode:
> >
> > -with parameter invocation the request document is expected to be in
> the format
> <params><para_name>value</para_name><param_name1>...</params>. The
> simplest way to form such a doc is with xmlforest - xmlelement(params,
> xmlforest(value as param_name, value1 as param_name1 ...))
> >
> > -Path info will be taken from endpoint if it's specified and will be
> expected to be a relative path.
> >
> > -soapaction would not be used.
> >
> > Basic usage would then be:
> >
> > call ws-model.invoke(request = value)
> >
> > Other considerations:
> >
> > We may also want to add system function(s) with nearly the same
> approach to allow for ad hoc, non-JCA based service calls.
> > We may want to add more explicit calling functionality for http to
> support rest.
> >
> > Steve
> > _______________________________________________
> > teiid-dev mailing list
> > teiid-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/teiid-dev
>
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
15 years, 3 months
what should a translator-ws look like?
by Steven Hawkins
Hello all,
Based upon the features of the translator-xml, we need a comparable translator-ws that has a job of simply invoking a service and returning a document (which can then be processed with xmltable or any other mechanism). I was thinking of exposing the procedure:
XML invoke(XML request, String endpoint, String soapaction) - both endpoint and soapaction default to null and the result is available as the return parameter.
With the HTTP mode:
-with parameter invocation the request document is expected to be in the format <params><para_name>value</para_name><param_name1>...</params>. The simplest way to form such a doc is with xmlforest - xmlelement(params, xmlforest(value as param_name, value1 as param_name1 ...))
-Path info will be taken from endpoint if it's specified and will be expected to be a relative path.
-soapaction would not be used.
Basic usage would then be:
call ws-model.invoke(request = value)
Other considerations:
We may also want to add system function(s) with nearly the same approach to allow for ad hoc, non-JCA based service calls.
We may want to add more explicit calling functionality for http to support rest.
Steve
15 years, 3 months
