[teiid-dev] Modeling SOAP services

[John Doyle]

Responses inline
----- "Steven Hawkins" <shawkins at 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 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
> _______________________________________________
> teiid-dev mailing list
> teiid-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev