The IT Strategy Letter
Doug Kaye, RDS Strategies LLC
August 18, 2003
(Subscribe)
|
|
|
Sapir and MSDN: Web Services By and For Desktop Users. Two interesting articles appeared last Monday, both addressing the impact of web services on end users. In his essay, How Infopath Works, Phil Wainewright summarized and analyzed an MSDN article describing this new add-on to Office 2003. It allows users to create forms that have an XML or web-services back end. It does indeed look interesting. (I haven't played with it yet myself.) Coincidentally, over on Tech Republic, Jonathon Sapir wrote Will Web services and SOAs change the development world? in which he described a scenario in which "non-IT employees can take responsibility for computerizing their part of the business." Tech Republic has coined the phrase "personal services builder (PSB)" to refer to this supposed new class of tool. Unfortunately, I think Sapir's world isn't the real one. Unlike the InfoPath concept, he envisions users actually developing services to be consumed by others. (As I understand it, InfoPath can be used to create structured XML data but doesn't actually build web services.) I'm highly skeptical of Sapir's vision of the future for any but the most trivial functions. Packages like InfoPath and Excel will become terrific tools for consuming and combining web services to create complex aggregated applications. And there's no doubt that your typical power user will be able to do this with ease. But it's still going to take the IT professionals to create those services that the power users will use. Have you ever seen complex spreadsheets written by non-programmers? They're typically inefficient, impossible to comprehend, and (most important) quite brittle. They don't contain the kind of code you'd want behind a web service available to an entire organization. I know, I know...if web services are loosely coupled, we shouldn't care what's behind the curtain. Well, we don't care what it is, but we do care that it's of high quality, scalable, and reliable. And user-created web services, for the most part, just aren't going to have those attributes no matter how much help they get from Microsoft's desktop apps. Spreadsheets and other personal-productivity tools have been a
terrific boon to individual and team-level data processing. They
allow users to develop many of the applications that might never
be addressed by the formal IT-development process. But one reason
for their success is that these personal projects were just that:
suitable for consumption only by the author and a few close associates.
I've got some terrific Excel spreadsheets that do all sorts of cool
things, but they're not ready for prime time. I would never release
them to others. The deployment of web services developed by amateurs
should be limited in the same way, and I doubt you're going to see
too many such web services listed, for example, in a company's UDDI
directory. |
|
|
|
Gartner: Event-Driven Architectures. This is an excellent web seminar by Yefin Natis and Roy Schulte of Gartner in which they explain the concepts of asynchronous event-driven services. In his review of the presentation, Edwin Khodabakchian at Collaxa pointed out that the Gartner distinction between SOA and EDA may not be correct. Indeed, Gartner seems to have decided that the phrase "service-oriented architecture" only applies to the request/response RPC-style synchronous MEP (message-exchange pattern). Most experts consider all MEPs, whether sync or async, to be under the SOA umbrella. But it's a detail, and the seminar is valuable nonetheless. The total presentation runs an hour, but if you don't need the
introduction to the basics of SOAs, skip to 27:00 and just listen
to Schulte's half. (Make sure you get the right presentation. There
may be more than one on the page.) That's where the event-driven
elements are presented. I particularly liked Schulte's point that
while synchronous systems involve a single requestor and responder,
an event-driven async system publishes events which have a potentially
unlimited number of subscribers, as in JMS. As he says, the flow
is determined by the recipient, not the originator. |
|
|
|
Collaxa:
An Introduction to BPEL. I just came across this elegant
introduction to BPEL and the concepts of orchestration. I say elegant
because it's short and sweet. The first slide tells most of the
story: a mix of synchronous and asynchonous services, exception
handling, and parallel async processes. If you understand these
three issues, you're most of the way there. [Source: Collaxa] I hope to record and IT Conversation about BPEL and orchestration with Edwin Khodabakchian, Collaxa's CEO, in the next week or so. Stay tuned. |
|
|
|
Loosely Coupled--Now Available as a PDF (at a 63% Discount)
As an alternative to the hardcopy edition, you can now download my latest book in PDF format at a substantial discount using PayPal or BitPass. From the time you purchase the eBook version, you have 7 days during which you can download the content up to 10 times. The PDF files can be printed, but the text cannot be copied or modified. Amazon.com Review of the Week:
|
"This
book provides an excellent explanation of why companies should
be looking at Web services. It approaches the topic with an
honest and straightforward description of the problem space
Web services are targeted to address and the characteristics/short
comings of those technologies as they exist today and as they
are expected to evolve. Perfect for IT decision makers who
are evaluating how/where Web services fit in their corporate
IT strategy."|
Kotok:
Review of Loosely Coupled. Alan is editor of ebXML
Forum. He liked the book, although he takes exception with my
criticisms of EDI and my thoughts on SLAs. The folks at Webservices.org
were kind enough to publish my comments on Alan's review. |
|
|
|
Sun:
ASN.1 Encoding for Fast Web Services. A group at Sun published
this article proposing a scheme for substantially improving the
efficiency of XML-based web services using Abstract Syntax Notation,
used extensively in the telecommunications industry. The results
are encouraging (4x to 10x), and they're hoping to get it approved
by a standards body. [Source: Don
Park who isn't thrilled with the idea. "This is one case where
common sense differs from reality," he wrote.] |
|
|
|
Purdy:
Loosely Coupled Web Services. Software legend-to-be Doug
Purdy explains how to create .NET web services that are version-resilient
using the Open Content Model. Specifically, Doug shows how to write
clients that can handle unknown versions without the need to recompile.
It's a real-world example of loose coupling. [32mb WMV file] Radovan Janecek, VP engineering at Systinet, has a new blog that will focus on web services. (Welcome, Radovan!) He points out that the technique Purdy demonstrates to obtain version resiliency depends on dumping structured data into an unstructured and untyped string. He's right: It's a bit of a quick-and-dirty gimmick. Still, I like the video because it demonstrates the problem if not the most elegant solution. |
|
|
|
Potts:
WS-Manageability is Coming. "On the same day that HP formally
proposed a Web services management plan to standards body OASIS
[last] week, IBM and Computer Associates announced a schema that
deals with similar issues of shepherding software services to interoperable
functionality...Mark Potts [CTO of Talking Blocks downplayed the
conflict between the two specifications] saying that the fact that
the two specs are being released to one technical committee within
one standards group will only accelerate adoption of a management
specification." [Source: Internetnews.com] Mark, too, is expected to join me for another IT Conversation. |
|
|
|
Bosworth:
The Blog. The CTO of BEA writes, "I've been planning to
start a weblog for quite some time but, unusually for me, I've suffered
from writers block at the thought that this would be so public.
Well it is time to tough it out." I'm looking forward to his insights. |
|
|
|
Perez:
Principles of Loosely Coupled APIs. Carlos Perez has published
an updated version of his comparison
of the attributes of loose and tight coupling, which in turn
was based on one
I published last November. |
|
|
|
Builder.com: Web-Services Quiz Results. Check out the results of this 10-question quiz at Builder.com. About 375 total responders. Biggest surprise, "#5: What organization developed the SOAP specification?"
Erroneous answer (picking nits), "#4: What does the acronym SOAP stand for?" In the latest specification it's just SOAP, since the protocol is neither simple nor for object access.
|
|
|
|
Kaye: Liberty Won't Amount to Much. Oh, boy. I can hear the complaints coming in already. Luc Hatlestad of VAR Business wrote this good article for ChannelWEB, giving some screen time to those of us who are less than enamored with the concept of federated identity for consumers. My opinions are the most negative in the article, which includes comments from such notables as Daniel Blum of Burton Group, Ed Giorgio at Booz Allen Hamilton, Liberty Alliance president Michael Barrett, and Eric Norlin of PingID. I admit that my final quote is brash, but give it a few years to see if I'm right or not.
Clarification: The example I published in May is of anonymous federated identity--quite different from the Liberty Alliance concept.
|
|
|
|
Baker: REST vs. Loose Coupling. Two weeks ago I wondered why Mark Baker thought web services were "object specific." Now I see that I took his comments out of the context of his on-going Tech Curmudgeon role. I thought he was referring to web services as being necessarily an OO technology. In fact, Mark was referring to the REST debate.
It may not be obvious from most of my articles and postings, which deal with what Anne Thomas Manes refers to as "advanced" web services, but I'm actually a REST fan myself. REST's simplicity is a great solution for many--maybe even most--XML communications problems. REST's standardized (as Mark calls it, object-generic) interface simplifies the design of many systems, but not all of them. I continue to believe that dynamic documents, such as those which evolve during a complex business process, are best communicated through non-REST style interfaces.
With regard to REST and business-process automation, Mark then wrote, "I'd say that is what REST does best. A URI is just an identifier. I could use one to identify some instance of a business process, and at any point, anybody with that URI could invoke GET to retrieve a document which represented the state of the process. As the process makes progress (in any direction 8-), subsequent GETs will return different results representing the current state." This implies that the document is associated with (tightly coupled to) a fixed location as specified in the URI. But a fully self-contained document can (perhaps even should) be loosely coupled as far as location. It can be sent from one service endpoint to another and another through a reliable asynchronous messaging infrastructure. The state of the business process continues to be stored within the document, but both the document and the state information are now freed from the requirement to be stored at some globally accessible location specified by a URI. The REST requirement that the URI always provides access to the current document and state of the business process is, in fact, a tightly coupled and therefore constraining concept. (Qualification: As I wrote earlier, it works great for many applications.) Furthermore, REST requires the design and construction of highly reliable, redundant, and scalable systems. If a document is to be retrieveable via an HTTP GET, the infrastructure must be synchronous and availability must be high. A loosely coupled architecture in which documents are moved through an asynchronous messaging system allows all the endpoints to be built using lower-cost and less redundant configurations. You can't send email to me using an HTTP GET or POST to my desktop
PC because it may be turned off. If my PC had to be up and running
all the time in order that email to me wasn't lost, my PC would
cost a whole lot more money to purchase and operate. Mark and I were scheduled to record an IT Conversation on this and related topics on August 14 at 6:30pm Easter time -- two hours after he lost his power in Ottawa like everyone else in the northeast. We'll reschedule and have the interview online shortly. |
|
|
|
Cooper: Standards Stupidities and Tech's Future. On CNet's news.com, Charles Cooper complains about the bickering between web-services standards groups. "Unless the sides bury the hatchet, the risk is that opposing Web standards will evolve. That would further slow down business use because of concerns over interoperability." He compares this to the food fight (thanks, Rich Miller) going on in the RSS world. It's true that the WS specs are coming about in a manner we're not used to. This model of specs-before-implementations is new in the world of public specifications, but it's certainly common within organizations and IT departments. We're witnessing the debates in public, and they're between large companies rather than individuals. We're seeing how the sausage is made, not just sampling the results. Time will tell whether this is a good way to arrive at standards as opposed to the traditional method of one party submitting a specification for a functioning technology to a standards body. I don't see any evidence that it's a slower process than the old way. Indeed, if you step back from the day-to-day, blow-by-blow press coverage, you'll see how far the web-services specifications have come in a short period of time. If we only saw the resulting sausage--not the inner workings of the sausage factory--I think we'd be impressed with the speed. The real question is what will we have when the dust settles? Will the resulting specifications--developed without benefit of real-world large-scale testing--be as good and long-lived as those developed more slowly using the traditional design-implement-deploy-test-submit model? That's the real unanswered question. As to the complaint (not made by Cooper, but certainly in expressed by others)
that there are too many WS specifications, this, too, will have
to be judged by the test of time. Unlike the monolithic specifications
of the past, the WS standards bite off smaller chunks of the problem
at one time. They're "composable" (able to be combined) in the same
way as web services themselves. Is this modularity of specifications
as chaotic as it appears? I think not. We're just releasing the
book serially, chapter-by-chapter, instead of all at once. |
|
|
|
IT Conversations are recorded (audio) interviews with the gurus of information technology. They're a new production of RDS Strategies LLC, and we hope you'll enjoy them. Stream IT Conversations to your desktop or laptop, or download them into your MP3 player and listen to them while you drive, workout, or sit on the beach with that piña colada. These IT Conversations are new since the last edition of the IT Strategy Letter: |
|
|
|
[stream--download--discuss,
5.1 mb, 22 minutes, recorded 7/30/03] |
|
|
|
|
|
|
|
Apache vs. IIS? It's always fun to find experts who vehemently disagree, particularly when their "authoritative" data supports their opposing views. You know: lies, damn lies, and statistics. Port 80 Software released a survey
of "the Top 1000 Corporations'" web servers. It claimed that Microsoft's
IIS is in use on at least 3x more sites than Apache. On the other
hand, Netcraft's recent results
are just the opposite, showing that Apache deployment exceeds that
of IIS by nearly 3x when testing 42,807,275 sites worldwide. [Source:
Robert
Scoble and Sudhakar
Sadasivuni] |
|
|
|
Gartner
Ignored: Fortune 1000 Adopt Linux. "As far as their Internet
presence goes, big companies are
doing the exact opposite [of Gartner's 'go-slow' approach to
Linux]; over 100 enterprise sites run by probably the very same
Fortune 1000 and global near equivalent companies that received
the SCO letter have switched to Linux since May, including Schwab.com.
[Source: Email from Mike Prettejohn of Netcraft
in Tim O'Reilly's weblog.] |
|
|
|
Kaye:
When Your Own Host Goes Down. "We all need to think about
what might happen if our web-hosting vendors suddenly go out of
business." -- My July '03 column for The Web Host Industry Review.
|
|
|
|
Presentations, Conferences, and Webcasts
|
The IT Strategy Letter is published weekly by RDS Strategies LLC. Much -- but not all -- of the content is published earlier in Doug Kaye's weblogs.
| Options: |
Subscribe |
This newsletter is governed by a Creative Commons License.
|
|
|||||||||
|
