<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><br><br>--- On <b>Thu, 16/10/08, Rick Moynihan <i><rick.moynihan@gmail.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: Rick Moynihan <rick.moynihan@gmail.com><br>Subject: Re: [dundee] It's soa point, and SFD, and the have soap and rest....<br>To: toxicnaan@yahoo.co.uk, "Tayside Linux User Group" <dundee@lists.lug.org.uk><br>Date: Thursday, 16 October, 2008, 11:19 PM<br><br><pre>2008/10/16 Lee Hughes <toxicnaan@yahoo.co.uk>:<br>> next, on the list, I've been exposed (in a good way) to soa / soap and<br>rest<br>> , and that's not me having a shower and then a snooze. I just<br>wondered if<br>> anyone else has see this in action in enterprise type networks, it's<br>> certainly looks interesting. I've always liked the idea of distributed<br>>
services, but the only options in the past have been the evil dcom or even<br>> eviler Corba. At a guess .net probably this new soap and rest stuff<br>package<br>> up in Microsoft marketing, but I digress...<br>><br>> soa seems to be a great way of just gluing everything together in the<br>> enterprise, getting<br>> some extra millage out of legacy application that won't talk to<br>anything...<br>> Here's to the enterprise service bus!!!! perhaps!!??<br><br>Hey Lee, I'm afraid I'm *way* more _cynical_ about the whole<br>Web-Services stack. Now, I've not got any direct experience in<br>large-scale enterprise deployments; but I have worked on projects<br>which have had to both provide and use SOAP based services, and it's a<br>real mess!<br><br>People always accuse CORBA of being a real pig, and again I've not got<br>a significant CORBA background (though again I have developed a few<br>simple CORBA clients/services in several
languages), but I genuinely<br>believe WS-* hasn't, at least architecturally made any real<br>improvements to CORBA. Arguably towards the end, CORBA was getting a<br>lot better, but by then the mas exodus to web-services had begun.<br><br>SOAP however is far from simple, and suffers from a whole host of<br>problems. The biggest, ironically is it's massive sprawling<br>complexity... I mean to do SOAP properly, you need to be able to<br>handle and process XML, validate XML-Schema's, and be able to generate<br>WSDL. All of these technologies are in my experience poorly defined<br>and implemented and are unsuited to the problem... Rather than admit<br>this though, the WS-* vendors choose to cover up these flaws with yet<br>more rampant poorly defined standards.... Essentially Microsoft and<br>IBM reimplemented CORBA on top of an unholy combination of HTTP and<br>XML, ultimately creating something who's only similarity to the web is<br>port
80.<br><br>REST however seems to be a lot better, and I hold out some hope for it<br>as unlike WS-Deathstar it doesn't go against the grain of the web.<br>However it's pretty lacking in tool support, but is pretty simple...<br>It's benefit is that it's lightweight... However, I suspect some more<br>complex services will be a little awkward to represent in a RESTfull<br>way.<br><br>In my own opinion, very little has come close to Sun's Jini platform<br>in this space (See Apache River). Jini essentially handles the real<br>issues in distributable service design, such as failure and<br>self-healing...<br><br>It is fault tolerant due to it's implementation of lookup-services,<br>and leases. It has tuple-spaces for building workflows between<br>co-operating services. It's also network protocol agnostic, meaning<br>you can implement Jini across a combination of networks<br><br>The biggest catch with Jini in this space, is that due to it's use of<br>mobile
code, it requires clients to be able to consume and run Java<br>class files, whilst services need to publish Java interfaces. These<br>shortcomings can be overcome by proxying but it's Java-centricity may<br>mean it's unsuitable.<br><br>Anyway, I think we're still yet to see a good solution in this space;<br>but there are some interesting component technologies. I personally<br>think Messaging Queues hold a lot of promise (preferably without the<br>XML WS-* bloat). I'm personally quite keen to take a look at rabbitmq<br>with JSON messaging, or Amazon's SQS (Simple Queueing Service).<br><br><br><br>> also, while I was research web services, I can along amazons e2 service?<br>> seems pretty<br>> far out, anyone used this, or thinking about using it? A virtual host with<br>> 160gb of storage, 1.7gb of ram , and the ablity to scale up servers on the<br>> fly when you need capacity, seems like a crazy idea, but does it work.<br><br>Yes,
Amazon EC2/S3 and SQS are pretty awesome. One of my colleagues<br>raves about EC2, though I myself haven't used it yet. There were some<br>limitations to be aware of though, the biggest being data persistence<br>(though I believe you can now pay a bit more money and get this too).<br><br>--<br>Rick Moynihan<br>rick.moynihan@gmail.com<br>http://sourcesmouth.co.uk/<br><br>Nice one Rick, thanks for the tips, I'll do more investigating.<br><br>Cheers,<br>Lee<br><br><br><br><br></pre></blockquote></td></tr></table><br>Send instant messages to your online friends http://uk.messenger.yahoo.com