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

[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 at 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 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