>
> 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.
Do you think the "enterprise" would accept Erlang/ErlyWeb as a
platform for web services development, though? I was under the
impression that most "enterprises" use .NET and Java because it's
easiest to recruit engineers who know those languages. Would the CTOs
of such companies consider ErlyWeb just because it performs better
than Rails? (The performance difference is hypothetical -- I haven't
seen any benchmarks to base it on.)
>
> >
> > - 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.
I'm not sure that a web services implementation needs all the MVC
capabilities that ErlyWeb provices, but the 'M' should certainly be
useful, and maybe also the 'C'. Mapping incoming requests to ErlyWeb
controller functions would be elegant I think, but ErlyDB would
certainly be useful for someone who's building web services
>
> 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.
If ErlyWeb scales as well as or better than J2EE (it's possible!) and
lets you develop as rapidly as Rails (if you know Erlang :) ), maybe
it would hit a sweet spot.
"ErlyWeb = enterprise scalability + agile development". If we only had
a marketing budget... :)
>
> 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 ;->
I don't think you necessarily need a generic JSON solution, but an
ErlyWeb-specific one would be useful for ErlyWeb developers.
Applications often make AJAX calls to a backend controller that
returns JSON. I think it would be useful to support Erlang -> JSON
serialization in the framework. Ideally, you could write your code
generically and let the Framework serialize it for you based on the
protocol. For example, the following response could be easily
translated to JSON (and maybe other protocols) without needing a
"standard" schema type:
-module(api_controller).
-compile(export_all).
foo(A, Param1, Param2) ->
{rpc, [1, 2, 3, <<"foo">>, <<"bar">>, {dict, [{a, {string, "b"}},
{c, {string, "d"}}]}]}.
Any thoughts?
Yariv
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
