Re: [teiid-dev] what should a translator-ws look like?

----- "Steven Hawkins" <shawkins(a)redhat.com&gt; wrote: > 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. I wonder it it wouldn't be better to require the user to envelope the SOAP message? This would enable us to provide the WS-* headers as other system or UDF functions that could put the appropriate values in the document. > > 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. > This was done to allow access to REST like sites that served up the same XML at different URLs ( ../Employees/1.xml && ../Employees/2.xml) > ----- Original Message ----- > From: "Ramesh Reddy" <rareddy(a)redhat.com&gt; > To: "Steven Hawkins" <shawkins(a)redhat.com&gt; > Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org&gt; > 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 > > > _______________________________________________ > teiid-dev mailing list > teiid-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/teiid-dev