WSDL to XPL
Locked
 
|
I figured if there is some interest on something like this for OPS, it
is going to take some input, and a new thread started for intial documenting. We can move this off list after coming up with initial requirements or leave it on, whatever you think. I think the OPS integration with SOAP through XPL is very nice, but coding an entire webservice with XPL may prove time consuming if done by hand, especially a service with 40 or 50 methods. Since WDSL is XML and so is XPL it should be rather simple to some up with a XFORM + XSLT process to so this. Basically we would have a form that accepts the URL of the wsdl, an XPL pipeline would load the WSDL. This is where a decision would be have to be made 1. To have a seperate XPL file for each method (operation), or 2. Is there a way to combine the methods to a single xpl and have each seperably callable from the pageflow? Either way the WSDL would be read and transformed via XSLT to the appropriate XPL processors For each method a seperate <delegation:execute service="webservicename" operation="method" xsl:version="2.0"> stement would need to be created. The parameters would need to be transformed to xsi:type parameters within the <delegation>, but this should be trivial as I believe that is how the types are defined in the WSDL the inputs and outputs are standard. The/each xpl would need to serialized to an output location. anyone interested in undertaking an OS implementation to contribute to OPS, please post back on this thread. -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
|
|
Richard,
Le lundi 04 septembre 2006 à 14:11 -0400, Richard Braman a écrit : > I figured if there is some interest on something like this for OPS, it > is going to take some input, and a new thread started for intial > documenting. We can move this off list after coming up with initial > requirements or leave it on, whatever you think. I think the OPS > integration with SOAP through XPL is very nice, but coding an entire > webservice with XPL may prove time consuming if done by hand, especially > a service with 40 or 50 methods. Since WDSL is XML and so is XPL it > should be rather simple to some up with a XFORM + XSLT process to so > this. Basically we would have a form that accepts the URL of the wsdl, > an XPL pipeline would load the WSDL. > > This is where a decision would be have to be made > 1. To have a seperate XPL file for each method (operation), or > 2. Is there a way to combine the methods to a single xpl and have each > seperably callable from the pageflow? That includes not only XPL pipelines that can be generated dynamically but even the page flows. In other words, if you want to use OPS to generate a server, it would be fairly easy to generate not only the web services invocations but even to generate web services servers that are conform to their DSDL specifications. > Either way the WSDL would be read and transformed via XSLT to the > appropriate XPL processors > > For each method a seperate > <delegation:execute service="webservicename" operation="method" > xsl:version="2.0"> > stement would need to be created. > The parameters would need to be transformed to xsi:type parameters > within the <delegation>, but this should be trivial as I believe that is > how the types are defined in the WSDL > the inputs and outputs are standard. > > The/each xpl would need to serialized to an output location. > > anyone interested in undertaking an OS implementation to contribute to > OPS, please post back on this thread. Eric -- GPG-PGP: 2A528005 If you have a XML document, you have its schema. http://examplotron.org ------------------------------------------------------------------------ Eric van der Vlist http://xmlfr.org http://dyomedea.com (ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax (W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema ------------------------------------------------------------------------ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
signature.asc (198 bytes) |
|
Some form of sponsoring wouldn't hurt :) ...
It never hurts, but I dont know who would sponsor it..... Hopefully members of the list will think it will be valuable enough to contribute, as this seems like a good tool to have packaged with OPS. Orbeon gives us alot in their efforts, so it would be nice to contibute back to it, wouldn't it? If nothing else as a present to Alex for his wedding :) Besides, you said it was easy and trivial, it shouln't need any sponsorship :) ..... I did find your comments about making page flows and xpls dynamic i guess based on the wsdl, you could have it create views and models to consume the entire services and have each view accesible via its path. I dont know if thats what we need but certainly the easiest to use would be the best. Eric van der Vlist wrote: > Richard, > > Le lundi 04 septembre 2006 à 14:11 -0400, Richard Braman a écrit : > >> I figured if there is some interest on something like this for OPS, it >> is going to take some input, and a new thread started for intial >> documenting. We can move this off list after coming up with initial >> requirements or leave it on, whatever you think. I think the OPS >> integration with SOAP through XPL is very nice, but coding an entire >> webservice with XPL may prove time consuming if done by hand, especially >> a service with 40 or 50 methods. Since WDSL is XML and so is XPL it >> should be rather simple to some up with a XFORM + XSLT process to so >> this. Basically we would have a form that accepts the URL of the wsdl, >> an XPL pipeline would load the WSDL. >> >> This is where a decision would be have to be made >> 1. To have a seperate XPL file for each method (operation), or >> 2. Is there a way to combine the methods to a single xpl and have each >> seperably callable from the pageflow? >> > > One of the nice things with OPS is that any resource can be dynamic. > > That includes not only XPL pipelines that can be generated dynamically > but even the page flows. In other words, if you want to use OPS to > generate a server, it would be fairly easy to generate not only the web > services invocations but even to generate web services servers that are > conform to their DSDL specifications. > > >> Either way the WSDL would be read and transformed via XSLT to the >> appropriate XPL processors >> >> For each method a seperate >> <delegation:execute service="webservicename" operation="method" >> xsl:version="2.0"> >> stement would need to be created. >> The parameters would need to be transformed to xsi:type parameters >> within the <delegation>, but this should be trivial as I believe that is >> how the types are defined in the WSDL >> the inputs and outputs are standard. >> >> The/each xpl would need to serialized to an output location. >> >> anyone interested in undertaking an OS implementation to contribute to >> OPS, please post back on this thread. >> > > Some form of sponsoring wouldn't hurt :) ... > > Eric > > > ------------------------------------------------------------------------ > > > -- > You receive this message as a subscriber of the [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws > -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
|
|
I have only very limited exposure to web services but every now and
again I run into a problem that looks like would benefit to be implemented using the WS "paradigm". I understand that there are WS providers (that you need a WSDL file for) and there are service consumers. All I have seen so far discussed on this list have been issues surrounding consumption of web services with OPS. Am I the only one who would like to implement a web service in OPS? As for sponsoring, I think the chances of people volunteering their money for this would grow if there was a clearer description of the value proposition explained in little more detail. So what you are proposing about initial documentation of the intent is a good idea. I would be happy to help in this effort somehow. A. On Sep 5, 2006, at 12:25 AM, Richard Braman wrote: > Some form of sponsoring wouldn't hurt :) ... > > It never hurts, but I dont know who would sponsor it..... Hopefully > members of the list will think it will be valuable enough to > contribute, > as this seems like a good tool to have packaged with OPS. Orbeon > gives > us alot in their efforts, so it would be nice to contibute back to it, > wouldn't it? If nothing else as a present to Alex for his wedding :) > Besides, you said it was easy and trivial, it shouln't need any > sponsorship :) ..... > > I did find your comments about making page flows and xpls dynamic > i guess based on the wsdl, you could have it create views and > models to > consume the entire services and have each view accesible via its path. > I dont know if thats what we need but certainly the easiest to use > would > be the best. > > Eric van der Vlist wrote: >> Richard, >> >> Le lundi 04 septembre 2006 à 14:11 -0400, Richard Braman a écrit : >> >>> I figured if there is some interest on something like this for >>> OPS, it >>> is going to take some input, and a new thread started for intial >>> documenting. We can move this off list after coming up with initial >>> requirements or leave it on, whatever you think. I think the OPS >>> integration with SOAP through XPL is very nice, but coding an entire >>> webservice with XPL may prove time consuming if done by hand, >>> especially >>> a service with 40 or 50 methods. Since WDSL is XML and so is XPL it >>> should be rather simple to some up with a XFORM + XSLT process to so >>> this. Basically we would have a form that accepts the URL of >>> the wsdl, >>> an XPL pipeline would load the WSDL. >>> >>> This is where a decision would be have to be made >>> 1. To have a seperate XPL file for each method (operation), or >>> 2. Is there a way to combine the methods to a single xpl and have >>> each >>> seperably callable from the pageflow? >>> >> >> One of the nice things with OPS is that any resource can be dynamic. >> >> That includes not only XPL pipelines that can be generated >> dynamically >> but even the page flows. In other words, if you want to use OPS to >> generate a server, it would be fairly easy to generate not only >> the web >> services invocations but even to generate web services servers >> that are >> conform to their DSDL specifications. >> >> >>> Either way the WSDL would be read and transformed via XSLT to the >>> appropriate XPL processors >>> >>> For each method a seperate >>> <delegation:execute service="webservicename" operation="method" >>> xsl:version="2.0"> >>> stement would need to be created. >>> The parameters would need to be transformed to xsi:type parameters >>> within the <delegation>, but this should be trivial as I believe >>> that is >>> how the types are defined in the WSDL >>> the inputs and outputs are standard. >>> >>> The/each xpl would need to serialized to an output location. >>> >>> anyone interested in undertaking an OS implementation to >>> contribute to >>> OPS, please post back on this thread. >>> >> >> Some form of sponsoring wouldn't hurt :) ... >> >> Eric >> >> >> --------------------------------------------------------------------- >> --- >> >> >> -- >> You receive this message as a subscriber of the ops- >> [hidden email] mailing list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> ObjectWeb mailing lists service home page: http:// >> www.objectweb.org/wws >> > > > > > -- > You receive this message as a subscriber of the ops- > [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/ > wws -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
|
|
I am going start a new topic for Alex Zatkos comments on creating tools that
automatically expose web services via OPS. I think that a stylesheet could probably be used to create a WSDL based on XPL. I think there is much value to this as well. If we put our heads together these tools can come very fast. -----Original Message----- From: Alexander Zatko [mailto:[hidden email]] Sent: Tuesday, September 05, 2006 9:41 AM To: [hidden email] Subject: Re: [ops-users] WSDL to XPL I have only very limited exposure to web services but every now and again I run into a problem that looks like would benefit to be implemented using the WS "paradigm". I understand that there are WS providers (that you need a WSDL file for) and there are service consumers. All I have seen so far discussed on this list have been issues surrounding consumption of web services with OPS. Am I the only one who would like to implement a web service in OPS? As for sponsoring, I think the chances of people volunteering their money for this would grow if there was a clearer description of the value proposition explained in little more detail. So what you are proposing about initial documentation of the intent is a good idea. I would be happy to help in this effort somehow. A. On Sep 5, 2006, at 12:25 AM, Richard Braman wrote: > Some form of sponsoring wouldn't hurt :) ... > > It never hurts, but I dont know who would sponsor it..... Hopefully > members of the list will think it will be valuable enough to > contribute, > as this seems like a good tool to have packaged with OPS. Orbeon > gives > us alot in their efforts, so it would be nice to contibute back to it, > wouldn't it? If nothing else as a present to Alex for his wedding :) > Besides, you said it was easy and trivial, it shouln't need any > sponsorship :) ..... > > I did find your comments about making page flows and xpls dynamic > i guess based on the wsdl, you could have it create views and > models to > consume the entire services and have each view accesible via its path. > I dont know if thats what we need but certainly the easiest to use > would > be the best. > > Eric van der Vlist wrote: >> Richard, >> >> Le lundi 04 septembre 2006 à 14:11 -0400, Richard Braman a écrit : >> >>> I figured if there is some interest on something like this for >>> OPS, it >>> is going to take some input, and a new thread started for intial >>> documenting. We can move this off list after coming up with initial >>> requirements or leave it on, whatever you think. I think the OPS >>> integration with SOAP through XPL is very nice, but coding an entire >>> webservice with XPL may prove time consuming if done by hand, >>> especially >>> a service with 40 or 50 methods. Since WDSL is XML and so is XPL it >>> should be rather simple to some up with a XFORM + XSLT process to so >>> this. Basically we would have a form that accepts the URL of >>> the wsdl, >>> an XPL pipeline would load the WSDL. >>> >>> This is where a decision would be have to be made >>> 1. To have a seperate XPL file for each method (operation), or >>> 2. Is there a way to combine the methods to a single xpl and have >>> each >>> seperably callable from the pageflow? >>> >> >> One of the nice things with OPS is that any resource can be dynamic. >> >> That includes not only XPL pipelines that can be generated >> dynamically >> but even the page flows. In other words, if you want to use OPS to >> generate a server, it would be fairly easy to generate not only >> the web >> services invocations but even to generate web services servers >> that are >> conform to their DSDL specifications. >> >> >>> Either way the WSDL would be read and transformed via XSLT to the >>> appropriate XPL processors >>> >>> For each method a seperate >>> <delegation:execute service="webservicename" operation="method" >>> xsl:version="2.0"> >>> stement would need to be created. >>> The parameters would need to be transformed to xsi:type parameters >>> within the <delegation>, but this should be trivial as I believe >>> that is >>> how the types are defined in the WSDL >>> the inputs and outputs are standard. >>> >>> The/each xpl would need to serialized to an output location. >>> >>> anyone interested in undertaking an OS implementation to >>> contribute to >>> OPS, please post back on this thread. >>> >> >> Some form of sponsoring wouldn't hurt :) ... >> >> Eric >> >> >> --------------------------------------------------------------------- >> --- >> >> >> -- >> You receive this message as a subscriber of the ops- >> [hidden email] mailing list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> ObjectWeb mailing lists service home page: http:// >> www.objectweb.org/wws >> > > > > > -- > You receive this message as a subscriber of the ops- > [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/ > wws -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
|
|
In reply to this post by Alexander Žaťko
Hi,
I implemented web services in one of my apps using OPS over a year ago and they work very nicely: it's relatively simple to do and you have absolute control over the SOAP messages (which is as it should be) without any of the obfuscation that Axis, etc. introduce. Cheers, Matthew Alexander Zatko wrote: > I have only very limited exposure to web services but every now and > again I run into a problem that looks like would benefit to be > implemented using the WS "paradigm". I understand that there are WS > providers (that you need a WSDL file for) and there are service > consumers. All I have seen so far discussed on this list have been > issues surrounding consumption of web services with OPS. Am I the only > one who would like to implement a web service in OPS? > > As for sponsoring, I think the chances of people volunteering their > money for this would grow if there was a clearer description of the > value proposition explained in little more detail. So what you are > proposing about initial documentation of the intent is a good idea. I > would be happy to help in this effort somehow. > > A. > > On Sep 5, 2006, at 12:25 AM, Richard Braman wrote: > >> Some form of sponsoring wouldn't hurt :) ... >> >> It never hurts, but I dont know who would sponsor it..... Hopefully >> members of the list will think it will be valuable enough to contribute, >> as this seems like a good tool to have packaged with OPS. Orbeon gives >> us alot in their efforts, so it would be nice to contibute back to it, >> wouldn't it? If nothing else as a present to Alex for his wedding :) >> Besides, you said it was easy and trivial, it shouln't need any >> sponsorship :) ..... >> >> I did find your comments about making page flows and xpls dynamic >> i guess based on the wsdl, you could have it create views and models to >> consume the entire services and have each view accesible via its path. >> I dont know if thats what we need but certainly the easiest to use would >> be the best. >> >> Eric van der Vlist wrote: >>> Richard, >>> >>> Le lundi 04 septembre 2006 à 14:11 -0400, Richard Braman a écrit : >>> >>>> I figured if there is some interest on something like this for OPS, it >>>> is going to take some input, and a new thread started for intial >>>> documenting. We can move this off list after coming up with initial >>>> requirements or leave it on, whatever you think. I think the OPS >>>> integration with SOAP through XPL is very nice, but coding an entire >>>> webservice with XPL may prove time consuming if done by hand, >>>> especially >>>> a service with 40 or 50 methods. Since WDSL is XML and so is XPL it >>>> should be rather simple to some up with a XFORM + XSLT process to so >>>> this. Basically we would have a form that accepts the URL of the >>>> wsdl, >>>> an XPL pipeline would load the WSDL. >>>> >>>> This is where a decision would be have to be made >>>> 1. To have a seperate XPL file for each method (operation), or >>>> 2. Is there a way to combine the methods to a single xpl and have each >>>> seperably callable from the pageflow? >>>> >>> >>> One of the nice things with OPS is that any resource can be dynamic. >>> >>> That includes not only XPL pipelines that can be generated dynamically >>> but even the page flows. In other words, if you want to use OPS to >>> generate a server, it would be fairly easy to generate not only the web >>> services invocations but even to generate web services servers that are >>> conform to their DSDL specifications. >>> >>> >>>> Either way the WSDL would be read and transformed via XSLT to the >>>> appropriate XPL processors >>>> >>>> For each method a seperate >>>> <delegation:execute service="webservicename" operation="method" >>>> xsl:version="2.0"> >>>> stement would need to be created. >>>> The parameters would need to be transformed to xsi:type parameters >>>> within the <delegation>, but this should be trivial as I believe >>>> that is >>>> how the types are defined in the WSDL >>>> the inputs and outputs are standard. >>>> >>>> The/each xpl would need to serialized to an output location. >>>> >>>> anyone interested in undertaking an OS implementation to contribute to >>>> OPS, please post back on this thread. >>>> >>> >>> Some form of sponsoring wouldn't hurt :) ... >>> >>> Eric >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> -- >>> You receive this message as a subscriber of the >>> [hidden email] mailing list. >>> To unsubscribe: mailto:[hidden email] >>> For general help: mailto:[hidden email]?subject=help >>> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws >>> >> >> >> >> >> -- >> You receive this message as a subscriber of the >> [hidden email] mailing list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws > > > ------------------------------------------------------------------------ > > > -- > You receive this message as a subscriber of the [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws > -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
|
|
I think we should use a SOAP service that can be beneficial to any website as an example, so I will keep going with the google search api. Please provide comments. the google search api wsdl can be found here: http://api.google.com/GoogleSearch.wsdl I want to spend some words describing the mappings from WSDL to produce a XPL on the fly. The XPL would have to take the WSDL filename, the service name, and the operation method name as inputs, so it could execute the web service. The in parameters also would need to be passed to the XPL presumably from an Xform, the output parmeters shouldn't need to be defined, istead the result message is handled by the Form that called the method. 1. The <service> element in the wsdl names the the service and defines its endpoint as follows <service name="GoogleSearchService"> <port name="GoogleSearchPort" binding="typens:GoogleSearchBinding"> <<a class="moz-txt-link-freetext" href="soap:address">soap:address location="http://api.google.com/search/beta2"/> </port> </service> in XPL this translates to the following code: <p:processor name="oxf:delegation"> <p:input name="interface"> <config> <service id="GoogleSearchService" type="webservice" endpoint="http://api.google.com/search/beta2 "> <operation name="doGoogleSearch" nsuri="urn:GoogleSearch"/> </service> </config> </p:input> <p:input name="data"><dummy/></p:input> <p:input name="call" href="#call"/> <p:output name="data" ref="data"/> </p:processor> So firstly we need to be able to translate the XML from wha it is in the WSDL to what is in XPL. 2. The WSDL defines any number of <operation> elements as children of it <binding> element. these operation elements translate to the the methods that the service exposes. For the doGoogleSearch operation the WSDL looks like this <operation name="doGoogleSearch"> <<a class="moz-txt-link-freetext" href="soap:operation">soap:operation soapAction="urn:GoogleSearchAction"/> <input> <<a class="moz-txt-link-freetext" href="soap:body">soap:body use="encoded" namespace="urn:GoogleSearch" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <<a class="moz-txt-link-freetext" href="soap:body">soap:body use="encoded" namespace="urn:GoogleSearch" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation> Each operation has an message element that defines the parameters for the method in their types like this in theWSDL: <message name="doGoogleSearch"> <part name="key" type="xsd:string"/> <part name="q" type="xsd:string"/> <part name="start" type="xsd:int"/> <part name="maxResults" type="xsd:int"/> <part name="filter" type="xsd:boolean"/> <part name="restrict" type="xsd:string"/> <part name="safeSearch" type="xsd:boolean"/> <part name="lr" type="xsd:string"/> <part name="ie" type="xsd:string"/> <part name="oe" type="xsd:string"/> </message> For each operation, a XPL processor needs to be created. All of the information contained can be generated from the WSDL. This should also be relatively trivial to generate on the fly. <p:processor name="oxf:xslt"> <p:input name="data" href="#instance"/> <p:input name="config"> <delegation:execute service="GoogleSearchService" operation="doGoogleSearch" xsl:version="2.0"> <key xsi:type="xsd:string">XXXXXXXXXXX</key> <q xsi:type="xsd:string"><xsl:value-of select="/q"/></q> <start xsi:type="xsd:int"><xsl:value-of select="/start"/></start> <maxResults xsi:type="xsd:int"><xsl:value-of select="/maxResults"/></maxResults> <filter xsi:type="xsd:boolean"><xsl:value-of select="/filter"/></filter> <restrict xsi:type="xsd:string"><xsl:value-of select="/restrict"/></restrict> <safeSearch xsi:type="xsd:boolean"><xsl:value-of select="/safeSearch"/></safeSearch> <lr xsi:type="xsd:string"><xsl:value-of select="/lr"/></lr> <ie xsi:type="xsd:string"><xsl:value-of select="/le"/></ie> <oe xsi:type="xsd:string"><xsl:value-of select="/oe"/></oe> </delegation:execute> </p:input> <p:output name="data" id="call"/> </p:processor> Matthew Graham wrote: Hi, -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
«
Return to Orbeon Forms community mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |