I intend to have Merb support SOAP in a more integrated fashion in the future. It is a personal 2.0 goal, but has not yet been clearly added to the roadmap. A proof-of-concept plugin would certainly be welcome. Part of the problem is that while REST maps directly onto the concept of Merb, SOAP requires a bit more finagling to get both right and DRY.
-- Yehuda On Mon, Oct 20, 2008 at 1:14 AM, Ahsan Ali <[EMAIL PROTECTED]> wrote: > Hi, > > Speaking of libraries, http://wso2.org/projects/wsf/ruby /looks/ like a > pretty good alternative to SOAP4r. I haven't tried it myself though ... > > "WSO2 WSF/Ruby is a complete solution for building and deploying Web > services, and is the only Ruby extension with the widest range of WS-* > specification implementations. Key features include, secure services and > clients with WS-Security support, binary attachments with MTOM, works with > Ruby on Rails and interoperability with .NET and J2EE." > > Now I'm trying to recall why I chose soap4r - was it the facility to > generate ruby stubs/skeletons from a WSDL (wsdl2ruby) ? It looks like WSO2 > also has something similar in the works. > > Best Regards, > > Ahsan Ali > > > On Mon, Oct 20, 2008 at 11:58 AM, Erik Lindblad <[EMAIL PROTECTED]> wrote: > >> >> Hi >> >> My intention was to do both. Since I am designing Merb-based nodes in a >> SOA each node needs to be able to produce as well as consume SOAP >> messages. >> >> I read in the pickaxe that Action Web Service does not support >> document/literal SOAP messages, which is the de facto standard in the >> WS-I guidelines. I am not sure whether this is a restriction in AWS or >> in SOAP4R (or if AWS even uses SOAP4R). I guess a SOAP lib that is based >> on libxml-ruby would be preferable for performance reasons and XML >> Schema usage. >> >> I realize that maybe this specific question is more appropriate for a >> SOAP4R list or a general WS list, but I think the subject as a whole is >> a valid Merb issue. >> >> I love RESTful development and the lightweight approach to web services, >> but in a legacy environment SOAP cannot be ignored. And in an enterprise >> environment, things like standardized policy enforcement, intermediate >> nodes and so on really rely on SOAP-based techniques. There is a lot of >> talk these days on whether Merb and other Ruby frameworks (guess which >> one :-) are ready for enterprise adoption and, in my opinion, in many >> areas they are. But with the upcoming second generation web services >> (WS-Security, XML Encryption, WS-Policy and so on) the Ruby SOAP libs >> are lagging far behind. >> >> And again, this is not a Merb-specific issue, since Merb can use any lib >> you want. But for me, and I think for a few other people as well, it >> would be a lot easier to argue the use of Merb if there existed an >> active and up-to-date SOAP-lib that was mentioned in the Merb pages and >> supported in the same way as e.g. DataMapper. Managers rarely go for the >> "but you can use anything" argument :-) So if anyone have done some work >> with Merb/SOAP/SOA/WS-* I would be very happy to hear about your >> experiences of it. Or maybe running Merb on JRuby using Java libs for >> SOAP integration. That would really be a strong selling point to my >> bosses :-) >> >> Kindest regards >> >> Erik >> >> >> Per Melin skrev: >> > 2008/10/17 Erik Lindblad <[EMAIL PROTECTED]>: >> > >> >> I would like to do the refactorization using Merb+DM but the >> >> potential lack of SOAP support might be a showstopper. >> >> >> > >> > Are we talking about servicing SOAP requests with Merb, or using DM to >> > collect data from SOAP services? >> > >> > > >> > >> > >> > >> >> >> >> > > > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
