Hello everyone, Responses within Willem's text...
On 30/11/2007, Willem de Jong <[EMAIL PROTECTED]> wrote: > > Hi, > > A couple of days ago Dave M. pointed out that ErlyWeb could benefit > from > a web services framework (in the thread about Strenghts and > Weaknesses). > > I would be willing to try to improve this, but I would like some > guidance: what > should it do? > > I will probably use the existing yaws+erlsom implication as a basis, > but I agree that it > can be improved. In particular the set-up could be easier. > > - I already have some code available that improves the handling of > import statements. > > - What flavours of webservices should be supported? Currently we have > the > 'document/literal' type only. >From my perspective, the most important would be SOAP and XML-RPC, with others such as JSON and REST well behind those two. The reason is that SOAP is pretty much *the* standard interface for developers working in the WebSphere/J2EE and .NET arenas. If we want to push Erlang into the "enterprise" (and I use that term loosely) areas, then it really has to be able to work with WebSphere and .NET; if not, the "default" solution of "forget this Erlang stuff; we'll just build it in our normal toolset" becomes a lot more difficult to counter. In general, for people working with J2EE and .NET, REST is probably on the very edge of their perception. Obviously that's a sweeping statement, but the reality is that J2EE and .NET have pushed SOAP (and to a lesser extent XML-RPC) as *the* Web service solution for many years, and as yet there's been no push from the key software vendors to entice people to even look for something beyond those protocols. >From an individual developer's perspective, there's no incentive (beyond professional curiosity) to even look beyond SOAP when everything you work with daily already talks SOAP? Personally, I see REST in particular as a big step forward, but in my corporate experience that's not a common perception. > > - What type of interoperability issues should I be aware of? > > - Should there be a strong link to the rest of erlyweb? What should it > look like? Or would > it be sufficient to offer support for web services in YAWS in a nice > way? The handlers could > call the ErlyDB APIs, of course. Personally, I'd like it to be hooked to Erlyweb rather than to Yaws - I think the MVC model in Erlyweb hits a very big sweetspot, and Erlyweb would be my choice (rather than Yaws) as the base platform for most Erlang Web development at this point. However, it's obviously early (erly?) days for Erlyweb yet, so I'm not particularly locked in on this thinking at this point. I'm sure there would be benefits in hooking to Yaws instead of Erlyweb that I haven't considered. Has anyone else got any thoughts on this? > > - Should there be a generic framework that also covers XMLRPC, REST, > Json? Is there an > example of such a framework - maybe in Ruby? Ruby on Rails (RoR) has a framework that covers SOAP and XML-RPC (Active WebService); basically it takes about 10 minutes to implement it on top of your existing functionality, so it's trivial to add a Web services interface for these protocols to your existing (HTML) application. RoR seems to moving towards deprecating Active WebService (AWS) in place of a REST interface; I suspect the reasoning is that relatively few people are using AWS as RoR seems to be targetting standalone applications in startups as their key market, and REST is conceptually easier to understand and implement when you're not having to interface with J2EE and .NET apps. Personally, I've found RoR gets huge acceptance all over the place purely for the reduced development time; it doesn't scale that well (or more accurately, it becomes expensive to scale it), but the vast majority of apps in big companies don't need to scale to big numbers of users. If I can have a demo RoR app built that's 90% functional while the J2EE and .NET guys are still working out which versions of their various libraries will work together, that's a pretty major selling point right there. I can imagine something > generic for all the > XML based variants, but I struggle for JSON. Not because it is not > XML, but because there > appears to be no 'schema' for JSON. It seems to me that such a > framework would require > some kind of metadata/specification, like a schema or WSDL. Personally, I think it would be harder to create a generic JSON solution than for the other protocols, for the reason you've outlined - there's no commonly-agreed schema. There is for SOAP and XML-RPC, and REST has a "sort of, defacto" agreed mapping to the general CRUD database access model. If you tried to create a generic JSON solution, I can't see how you could avoid defining your own schema, and then users would have to build tools that talk to your schema specifically. My guess is that, in that case, an IBM/Microsoft/Sun/... would almost inevitably come out with a completely different "standard" schema within the next month ;-> > > - anything else? No, that's about all I can think of at this point. Now I'd better hustle off to work - I'm gonna be late... Thanks for your response Dave M. > > Regards, > Willem > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "erlyweb" 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/erlyweb?hl=en -~----------~----~----~----~------~----~------~--~---
