From: Eric L. <eri...@gm...> - 2009-11-12 05:38:57
Attachments:
signature.asc
|
Hi all, I've just tried soap on yaws. It looks like there is only one soap related configuration: enable_soap, and have to use yaws_soap_srv:setup() to setup the handler in yaws interactive shell. Is this true? or how can I do to setup a soap server module via config file ? However, any suggestions will be appreciated. Thanks in advance. Eric |
From: Steve V. <vi...@ie...> - 2009-11-12 06:30:16
|
On Thu, Nov 12, 2009 at 12:38 AM, Eric Liang <eri...@gm...> wrote: > Hi all, > I've just tried soap on yaws. It looks like there is only one soap > related configuration: enable_soap, and have to use > yaws_soap_srv:setup() to setup the handler in yaws interactive shell. > > Is this true? or how can I do to setup a soap server module via config > file ? > You can submit a patch. :-) I could be wrong because I don't use any SOAP features of Yaws and don't ever intend to, but the current code looks like this: %% Setup a SOAP interface according to the config file. setup(_ConfigFile) -> tbd. All that's needed is to replace that tbd with whatever's required. :-) If I were you, I'd try to avoid SOAP if possible, not because of Yaws issues like the above, but because SOAP is generally just a fairly horrible way to use HTTP. --steve |
From: Eric L. <eri...@gm...> - 2009-11-12 07:43:23
Attachments:
signature.asc
|
Steve Vinoski wrote: > > > On Thu, Nov 12, 2009 at 12:38 AM, Eric Liang <eri...@gm... > <mailto:eri...@gm...>> wrote: > > Hi all, > I've just tried soap on yaws. It looks like there is only one soap > related configuration: enable_soap, and have to use > yaws_soap_srv:setup() to setup the handler in yaws interactive shell. > > Is this true? or how can I do to setup a soap server module via config > file ? > > > You can submit a patch. :-) I could be wrong because I don't use any > SOAP features of Yaws and don't ever intend to, but the current code > looks like this: > > %% Setup a SOAP interface according to the config file. > setup(_ConfigFile) -> > tbd. > > All that's needed is to replace that tbd with whatever's required. :-) Thanks Steve, see you again :) Actually, I'm considering submit a patch, well before that, I think more suggestions from the yaws gurus like you are necessary. I've seen this interface, but after implementing it, I still have to call the yaws_soap_srv:setup() in the yaws shell, if I understand yaws correctly. Well, my purpose is to setup the soap server automatically when yaws starting, that means add some supports to yaws config module. for example, add the following tag to the configfile: <soap_srv_mod> my_module = PATH_TO_WSDL_FILE <soap_srv_mod> This will lead yaws to call yaws_soap_srv:setup({my_module, handler}, "PATH_TO_WSDL_FILE"). As my_module will be a specified service, I prefer to add this configuration to SC. Are there anything more should be considered ? > > If I were you, I'd try to avoid SOAP if possible, not because of Yaws > issues like the above, but because SOAP is generally just a fairly > horrible way to use HTTP. > > --steve Well, I use soap because the guys I collaborate with possibly use some different languages and platforms, and soap is more convenient than thift( http://incubator.apache.org/thrift/ ). When I say convenient, that means it's less demand on technology. Do you have any more advices ? Thanks in advance. Eric |
From: Steve V. <vi...@ie...> - 2009-11-12 08:52:10
|
On Thu, Nov 12, 2009 at 2:42 AM, Eric Liang <eri...@gm...> wrote: > Steve Vinoski wrote: > > > > On Thu, Nov 12, 2009 at 12:38 AM, Eric Liang <eri...@gm...>wrote: > >> Hi all, >> I've just tried soap on yaws. It looks like there is only one soap >> related configuration: enable_soap, and have to use >> yaws_soap_srv:setup() to setup the handler in yaws interactive shell. >> >> Is this true? or how can I do to setup a soap server module via config >> file ? >> > > You can submit a patch. :-) I could be wrong because I don't use any SOAP > features of Yaws and don't ever intend to, but the current code looks like > this: > > %% Setup a SOAP interface according to the config file. > setup(_ConfigFile) -> > tbd. > > All that's needed is to replace that tbd with whatever's required. :-) > > Thanks Steve, see you again :) > > Actually, I'm considering submit a patch, well before that, I think more > suggestions from the yaws gurus like you are necessary. > > I've seen this interface, but after implementing it, I still have to call > the yaws_soap_srv:setup() in the yaws shell, if I understand yaws correctly. > Well, my purpose is to setup the soap server automatically when yaws > starting, that means add some supports to yaws config module. for example, > add the following tag to the configfile: > > <soap_srv_mod> > my_module = PATH_TO_WSDL_FILE > <soap_srv_mod> > > This will lead yaws to call yaws_soap_srv:setup({my_module, handler}, > "PATH_TO_WSDL_FILE"). As my_module will be a specified service, I prefer to > add this configuration to SC. > > Are there anything more should be considered ? > Sounds about right, but maybe Willem or Tobbe could chime in, since they originally wrote and integrated that code into Yaws. > If I were you, I'd try to avoid SOAP if possible, not because of Yaws > issues like the above, but because SOAP is generally just a fairly horrible > way to use HTTP. > > --steve > > Well, I use soap because the guys I collaborate with possibly use some > different languages and platforms, and soap is more convenient than thift( > http://incubator.apache.org/thrift/ ). When I say convenient, that means > it's less demand on technology. Do you have any more advices ? Thanks in > advance. > If SOAP is more convenient than Thrift, then Thrift surely must be doomed. Personally, I don't like either of them. Now, let me climb up on my SOAPbox... ;-) You're already using HTTP but are doing so by layering SOAP over it -- why? Why not just use HTTP? SOAP just adds complexity and pain. SOAP and WSDL were made primarily so that Java/C#/C++ folks could just stay within the confines in their respective languages and code-generate all their distribution and remote invocation support code, as if distribution can be hidden as an afterthought. I know this because I used to be the chief architect/engineer of a fairly prominent company who built tools and libraries to support all that stuff. Not only did I used to work on all that junk, I was even an inaugural member of the W3C Web Services Architecture Working Group back at the beginning of this decade, before I finally realized how pointless and unnecessary the whole approach really was and left it all behind. You might consider reading these: <http://www.infoq.com/articles/vinoski-erlang-rest> <http://steve.vinoski.net/pdf/IEEE-Serendipitous_Reuse.pdf> <http://steve.vinoski.net/pdf/IEEE-Demystifying_RESTful_Data_Coupling.pdf> and perhaps some of the other REST-focused columns under: <http://steve.vinoski.net/blog/internet-computing-columns/> but if you do that you also really have to read these to fully understand it all: <http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm> <http://oreilly.com/catalog/9780596529260> One of my colleagues recently got stuck with the task of integrating our system with another vendor's, and he had no choice but to use SOAP. I unfortunately got dragged into it too, and man it was ugly. It took much longer than it should have, and the result is horribly brittle and hard to understand. He used Python, which is a nice language, so that was the only good part about the whole effort. The rest of it was enough to bring back nightmares. :-( --steve |
From: Eric L. <eri...@gm...> - 2009-11-12 11:09:54
Attachments:
signature.asc
|
Steve Vinoski wrote: > > > On Thu, Nov 12, 2009 at 2:42 AM, Eric Liang <eri...@gm... > <mailto:eri...@gm...>> wrote: > > Steve Vinoski wrote: >> >> >> On Thu, Nov 12, 2009 at 12:38 AM, Eric Liang >> <eri...@gm... <mailto:eri...@gm...>> wrote: >> >> Hi all, >> I've just tried soap on yaws. It looks like there is only one >> soap >> related configuration: enable_soap, and have to use >> yaws_soap_srv:setup() to setup the handler in yaws >> interactive shell. >> >> Is this true? or how can I do to setup a soap server module >> via config >> file ? >> >> >> You can submit a patch. :-) I could be wrong because I don't use >> any SOAP features of Yaws and don't ever intend to, but the >> current code looks like this: >> >> %% Setup a SOAP interface according to the config file. >> setup(_ConfigFile) -> >> tbd. >> >> All that's needed is to replace that tbd with whatever's >> required. :-) > Thanks Steve, see you again :) > > Actually, I'm considering submit a patch, well before that, I > think more suggestions from the yaws gurus like you are necessary. > > I've seen this interface, but after implementing it, I still have > to call the yaws_soap_srv:setup() in the yaws shell, if I > understand yaws correctly. Well, my purpose is to setup the soap > server automatically when yaws starting, that means add some > supports to yaws config module. for example, add the following tag > to the configfile: > > <soap_srv_mod> > my_module = PATH_TO_WSDL_FILE > <soap_srv_mod> > > This will lead yaws to call yaws_soap_srv:setup({my_module, > handler}, "PATH_TO_WSDL_FILE"). As my_module will be a specified > service, I prefer to add this configuration to SC. > > Are there anything more should be considered ? > > > Sounds about right, but maybe Willem or Tobbe could chime in, since > they originally wrote and integrated that code into Yaws. > OK. However, I'll do that first. >> If I were you, I'd try to avoid SOAP if possible, not because of >> Yaws issues like the above, but because SOAP is generally just a >> fairly horrible way to use HTTP. >> >> --steve > Well, I use soap because the guys I collaborate with possibly use > some different languages and platforms, and soap is more > convenient than thift( http://incubator.apache.org/thrift/ ). When > I say convenient, that means it's less demand on technology. Do > you have any more advices ? Thanks in advance. > > > If SOAP is more convenient than Thrift, then Thrift surely must be > doomed. Personally, I don't like either of them. > > Now, let me climb up on my SOAPbox... ;-) > > You're already using HTTP but are doing so by layering SOAP over it -- > why? Why not just use HTTP? SOAP just adds complexity and pain. SOAP > and WSDL were made primarily so that Java/C#/C++ folks could just stay > within the confines in their respective languages and code-generate > all their distribution and remote invocation support code, as if > distribution can be hidden as an afterthought. I know this because I > used to be the chief architect/engineer of a fairly prominent company > who built tools and libraries to support all that stuff. Not only did > I used to work on all that junk, I was even an inaugural member of the > W3C Web Services Architecture Working Group back at the beginning of > this decade, before I finally realized how pointless and unnecessary > the whole approach really was and left it all behind. > > You might consider reading these: > > <http://www.infoq.com/articles/vinoski-erlang-rest> > > <http://steve.vinoski.net/pdf/IEEE-Serendipitous_Reuse.pdf> > > <http://steve.vinoski.net/pdf/IEEE-Demystifying_RESTful_Data_Coupling.pdf> > > and perhaps some of the other REST-focused columns under: > > <http://steve.vinoski.net/blog/internet-computing-columns/> > > but if you do that you also really have to read these to fully > understand it all: > > <http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm > <http://www.ics.uci.edu/%7Efielding/pubs/dissertation/top.htm>> > > <http://oreilly.com/catalog/9780596529260> Thanks a lot for your kindness. I've read your blog article mentioned before :), and I'll read the rest later. > > One of my colleagues recently got stuck with the task of integrating > our system with another vendor's, and he had no choice but to use > SOAP. I unfortunately got dragged into it too, and man it was ugly. It > took much longer than it should have, and the result is horribly > brittle and hard to understand. He used Python, which is a nice > language, so that was the only good part about the whole effort. The > rest of it was enough to bring back nightmares. :-( > > --steve Then it looks like we get bogged down in the same mud :P Eric |