Web 2.0

This article is a month old but good. I especially liked the chart with stuff like
Ofoto --> Flickr
Akamai --> BitTorrent
mp3.com --> Napster
Britannica Online --> Wikipedia
...
but then there was
screen scraping --> web services

and I was like wtf mate? WS does quite a bit ... "more" than screen scraping. It wasn't long before Tim shut me up.

Once the idea of web services became au courant, large companies jumped into the fray with a complex web services stack designed to create highly reliable programming environments for distributed applications.

But much as the web succeeded precisely because it overthrew much of hypertext theory, substituting a simple pragmatism for ideal design, RSS has become perhaps the single most widely deployed web service because of its simplicity, while the complex corporate web services stacks have yet to achieve wide deployment.

...which, for those of you just joining us, is dead on. There will, of course, always be a place in the world for thick, fat stalks of really-complicated SOA apps that can run a whole department or a whole company. But I don't see these impacting the general public much.

What has much more creative potential are specific little very-hackable webservices that do one thing and do it well. Throw a few hundred thousand of them out into the Net and see what a bit of remixing does for them.

This, of course, assumes that creating/modifying webservices without licensing the various applicable (ha) patents remains possible.

Anyway, read the rest of that article. Very slick.

Important - "Live" is not alive yet

Alright, let's do a little Microsoft commentary. Starting again, with Phil's commentary.

But, let's look at some other MS analysis and combine the two a little...

Most relevant in the MS analysis to our discussion are the last 2 paragraphs in that 2nd page, so read those at least.

So in 2000, Microsoft said that .NET products and services "Includes Windows.NET, with a core integrated set of building block services; MSN™ .NET; personal subscription services; Office.NET; Visual Studio® .NET; and bCentral™ for .NET."

So a couple of quick Google searches show Windows.NET doesn't exist, MSN.NET doesn't exist (though MSN does include some of those "personal subscription services"), Office.NET doesn't exist, Visual Studio.NET exists (and is actually quite good I hear), and bCentral was shelved.

Microsoft's initial description of .NET was the perfect example of what Wainright described - "Announcing an offering that doesn't exist yet buys valuable time while the vendor brings it into being." Today's .NET is only related to what Microsoft said it would be.

Let's apply the same logic to these new Live offerings. Aside from a Google Personal Homepage rip-off (Phil calls it a Web 2.0-style portal template), we're supposed to be seeing things like Internet-to-phone, virus-scanning, and web hosting. But we don't see them. We only hear about the plans for them.

This is because Microsoft is probably throwing out some marketing in an effort to cool down the hype around Google. But if they were to actually follow thru on the vision of the web as a base platform, they have to jettison their precious marriage to the operating system as the base platform. And since the www.live.com site does not support Firefox (coming soon, yeah right), Microsoft hasn't even shown that small amount of interest in using a standardized web platform.

That's all for now. Between the time I started writing this post and the time I actually posted it, most of the buzz around the Live offerings predictably died down. It's obvious that Microsoft is playing catch-up and is using the old vaporware tactic. It's not going to work this time.

SoSaaS

Same old Software, as a Service. Phil Wainright has a few of these straight-up slam-dunks.

From the second link, about the difference between ASP's in the 90's and today's real services models - "designed from the ground up to be delivered over the Internet on pay-as-you-go terms."

From the third link, somewhat related, as to why there can be a real SaaS model - "No on-demand customer pays simply for the privilege of accessing the software. They pay because the software delivers business results." [emphasis his]

I like Phil's analysis, and I've slapped his RSS feed right on the front of my Google Personalized Homepage. And since I want to contribute back, I'll add on some of my own analysis.

I think a perfect (and very successful) example of a software-as-a-service model is Google AdWords. Basically, the way AdWords works - an advertiser sets up an AdWords account with Google, and can then create some basic text ads for Google to display on the most relevant sites, targeting by content. The advertiser deposits a certain amount into their AdWords account, and specifies how much they are willing to pay for each click-thru they receive via Google ad listings.

The two important characteristics here are that the software service is designed to 1) be delivered on the internet 2) on a pay-as-you-go basis.

Obviously, the service revolves around web content, so it's built with the web in mind. That kind of design enables great expansion, as I'll describe in a bit...

