"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Saturday, March 25, 2006

It's Enterprisey!

Overnight this new term and meme has taken hold. Would that I were not familiar precisely with that that it implies.

It's enterprisey!
Update:

Bill de hÓra writes in lesscode that the term now has among other things, a wikipedia entry, and a wonderfully animated architectural illustration with its own theme music.

Da-da-da-da-dadadadada! It's enterprisey!

Paul James on REST/HTTP

I don't think I've seen these before. Paul James has a number of useful REST articles on his site.

I believe heavily in developing web applications using the KISS principles of "less is more".

Friday, March 24, 2006

One Method Too Few or Too Many?

Ethan Fremen writes in a lesscode comment...

The main way in which the additional verbs are really helpful in an application is whenever you want to manipulate multiple resources at once. Of course, in most cases where you’re doing that, you’re using even more of those ‘useless’ verbs, like MKCOL and PROPFIND etc.

To me it’s like you’re arguing that the only methods anyone ever needs on a class are gettr and settr methods.

I don't think the comparison with an object-oriented programming language is helpful. Classes with only getters and setters are brittle in their context (very small amount of state that changes often, very closely located to collaborating objects within a single OS process, one or a few developers working together modify most of those classes, short release cycles).

On the other hand with a distributed system it may be that the more methods in a system the more brittle in that context (very large amount of state that does not change often, very remotely collaborating systems across multiple network boundaries, many developers who know little if anything of each other, long release cycles)

A mechanism to "manipulate multiple resources at once" in the latter, distributed HTTP context may be to construct a resource that represents the collection of resources and then manipulate *that* resource using the smaller number of verbs.

The hurdle I've mostly climbed over to the level I currently understand REST, HTTP, URIs, Atom, etc. is that this is not an object system. This is an application protocol (and architecture, formats, etc.) for distant collaboration. The challenge is to understand what are the conceptual pieces in this system and how to map ones needs into this system.

Most of the heavy computational lifting of those resources *does* take place in object systems (or functional or...) where there is a rich processing vocabulary. The distributed part is just about moving representations around in a coordinated fashion to enable the heavy compuational lifting at the appropriate time and place. The architecture for one is most likely not going to serve the characteristics of the other. The more they are considered distinct the better.

That said, I cannot clearly articulate when to create a new method except that the resistence to adopting that new method will be great so the time spent thinking about how to use the existing methods will more likely be the time well spent.

My second articulation would be to suggest that if you want to create a new method or two, then probably so do I and so do several others reading this. Before long we would be drowing in a sea of new methods. There may be a Cambrian Explosion of new collaborative techniques if we focus on how better to combine the pieces we already have. Inventing another nucleotide should be a very high bar.

Update:

In another lesscode comment Paul James confirms this approach...

You don’t need new verbs to manipulate multiple resources at once, you just need another resource that represents all the resources you want to manipulate together and to then manipulate that with your existing verbs.

Thursday, March 23, 2006

TSSTTCPW

Good news for Java programmers seeking the simplest SOAP stack that could possibly work...

I am back implementing Alpine. This has no dynamic redeploy, no ease of use features, no Java1.4 support, no annotations. It's going to be so simple I will have it working before I fly off to the Alps for my ski trip

Wednesday, March 22, 2006

The Coming Breakage: Minimize Dependencies

Steve Loughran writes about old binaries running (or not) on the next version of the Windows OS...

Now, making old apps work bad may finally create incentive for people to upgrade their office suite, but it will also break every single IT-written win32 app out there. That's serious, and going to become and ongoing issue, I suspect.

Fortunately, there is a workaround. Don't write Win32 binaries. Code in Java, Python, Ruby, Squeak or other interpreted language, and trust the runtime to be signed by the time vista ships. You sneak past the security problem without having to go to any effort, and you avoid being at all dependent upon the OS and any more delays.

If you want to take advantage of some specific OS, framework, library, or whatever... why would you not code the independent 80% part, well, independently? Writing software to your advantage is always about minimizing unnecessary dependencies.

Monday, March 20, 2006

$100

Don Box has a couple of interesting posts on Microsoft's support for REST/HTTP. I don't know a whole lot about the products, but there's a long list.

He asks a good question: how would you dole out $100 in support of REST/HTTP within Microsoft. Since I cannot really address specifics within their current product line, I'd consider something like this:

  • $25 toward furthering their current investments in open REST technology, e.g. Atom and APP support in various systems and frameworks.
  • $25 toward open RESTful "push" technology, e.g. XMPP and mod_pubsub.
  • $25 toward a RESTful coordination technology above HTTP per se. Something like Rogue Wave's defunct Ruple XML tuple space, but using REST/HTTP. Deliver this as a live service (i.e. like Amazon's S3 but with somewhat richer associative memory than just keys or URLs (a URL is just a key, right?)) as well as a framework that others can deliver on their own systems and customize.
  • $25 for better treatment of dynamic languages at Microsoft. I believe REST/HTTP/XMPP/etc. are to distributed systems generally as dynamic languages are to programming languages generally. To be fully RESTful I think you have to be as simple as possible and fully dynamic. Doing this will stimulate more RESTful ideas within Microsoft. I know they have a number of Ruby programmers... turn that amp to eleven.

LAMP on a Grid

Mark Baker writes...

Finally, the Web's getting its due.

Ok, so who wants to break the news to the Grid folk? 8-)

The most interesting vendor at the Infoworld Executive SOA Forum last week was ActiveGrid, a LAMP-based grid for various purposes.

Sunday, March 19, 2006

The Same Old Place

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.

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.

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.

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".

Software Development *Is* Program Transformation

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.

Saturday, March 18, 2006

BS-Transfer?

Mark Baker writes...

I'm calling bullshit on WS-Transfer. Please join me.

Favorite SOA Observation

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

But Will It Be Compelling?

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

What is Success?

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?

Keep It Simple

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.

Wednesday, March 15, 2006

Storage Paradigms

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...

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.

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.

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.

Tuesday, March 14, 2006

First Class Nonsense

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.

A Little Rest Here and There

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.

Bay Area Adventures

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.

Monday, March 13, 2006

Open Source and/or Standards

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.

Sunday, March 12, 2006

Bonne Chance

From Ajaxian...

Will Microsoft buy DabbleDB as they realise that it is what Office Live should be?

Monday, March 06, 2006

Jini and Javaspaces -- Distributed Systems Secret Sauce?

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.

Saturday, March 04, 2006

ws-success

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.

Follow the changes with the RSS feed or the Atom feed.

Thursday, March 02, 2006

Fun (and Learning) with SVG

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.

Wednesday, March 01, 2006

Next Move in Programming

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.

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.