G'day Yariv,
On 02/12/2007, Yariv Sadan <[EMAIL PROTECTED]> wrote:
>
> >
> > 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.)
I don't know if "the enterprise" is ready to accept Erlang/ErlyWeb,
but I think there's a growing realisation that Java and C# aren't the
answer to every programming question. Java now runs acceptably fast,
but as soon as your code starts to spawn threads off it starts to get
ugly.
C# is pretty much in the same ballpark
There's also the case that the languages themselves aren't necessarily
the best fit for a large range of problems. In two big companies
where I've worked, there's a dawning understanding of two issues: (a)
the cost of buggy code is just way too high, (b) the cost of securing
sensitive code against buffer overflows and the like is also extremely
high; functional languages remove a large part of the opportunity for
these two problems to arise.
I don't necessarily think Erlang/ErlyWeb are going to get significant
enterprise mindshare, but I think that something other than Java and
C# will, very soon.
>
>
> >
> > >
> > > - 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
>
With Ruby on Rails, the M and C do what you'd expect; the V's job is
to format what C hands to it. In a Web services context, that means
that (typically) V's job is to take a hierarchical collection of
objects from C, and deliver it in the appropriate sequence or with the
appropriate format.
For example, C might return a set of authors, and under that, the set
of books they've written, ISBNs and so on. The V might present it as
<authors>
<author name=>
<book title=>
<isbn id=>
but a different V might present the same info as
<books>
<book title=>
<author name=>
<isbn id=>
In essence, the V layer can be used to juggle the hierarchy of data
given it to by C. I realise this could all be done in C, but then you
might wind up with multiple C layers to present identical data in
different ways; Rails uses multiple V layers instead, and gives a
domain-specific language (RXML) to allow you to tweak data as per the
above in a very simple manner. Extending and maintaining RXML code is
particularly simple.
I like the way this works in Rails, but in the end it's a syntactic
sugar more than a must-have feature.
>
> >
> > 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 strongly suspect ErlyWeb could scale far better than J2EE for some
specific use cases. Erlang's ability to create new processes quickly
(not to mention simply) gives it an advantage that must have some
benefits...
>
> >
> > 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?
Yep, I can see how that makes sense. I haven't really used JSON in
any non-learning context, so I'm still coming to grips with how/where
I should be using it. I've had a bit of a prejudice against
JavaScript as a "toy" language for years, and now I'm finding I have
to unlearn that prejudice.
Smarter people than me could probably give some better advice in this area.
Regards
Dave M.
>
> 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
-~----------~----~----~----~------~----~------~--~---