But also key to the success is the pay-as-you-go aspect. If a business buys the AdWords service, they don't pay for access to AdWords, since creating an account and creating the ads are both free activities. They are paying directly (and only) when the service yields actual business value - a marketing contact with potential customers.

Furthermore, the business has complete control over their software service budget. They can start small and go up on their own pace. Can you imagine if Google tried to sell this as a one-time fee, or tailor it to each advertiser? The pricing difficulties for Google and the advertisers would be monstrous and costly, and the advertisers would be stuck only with the prices Google can come up with.

The internet-designed service enables more and more application of the service instead of traditional software model - a single use per application. Related to AdWords is AdSense which is another software service to help Google (and others) make money by helping AdWords's advertisers. AdSense lets anyone display the ads and receive a portion of the click-thru fee. Because AdWords was designed for the internet, it has application at Google - ads displayed in their other software services like GMail, Google Search - and outside of Google via the AdSense program. And Google recognizes that it can and should pay its AdSense partners when those partners' services (target-marketing/advertising) deliver business results as well.

All of this is to say that SaaS is not only sound, but is already a huge software market for those that implement the right kinds of software services - that deliver business results.

UPDATE: I read this post of Wainright's AFTER I wrote this post. And he included such good analysis of API-accessed services like AdWords vs. On-Demand services that I included yet another link to his blog. That guy is awesome.

Linux (open-source) & Interoperability (again)

Couple of articles to read to get the perspective from which I'm writing this.

CSP said their need was "increased integration with other criminal justice agencies," and they deduced, dear Watson, that the key to integration is "a standardised infrastructure."

That seems to play nicely into the first article I cited, which discusses how the usual suspects of open-source "big boys" are going to lend support to the Linux Standard Base project in an effort to "encourage the development of more applications for the Linux platform."

So this is all good, but what does it have to do with Web Services? I'm glad I made you ask.

CSP wants increased integration with other criminal justice agencies, and I'll make a few assumptions...

1. The other agencies they're referring to are not-Linux organizations.
2. They don't need to interoperate at technical low-level detail - EBCDIC vs. ASCII, Big-Endian vs. Little-Endian and the like.
3. The agencies are not big organizations and do not have big IT budgets.

Looking at everything it's NOT, we can see they're probably talking about Windows interoperability at the application level on a small-to-medium-sized budget. This is important because of this.

One of the most alluring ways in which Microsoft is promoting .NET is that it gives developers simplified (though proprietary) framework, methodology, and libraries for developing networked applications. This is a big contrast to J2EE which is very complex, and therefore requires significant time and labor to implement. As such, although open-source, free J2EE products are all over the place, the total cost can indeed be higher than getting a .NET license and hiring one really good .NET programmer.

I am extremely excited about the idea of PHP Collaboration Project (PCP, hah!) which "will aim to compete with Microsoft’s .NET platform..." Especially if it seeks to do so with an interoperability approach based on WS - another approach that Microsoft boasts, and developers, and businesspeople, are attracted toward.

However, we can probably guess what kind of "interoperability" Microsoft .NET may encourage - .NET Remoting rather than Web Services, C#.NET and ASP.NET and VB.NET apps working together, etc. Basically, Microsoft is still convinced they can own the space and lock everyone into their single platform. But that single platform is very attractive to people like CSP and other small or medium-sized orgs because it reduces complexity.

I would love PCP to do the same thing - reduce development complexity and cost for small to medium businesses. But at the same time, keep those business from the lock-in scenario, and maintain a standardized WS-based interoperability approach.

That would seem to line up with the requirements of orgs like CSP which would keep them from jumping to Windows.

skipping a post

I had a post about 'SOBA' typed up, but I lost a large part of it, so I may have to just throw that one out and leave 'SOBA' with just a link and this summary:

Another buzzword does suck, but I like the notion of creating Business Applications (BA) out of Service-Oriented (SO) components. Like Matt's analogy of composing Lx shell scripts or utility programs out of the small, text-processing utilities already available. For SOBA, you lay out your business processes, and then you compose the implementation out of these or those small utility services.

The real post for today is a response to 'Open Servicing' in one of my favorite mags. The synopsis of the article is that Apache Synapse is an open-source platform for deploying web services in an ESB architecture, and that it's a great idea because consortiums of vendors tend to make standards and practices that are overly complex and borderline proprietary.

Some gems from the article:

"It seems as though as soon as the open source community rallies around a technology, the IT industry starts taking it more seriously - and finds practical application for it. "

"...although technology standards are driven by a consortium, the consortiums are primarily representative of a handful of mainstream vendors with large market shares."

"The standards in Web services are becoming unmanageable...As a result, the Web services that are being developed in most organizations are not well thought out."

I've never had to deploy an entire SOA since most of my web services work just involves integrating 2 heterogenous environments with statically discovered services. As such, I'm very guilty of the charge leveled in the last quote there. I would love to see Apache make this a great project to better deploy, manage, secure, coordinate, ... web services.

Right now, I think most developers are just implementing the simple stuff like SOAP and WSDL, or maybe some of the more vital and down-to-earth WS-* standards like WS-Security, WS-ReliableMessaging, WS-Addressing. Some pretty gutsy outfits out there may be doing the whole WS-Policy & WS-BPEL dance, but like the article says, it's complex, confusing, and largely designed to fit into a handful of vendors' product roadmaps.

More and more, I think informed skepticism with regards to WS-* is in order. However, un-intelligent and reactionary jabs from a single-vendor perspective are not in order.

Reynolds's SOA definition

in response to Matt's post, which was a response to Reynolds's post, I would say the following...

cajo's response sounds nice to developers, because it's what they want to hear - we don't need to change the way we do things; SOA is just new buzz-hype on what we already do. but it would not be "honest" to say "that SOA means nothing more than separating business functions into routines, just as they have always done."

for example: one of our developers separated his business functions into routines: he made 11 .cfm pages of ColdFusion code, and then 1 page of ColdFusion code with 12 cfinclude tags. even if the only thing you've read is the senseless marketing trash that vendors are putting out about SOA, you know this cfm approach is not SOA, even though it is separating business functions.

Reynolds includes the key distinction at the end of his definition (a smart place for it):

"Each service provides an interface-based service description to support flexible and dynamically re-configurable processes"

the interface-based service description is mandatory. it's what makes an SOA different. the architecture is not based on identification of objects in the system, as with OOP. rather, objects come about from the descriptions of the services that need to be performed. neither is the architecture based on run-time context as the case with procedural includes of multiple script files.

the service descriptions come first, and are arranged into composite, higher-level services with their own descriptions. this is the key between SOA and other approaches to modularity.

I first encountered this in Erl's first book when he talked about the similarity between OOP and SOA - code to the interface. but with WS-based SOA, the interface is described using a standardized format so that the services implementing the interface can be in any language on any platform.

so the good news is that it is indeed another attempt at creating modularity and re-usability in software. the bad news is that if you work under the assumption that that's ALL it is, you won't really be capturing the benefits of SOA.

(Microsoft != Web Services && Web Services != SOA)

I'm trying a new tactic with the blog. I've added my brother Matt to make this a team blog. hopefully he can help me in keeping posts pretty regular. I think I've first thought about having him make posts about web services, but we may end up just co-blogging on web services and open source.

now, I read an interesting opinion. I'm all for healthy skepticism and realism, but Fergesun isn't offering a good deal of either. the "tone" of his writing seems more like whining than real criticism.

he first shows his Microsoft fanboy side with this whopper:

"Web services are great! If you have to interoperate with non-Microsoft systems, they may be your only option."

now, even if one doesn't hate Microsoft, one would have to have their head buried pretty far into the sand to ignore the growing interest among enterprises in running platform-neutral software systems. hell, Java's popularity is largely a result of that single capability. I think it's a pretty safe assumption that if you're building software that will handle any meaningful amount of a company's business, you're going to need (or at least want) to interoperate with other systems in the company - be they non-Microsoft, non-.Net, non-Windows, non-American, non-Expensive, non-UnderYourTotalProprietaryControl, etc.

and his last direct quote I'd like to deal with:

"What I do not buy into is the idea that all systems should be seen either as services that expose their functionality only via unidirectional XML messaging or as clients of such systems."

