Responses inline
----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
What is the physical model procedure CountryInfoService backed by?
The new WSConnection logic only supports the invoke procedure. Are
you wanting to add some additional handling?
Yes, I'm behaving badly here, going outside the API. It's backed by the WS
translator. The translator doesn't actually check what the procedure is called, so as
long as the right values go in the right params, it works. This is easily changed.
So you are promoting a fully layered approach where request, invoke,
and response have independent place holders. I like that all three
are there, but what I think Ramesh is getting at is that for simple
input documents you could just have a single procedure encapsulate all
three steps:
create virtual procedure
begin
select t.* from (EXEC getOperationXXXRequestXML(proc.input1,
proc.input2 ...)) as request, (EXEC invoke(request.result ...) as
response, (EXEC getOperationXXXResponseTableXXX(response.result) as
t)
end
Yes, I think we're all on the same page here thankfully. That was the main
thrush of my original question and I'm pleased we agree on this.
The advantage is that the user can then do something similar to the
old WS logic: select * from proc where proc.input1 = '1' and
proc.input2 = 'foo'
The downside, as John indicates, is that this only works when the
input document can be formed from simple scalars. It also means that
the response document is local to this execution. Without
considerations for caching if there are multiple tables to extract
from the response document you would want to use the same doc.
For example to use the same response doc for a parent/child
relationship: select p.* from (EXEC
getOperationXXXRequestXML(proc.input1, proc.input2 ...)) as request,
(EXEC invoke(request.result ...) as response, (EXEC
getOperationXXXResponseTable1(response.result) as p inner join
getOperationXXXResponseTable1(response.result) as c on p.id = c.pid)
Although it would be better from a performance perspective if that
join would be expressed as a single XMLTABLE instead...
There is a limit to the intelligence that's going to end up in the importer, and it
certainly very limited in the short term. I think blogging and example/documentation is
going to have to play a big role for this feature. Real world WSDLs are so varied and we
can't really know what the user wants to do. But as you demonstrate, the beauty of
the new language feature is that they can do what they want, and in a way that is more
comprehensible.
> XML using XMLTABLE and have access pattern on the all the scalar
input
Access patterns will also only work for non-lob inputs, which would be
a problem for XML typed inputs.
Thanks, I have been runnning into this.
Thanks for the feed back guys.
----- Original Message -----
From: "John Doyle" <jdoyle(a)redhat.com>
To: "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Monday, August 16, 2010 2:02:19 PM GMT -06:00 US/Canada Central
Subject: [teiid-dev] Modeling SOAP services
Moved from private thread to mailinglist:
Close, but in my model the user executes something more like this:
select t* from (EXEC getRequestXML(...)) as in, (EXEC execute(in) as
out, (EXEC getResponseValues(out) as t))
and in this case getResponseValues() is using XMLTABLE to create the
procedure result. I can also get a lot more complex if either the
request or response requires hierarchy with multiplicity, the it could
become:
select t* from (EXEC getParentRequest((EXEC getChildRequest(...) as
child), ...) as parent,....
In regards to using access patterns on the inputs, I would only use
them in the event that multiplicity is >= 1. Real world WSDLs are
pretty spotty in describing what's actually required for a service and
what's not.
~jd
----- "Ramesh Reddy" wrote:
> John,
>
> I am trying understand all this myself, as I am starting to write
the
> XMLTABLE blog. Yours is most advanced case in that!
>
> For some reason, this model of two procedures, that user need to
> execute
> is not sounding right to me. So, let me understand this correctly.
> User
> executes some thing like this right?
>
> select t* from (EXEC getRequestProcedure(...)) as in, (EXEC
> getResponse(in))
>
> Please correct me, if understanding is wrong.
>
> thinking out loud - why not create response table based on the
> response
> XML using XMLTABLE and have access pattern on the all the scalar
> input?
> The one issue I see is input and output elements not matching.
>
> Ramesh..
>
> On Mon, 2010-08-16 at 10:13 -0400, John Doyle wrote:
> > Hi guys,
> >
> > Last week I worked on changing the WSDL to source importer to
work
> with the new system functions. I've attached a model project that
> contains a model for one operation of a WSDL in order to show the
tact
> I've taken, and want to get some feedback from you. It's not
complete
> yet, I need to add namespaces to the SQL, inputs/output for child
> element XML, etc, but wanted to get feedback on the overall
concept.
> >
> > The importer will create one physical model for each endpoint
> defined in the WSLD, since each endpoint might need to be bound to
a
> different URL. I intended this physical model to used across the
> generated views.
> >
> > The importer then creates a schema to contain views for each
> operation. I added the schemas to the model because operations
often
> reuse the same type/element definitions across operations, but not
> necessarily with the same XPaths. Containing the views within
schema
> allow me to create multiple views for any type/element with
> encountering naming clashes.
> >
> > The views are created by parsing the declaration of the request
and
> response messages. A request message results in a procedure with
> scalar inputs that produces and XML result. A response message
> results in a procedure with XML in and scalar results. The
procedures
> are not yet accounting for child elements for messages with
hierarchy
> and multiplicity.
> >
> > Does this make sense, or did you have a different/better vision
for
> how a user would model around the new language features? As it
stands
> right now, I have been unable to create a procedure that executes a
> service with this structure. Could be my limited abilities with
SQL,
> or that I've missed some limitation around our use of the XML type.
> I've tried passing the requests to the physical procedure and
> responses from the physical procedure using nested selects, and
tried
> holding them in variables to pass them, without success. I
typically
> end up with a validation error because I'm using a clob as a
> criteria.
> >
> > I appreciate any and all feedback.
> >
> > ~jd
_______________________________________________
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