[teiid-dev] Modeling SOAP services

[Steven Hawkins]

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?

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

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

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

----- Original Message -----
From: "John Doyle" <jdoyle at redhat.com>
To: "teiid-dev" <teiid-dev at 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 at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev