WebServices

posted: 2003-06-11 05:32:37 perma-link, RSS comments feed

I'm dubious yet excited about web services which isn't suprising given my moodiness of the last year. Let's talk about what's exciting about them.

This is a rant in progress, but I wanted to allow feedback while I was tweaking it.

First of all it's a somewhat new technology that is gaining mind share business wide similar to the way that XML has. I've already seen commercials on primetime televison demonstrating how web services will enable my business to have products built and delivered right as the customer signs the check. That's a pretty impressive feat, but more impressive is that they thought that this piece of technology would be something the millions of people watching ABC at 8:30 pm might care about.

Peaking under the hood a little we see that the more popular web services technologies ( of which there are many ) are about letting applications on one box leverage a "service" on another box. The usual mechanisms for this "leveraging" are XML data representations transmited over HTTP. It's an excellent use of existing technologies. And the definition of a "service" is generally a fine grained peice of functionality. The promise of all of this "service leveraging" is that everything becomes loosely coupled and silos of functionailty are broken down and that applciations anywhere in the enterprise can take advantage of other services exposed by other applications elsewhere.

It has all of the makings of the next disruptive technology.

Sweet.

That is if it doesn't tangle itself up in a giant ball of service spaghetti.

So what is it really? Well, like any other technology, it is what you make of it. Instead of a silos, webservices allow you to architect fabrics. A fabric is just what you'd think - a network of interconnected, overlapping, criss-crossing threads. ( Instead of building with legos, it's more like quilting a hyper cube. )

The very nature of web services lends itself to problems with security and scale. Who's using your service? How many people are using it? What do you mean that my service isn't protected by the firewall? If you change your service to suit the app your working on, how many other apps are going to break? Tricky questions that the providers of WS technology are working to answer.

At the last OReily Emerging Tech conference, there were representatives from Sun, IBM, Microsoft, BEA, etc. There was a discussion panel for Web Services vendors where this exchange took place:

BEA's Adam Bosworth:	"First-generation toolkits make tight coupling too easy and attractive."
Microsoft's Dave Stutz:	"Guilty as charged, but with an explanation. Visual Studio .Net aims to energize a broad base of developers. It is doing so, and we [vendors] should all be grateful."

In their view, brittle interfaces would be a good problem because they build markets requiring yet more solutions.

But now that the planet is on this path leading from the silo world of tight integration and platform specific API's into this loosely coupled world of application fabric, what makes WS more than just CORBA with angle brackets? The answer lies in loose coupling - but not the kind that WS folk generally tout. Most WS people are excited about spreading the funtionality across machines, and not havin to distribute code modules in order to re-use them.

This really only gains you the ability to deploy your tightly integrated applications across a bunch of loosely coupled wires. It is still tightly integrated in terms of the domino effect of changes. Furthermore, unless it is approached very carefully it does not significantly reduce the scaling problems either.

What I find fascinating about web services is the temporal de-coupling of functionality.

With this approach, two systems A and B send/receive instructions/data to each other over a "reliable" messaging infrastructure in which there is no assumption that any request will receive an instantaneous answer. The reliable messaging infrastructure guarantees you that an answer to any request will be provided - but does not tell you when.

It has been my experience that if you build systems this way, true decoupling can result. By true decoupling I mean the ability to hot-swap any component piece without impacting the whole app.

And once you embrace a design and integration style that is decoupled in this manner, you begin to focus more on the data that flows between processes - not on the processes themselves.

Now we're modelling data in an application neutral fashion and getting that data flowing around our systems.

Web services hopes to satisfy the second half. What we are talking about here is essentially the data-flow based approach to application design and integration advocated by many in the seventies. Less cynically, it can be argued that we did not have XML in the seventies to describe the data in dataflows. We also did not have ubiquitous interconnectivity. Now that we have both we can re-address these concepts. It seems everything old is new again, and the one thing that is still certain is that good data modeling is going to be key. Both in the future for backing up web services style applications and right now for apps that may need to integrate with fast forward at some point.

---

---

gg said on 2003-06-15 10:52:50:
delete me 2

---

g said on 2003-06-15 10:16:11:
delete me 1

---

glenn1you0 said on 2003-06-13 21:53:04:
All sorts of companies could be threatened: Oracle - what if SOAP becomes the standard way of fetching data from disparate sources? The applications no longer care what is behind the service. It could be Oracle, MySQL, flat files, in-ram information. Instead of one database, it could be many less expensive ones. Sun - standardized web services with RMI, but tied the standards to Java. Web Services make the language behind the service irrellivent. Microsoft - the standard interfaces allow the services to be swapped out for another implimentation without changing the client. If WS become pervasive in MS software, then parts of your MS architecture can be swapped out for non MS technology. For instance, if the communcations between Outlook and Exchange were soap, the openSource community would have built Exchange compatibility into Revolution or Mozilla Mail already. And they would have implimented mail servers that Outlook would connect to for the same level of functionilty that Exchange gives it already. They're chomping at the bit as you read this. So who stands to gain? The same folk, but so long as the interfaces remain open and standard ( which is what open standards are for , right? ), the competition becomes more head-to-head. Microsoft - since the consumers of webservices - network client software - are insulated from the remote end's implimentation, all of their existing Visual basic users can do web services, all of their existing Visual C++ developers can use web services, both of their existing C# developers can use webservices. Open Source - again, the same benefits as MS, but more on the server side - all of the existing Perl, Python, C++, Ruby, PHP, TCL developers can impliment and use web services. The most popular aspect of WS is that the developer can use whatever tools s/he is most familiar with. When it comes to building individual services, you'll have language choices and platform choices. And peeople will probably fall along these lines: - Sun/Oracle when you've got a budget and it has to scale through big hardware. - Linux/MySQL when you're shy on cash and can scale by using multiple cheap boxes. - Windows/SQLServer when you've got money, but aren't so worried about scale. Microsoft is excited because it leverages alll of their developers, where it used to be that you used Java for network centric computing ( Remember Sun's old slogan: "The network IS the computer"? ). Sun/Oracle are excited because anywhere a poorly implimented app built on MS technology begins to falter, you can buy big iron from them and plug-n-play from MS to them. OSS is excited because they can take the place of either system and play in either direction and continue building traction in the enterprise. So there are the usual mix of risks and rewards, that is until MS starts implimenting their own patent-protected extentions to SOAP and try to sue anyone who tries to be compatible. And then there are the risks I outlined above to the Enterprises that use web services architectures - how do you manage a project/product that relies on so many different parts, written in different languages, on different platforms? What do you do when one of those pieces change, and all sorts of additional projects/products cease to function properly?

---

Benz said on 2003-06-13 06:49:23:
First, why are you up at 5:30 a.m. thinking these thoughts? Take a Tylenol PM, dude. Second, this all sounds great. But it's still sort of abstract to a money-grubbing business-focused whore like me. How does it save me money or make my business more efficient? Concrete example? One of the problems I generally have with these types of things is that they offer all kinds of vague promises (smiling guys in three-piece suits, happy workers, pleased customers) but when push comes to shove, you end up in a Vietnam of implementation. I'm assuming when you cite web services as a potentially disruptive technology, it's disrupting the monolithic tech staffs that many organizations have to support? What other businesses are in the way of this snowplow? Who stands to get disrupted? I want to know which stocks to short. Har.

Comments

Post a comment

Your name:

Comment: