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

[John Doyle]

----- "Steven Hawkins" <shawkins at redhat.com> 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 at redhat.com>
> To: "Steven Hawkins" <shawkins at redhat.com>
> Cc: "teiid-dev" <teiid-dev at 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 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