Mark Baker writes...
Finally, the Web's getting its due.The most interesting vendor at the Infoworld Executive SOA Forum last week was ActiveGrid, a LAMP-based grid for various purposes.Ok, so who wants to break the news to the Grid folk? 8-)
"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.
Mark Baker writes...
Finally, the Web's getting its due.The most interesting vendor at the Infoworld Executive SOA Forum last week was ActiveGrid, a LAMP-based grid for various purposes.Ok, so who wants to break the news to the Grid folk? 8-)
Or was that the old Same place? Nevertheless...
I'd sure like to understand this claim and prediction from Eric Newcomer of Iona...
Now with customers deciding on the approach independently of technology, the roles are reversing. Customers are starting to tell vendors what kind of technology they need by creating their SOA based designs independently of their technology decisions.I see a lot of people putting blind faith in WS-* because the industry has told them to. But then the industry says WS-* interop is not ready and there is no standard for a full service bus, so you have to make an investment in a specific vendor.This strikes me as a very good trend, and appropriate for where we are in the evolution of the software industry, helping to lead us to a place of resolution for the current frustrations with enterprise software.
Same old story from what I can see. Anyone that wants an agile enterprise can get it using technology that is ten years old or more. There is *no* need to invest in WS-* or an ESB. I think an ESB could be a good investment in some cases but not because of any promise of a "standards-based platform".
Let's celebrate another post from Ralph Johnson...
I do not say that program development *should* be program transformation, I claim that it already is. Most work on software is after the first released version. The purpose of work on existing software is to transform it to the new version. Since almost all work on software is converting version N to version N+1, almost all work on software is program transformation...I do not claim that program transformations are easy, or that they can be automated, or even that we can always understand them. I am claiming that thinking of software development as program transformation is likely to lead to improvements in how we develop software.
My favorite observation from Infoworld's Executive SOA Forum last Thursday came from The VP of Enterprise Architecture at Sony Pictures Entertainment. Pointing out that SOA is nothing new, he had first encountered the idea in Tandem's shared nothing messaging capability. (pdf)
The same observation was made by Alan Kay in the 1960's about the Burroughs B5000 and contributed to his invention of Smalltalk. And then there's Erlang and other shared nothing systems.
You wanna make fourteen dollars the hard way? (WAV)-Rodney Dangerfield, Caddyshack
James Robertson makes an observation that will please my 13 year old (a dyed in the wool Nintendo fanatic)...
Sony's release dates for the PS3 are starting to look like the planning for Longhorn
Tim Bray writes about WS-* vs. ReST/HTTP...
Speaking for myself, not for Sun, I think that we ought to be pouring resources and investment into tooling and developer support around simple XML/HTTP/REST technologies. You know, the standardized ones that work today.Vendors have sunk a lot of time and money into SOAP and WSDL. Appearances are this effort has gone into easing the burden of programming with SOAP and WSDL. That should tell us something about their languages as well as something about SOAP and WSDL.
What's the result?
Adam Tratchenberg spoke about ebay's approach to versioning their numerous web services at Infoworld's SOA Executive Forum last Thursday. When asked how ebay performs compatibility tests across multiple languages and toolkits, his response was they test with Java, .Net, and PHP. My guess is they don't test with many of the Java toolkits. Perhaps they test with .Net's various toolkits because Windows many programmers are in various stages of adoption.
Anyone with an incompatible toolkit or language though is not left out in the cold... ebay provides an HTTP and POX interface for each method. Can ebay's approach be considered a success for SOAP and WSDL given this lack of universality?
What if the vendors sunk as much money into making HTTP and POX as convenient as they're trying to do with SOAP and WSDL?
Meanwhile at least the long march toward more compatibility in WS-* continues. I've not found a list of attendees to Microsoft's interop session. My sense is the list of languages and toolkits is fairly short (Indigo and Sun's Java toolkit. Others?)
Is this a barrier to entry that guarantees its ultimate demise?
mdavidx5 asks a great question in response to my post about Amazon's S3...
Why the fuck do people have to insist on complicating things?Maybe it is the case that S3 is the simplest thing that could work. But I think there is something between S3 and the full-blown web hosting provider he's fearing.
The simple way S3 works is as an associative memory between keys and values. As long as you know which key to use, this is a great service. But what if you need to retrieve your data based on some contents?
The key / value pair approach of S3 is the degenerate case of associative memory. I don't think S3 has to be about anything more than storage, but there I think there will be some room for associative retrieval of some complexity beyond simple keys.
If the pipe was big enough then there would be no trouble bringing gigabytes over the pipe and doing the associative lookup remotely. Or one could store in S3 the data itself under one key and various indexes under another set of keys. That's clunky but I can imagine someone trying it.
mdavidx5's point is well taken though. Keep it simple.
Stephen Williams writes in the FoRK email list on an exchange about Amazon's new storage service...
I firmly believe that both full filesystem semantics and ACID integrity constraints are red herrings and have seen a number projects reach the same conclusion...Having worked on and with very complicated object-oriented databases, very complicated relational databases, and other approached, I've noodled for some time on the possibilty that there are three basic persistence patterns that can meet a ton of needs.With database-based applications, even when you have ACID capabilities, there are a number of reasons to avoid updates, avoid "accumulators", and otherwise avoid many of the situations where you needed transactions to begin with.
I will be interested to learn if Amazon has now or will offer some higher-level services on their storage service. Search, matching, versioning, etc. I see they want to keep it simple, and I agree with that. Before long though people will want to do things with their storage. Some of those things will be better done very close to the data itself.
I wonder if/when we'll see the ability to put computations very near Amazon's storage (including indexes, calculations, searches, etc.) that are aware of the format of the stored data, that is secure, etc. Storage is just the most basic start of a shared grid of services.
A problem with our industry (is it more than ours?) is the loose use of terms that truly have a formal definition. What is the meaning of this claim?
In contrast to standard distribution middleware such as CORBA or Java RMI, an SOA implements processes as first-class entities.This is on page 58 of the March/April IEEE Software magazine (pdf). I wonder if the editors have any more sense of how wrong this is than the authors?
First of all, SOA has no formal definition. Secondly, in any common use of the term SOA, there is nothing resembling a process, let alone a first-class process.
Smalltalk has something close to first-class processes. Kali Scheme, yes, even distributed first-class processes. Termite Scheme, uh-huh.
SOA is so far from having anything resembling first-class processes that such a claim in an institutional publication is incredibly disheartening. In 2006 our programming languages *should* have first-class processes.
Mark Baker points to a really interesting application of REST to dynamic networks of small devices.
The primary mean of abstraction within pREST is a resource. Virtually anything that can be uniquely addressed with a URL is a resource: devices, services, and configurations as well as documents, pictures, and raw data. Resources can be nested, so that services and properties of a component being associated with URL are resources themselves.
I will be at the SEM SIG meeting tomorrow night in Palo Alto to hear Mary Poppendieck talk about Lean Software Development (see quote below). Then Thursday I'll be at the Infoworld SOA conference in San Francisco.
Jon Udell, Phil Windley, and others will be at the conference, which should be worth the price of admission alone. Well, I got a free pass. So worth *more* than the price of admission!
I will be looking for entries to put on the ws-success wiki. The agenda looks good -- not just vendor fluff.
From Mary's abstract on Lean Software Development...
Lean Strategies for Software Development Leaders What do PatientKeeper, a hospital data management system, and Zara, a high fashion clothing chain, have in common with Dell Computer and Toyota Motor Corporation? All four companies are overwhelming their competition with a constant flood of new products that seem to be exactly what customers want, even as they set the standard for quality and value. How do they do it? To these companies, Lean Thinking is a way of life: Customer Value, Rapid Response, Constant Learning, Built-in Quality and Engaged Workers are part of the culture.
Jon Udell, et al. wonder about the value of open source and/or standards.
I would hesitate to adopt any standard that does not already have a up-to-date open source implementation. And I would refuse to define a standard without concurrently defining an open source implementation.
I've been involved in two standards definition processes. Neither had any significant implementation or formal model to guide them. I suspect other standardization efforts have suffered similar consequences.
Mistakes were made.
From the SOA Yahoo group, Greg Wonderly writes about Jini and Javaspaces...
One of the primary issues we have in the Jini community, at large, is that the Sun Jini team has commented in private that there are many different users of Jini which do not wish to have public recognition. Some developers have told me that Jini provided such an large, positive impact on the development and systems, for such a small investment, that they consider it a competative advantage that they don't want to talk about. I.e. it was so cheap and easy to use that their competitors would be able to be on par with them quickly.
I have created a wiki, http://ws-success.pbwiki.com, for capturing and refining success stories about implementing distributed systems with technologies that follow ws-* standards (SOAP, WSDL, etc.)
Please feel encouraged to capture your success stories there or contribute to the stories that may already be there by adding your experience with an existing story, technology, or standard that may be part of that success.
Feel free to leave questions about the stories too, but please respect the content that may already be in place. Don't edit someone else's story unless you are contributing to a faithful rendering of a common experience.
Firefox 1.5 now supports SVG, if you've not heard the news. You can see this in action on a fun learning page about orbits and how our moon may have been created.
Dave Thomas (the Smalltalk Dave Thomas) writes in JOT...
We need to move beyond the complexity, limitations and weaknesses of Smalltalk and Lisp but seek a language with at least as simple a syntax and more expressiveness.Here's a programming leader who knows his stuff and I love the fact that he refers to Smalltalk and Lisp as being complex, and having limitations and weaknesses. These are not the be-all and end-all even though they are better than anything that's come along since their invention 35-45 years ago. Noodle on that: 35-45 years without a significant leap forward in programming languages.
Maybe we'll go another 100 years without that improvement. Maybe that is to be expected.
I have created a wiki, http://ws-success.pbwiki.com, for capturing and refining success stories about implementing distributed systems with technologies that follow ws-* standards (SOAP, WSDL, etc.)
Please feel encouraged to capture your success stories there or contribute to the stories that may already be there by adding your experience with an existing story, technology, or standard that may be part of that success.
Feel free to leave questions about the stories too, but please respect the content that may already be in place. Don't edit someone else's story unless you are contributing to a faithful rendering of a common experience.
Update: Jon Udell happened to know where to find the information I was listening for. And created the excerpt.
Lisa describes how to use WebDAV to lock events, multiple events, access control, etc. Then she explains that a narrow number of features are needed specifically for calendering, e.g. how to query free/busy information on someone's calendar.
I sure wish I knew whether Lisa thinks we need a DAV extension for every kind of resource. Assuming not, why are calendars special? I think we need *conventions* for using HTTP per se to do versioning, locking, accessing, calendaring. I certainly hope we don't need extensions for every kind of resource. Oops. Isn't that like SOAP?
End Update
I am listening to a podcast, something I have done only a couple of times because I would much rather read than listen. In this case it is IT Conversations with Lisa Dusseault on calendering, CalDAV, and WebDAV.
What I most want is to know whether the question comes up as to why WebDAV and CalDAV are necessary. The logical conclusion of this approach is every resource on the web has its own application protocol... PurchaseOrderDAV, MovieDAV, ShinyObjectDAV, etc.
I don't have the time to listen to 30 minutes of conversation to see if this comes up. So I am on the lookout for a relatively easy to use and free or open source speech to text conversions.