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

[John Doyle]

Nevermind, that's a terrible idea.

----- "John Doyle" <jdoyle at redhat.com> wrote:

> ----- "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