well, news flash to Mr. Fergesun, "unidirectional XML messaging" is not SOA. what you've described is Web Services, though even web services are growing out of the unidirectional phase. while most SOA proponents think Web Services are the best means to achieving SOA, the two terms are not synonymous. so I'll be sure to make note when Fregesun is criticizing a technical aspect of Web Services that is not intrinsic in every SOA architecture.

Fergesun's problems listed are the "change in thinking" that comes along with asynchronous system operations, versioning, and reliability. in all of these cases, he mistakes Web Services as the only means to SOA, and furthermore, his Microsoft-centric perspective keeps him from seeing how these problems are actually addressed by web services.

in mentioning asynchronous operations, Fergesun ignores the fact that SOA != Web Services. it is entirely plausible to build service-oriented software that communicates via synchronous protocols. however, there is a very good case already made(by someone much smarter than myself) that asynchronous architecture is more appropriate for modern systems - that is, highly networked systems using the internet as their core platform. but Fergesun does not mention any of the merits of asynchronous architecture; he only laments the need of a "change in thinking." perhaps if Microsoft had written a white-paper on the subject and released Microsoft Change-In-Thinking XP, he would be more willing to buy...er, accept change.

as far as versioning goes, the .NET CLR approach does not alleviate versioning problems, it only changes them to be more like Java-on-Windows (other platforms, if you're crafty). for example, if your program requires functionality that is in 1.1 of the .NET framework and not in 1.0, you have to upgrade your .NET CLR to 1.1. (note: I came across this gem while searching for 'web services versioning' and literally laughed out loud.) the CLR approach might avoid "DLL Hell" but is that really of huge benefit? I know one of the things I like about Lx (and php, to a lesser extent) is being able to upgrade only certain components to enable new features, rather than having to buy/download/upgrade to the latest version of dozens of packages all at once that may or may not break my other code relying on them.

but back to the world of Web Services (again remembering SOA could actually be achieved without Web Services, even with completely proprietary .NET system architecture)...

UDDI is the (open-standards-based, non-proprietary) means to address the versioning and deployment of web services, and there are already a good deal of introductory methods for the practice. so we find that UDDI is the out-of-the-box standard for versioning web services. perhaps if Microsoft isn't on the ball with it, there's a problem with Microsoft. it typically happens that they will try to create an out-of-the-box tool instead of a standard - perhaps a nice little .NET Deployment Wizard that will be released in late 20X6.

since Fergesun makes only passing mention of the reliability "problem" with web services (again, not equivalent to SOA), I'll only make this link as my passing rebuttal.

Finally, I will close, mirror of Fergesun, with the eternal benefits of all new software technologies - revolutionary new productivity, nearly-infinite opportunity, vast new markets for new products, and perhaps most importantly, independence from proprietary legacy vendors.

I may be giving Derek too hard of a time, because I've not read up on his other posts. but my guess is that this editorial post was meant to kick up controversy and "pick a fight." in that he has succeeded. but in providing real criticism or insightful analysis of SOA's "problems," he has failed - largely because he has only criticized web services, and only web services development from a Microsoft perspective.

Greetings

How nice to be invited in here. Here's my WS comment for the day:

In the raging war between microsoft and massachussets, I hear a lot about XML being an "open enough" standard to provide the interop benefits sought by the commonwealth. This, in my opinion, is a case of trying to buzzword a problem away. So any WS afficionados who are all excited about MS Office XML being the default format for Office 12/Vista, take note:

(disclaimer: I don't pretend to know nearly as much about this as many others do)

-MS XML can contain binary objects that depend on MS Office and Windows.

Which is a pretty uncomfortable fact, w/r/t the Whole Point of webservices, viz: "to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer" (src). That is to say, if Office really wraps up your doc in well-formed XML, it's great 'cause you'll get some sort of response back from any WS that asks about it.

But if the response is -- more or less -- "There's no telling what's in here", then I don't see the big fat advantage. So before we all celebrate the use of XML in Office 12, maybe look closely at how it is used. In my opinion, it's mostly used to keep trendy.

(Yes, if you haven't figured it out I'm the resident raving anti-microsofty here at WS-Comments. Future posts will be more on-topic, though. I promise.)