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... 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(a)redhat.com&gt; To: "teiid-dev" <teiid-dev(a)lists.jboss.org&gt; 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: _______________________________________________ teiid-dev mailing list teiid-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-dev