June 27, 2007

I, for one, welcome our new iPhone overlords

I'm flying to D.C. this weekend to visit a friend & try to snag an iPhone. I have a U.S. SSN from a few years ago, and a U.S. address -- hopefully it works out.

Roaming in Canada will be a bit pricey, but between my work use of the phone (which pays for a large chunk of the bill) and my existing Rogers phone, it probably won't be too bad.

One thing I note on the recent reviews is that everyone is discussing the missing features & oversights, but few are discussing the reason why all of this is irrelevant, and why the iPhone really does change the game: it's just software, folks. Apple will issue updates regularly -- that will auto-sync whenever you dock the phone with iTunes.

Sure, they can't fix the fact that EDGE is slow (it's not "ancient", and is pretty good, by the way, in Canada, even in rural Ontario areas, and it's a lot faster than GPRS was). But, cut/copy and paste? Instant messaging? MMS? MP3 ringtones? Surely these were triaged and didn't make the cutoff date. Apple will get there....

Posted by stu at 12:29 AM

June 22, 2007


For months, industry analysts have warned about e-mail access, security and whether the voice quality of the iPhone will be up to corporate standards. Gartner analyst Ken Dulaney is finalizing a report describing iPhone concerns, but would not discuss it until its release next week.

"Lots of Gartner clients are asking" about iPhone for business uses, Dulaney said. "They are scared of this device."

courtsey PCWorld

I read this, and I'm afraid of these businesses. Have we lost all sense of reason and fun? I mean, I get that it takes work & thought to support new devices, but that's the job of an IT department.

The press seems to be drumming up drama here, and I'm not sure the point -- is it to see Apple fail in some way? Is it to point out the flaws in corporate IT's stodginess? Or both?

Posted by stu at 04:01 PM

June 21, 2007

it's hot

A BEA blog entry on what I've been up to.

Posted by stu at 08:28 AM

June 13, 2007


I just wanted to say, I really did love the way the Soprano's ended. The whole episode was very reflective of most of the Sopranos -- real life goes on, there are no real book-ends. There is resolution of a sort (the NY war). But Tony & family "goes on, and on, and on, and on...." It reminds me of an episode in Season 3, where Patsy Parisi threatens Gloria with a gun mid-episode, and then ends the episode picking up groceries.

Yes, the cut to black was jarring.
Yes, I thought my cable cut out.
When the credits rolled, I laughed.

But, what a scene -- every trick in the book was created to raise tension, to get the viewer into Tony's state of mind. Everyone entering the diner was a potential hit man. Externally, he was just Tony: "focus on the good times". Inside, he was a knot of paranoia. And so were we.

I felt frustrated, but also relieved.
And then, I thought back, and liked the journey.

The ending works, not because it was a cop out, but because it makes you feel. It celebrates the utter ridiculousness of life, like Meadow's inability to parallel park, the weirdness when surrounded by strangers that keep looking at you, and those moments of clarity that happen in the silliest places, like, oh, when you're in a diner, groovin' to a Journey song.

Don't stop believin', indeed.

Posted by stu at 09:27 AM

June 11, 2007

Web 2.0 on the iPhone

So, some are complaining about Apple's announcement that they'll be exposing iPhone's features to developers via a Web 2.0 interface (whatever that means). I assume it's going to be (ideally) understanding URIs (such as the tel: scheme), media formats like vCard (maybe microformats like hCard and hCal?), and perhaps some JavaScript functions.

I think that while ultimately there should be an ability to release certified OS X apps on the iPhone, this is going to be a very big deal. Seriously, does any other phone really integrate hypermedia into the phone experience? I've always felt this was one of the best features of the BlackBerry, that all of the apps had some level of hyperlinking to the phone. But, the web browser still was a walled garden. Not anymore.

I think the herd is seriously underestimating the flexibility of this approach. They're too busy waiting for their VLC or Skype port, but they're pretty marginal, have been done before, and still are unlikely to offer a mainstream experience (on a mobile device) for quite some time.

It remains to be seen if the iPhone device is as usable and productive as it looks, but if it is, I'm looking forward to seeing some interesting iPhone web apps fairly quickly. This could be the beginning of real convergence.

Posted by stu at 09:32 PM

Business Architecture in a Web

It's often asked what the business implications of a web architecture are. "What impact does REST have on business?", "Isn't this just mechanism?", etc.

My claim: It's about moving from "push" to "pull" approaches for resource consumption and business process design. See John Hagel's viewpoint. Read about Lean.

Posted by stu at 09:57 AM

June 10, 2007

Data-centric architecture

This is also based on a recent post on the Yahoo! SOA mailing list, modified somewhat.

One complaint about RESTful approaches to software architecture is that it's a difficult investment to start looking at a legacy in terms of "Resources". Many transactional interfaces already look like services or components, so a shift to WS-* style SOA tends to be easier to adopt.

I see an large amounts of work undertaken to "SOA enable" one's transactional systems into more business-relevant services, using every manner of infrastructure (BPM, ESB, Data Services, etc.). Usually this is part of a larger initiative (as "SOA for its own sake" tends to be a very hard sell).

The problem is that, in my experience, shifting an IT department's mindset towards SOA tends to require a lot of architectural change. Many transactional interfaces are at the wrong granularity. Or have disjoint, overlapping semantics with other systems that evolved independently, but now require integration. It's mixed as to how an organization may accomplish this:

  1. Some are throwing out their old applications and buying packages like SAP (which want to SOA-your-world). This is often $100m+ of work.
  2. Others are rebuiliding their systems on Java or .NET , perhaps with some best-of-breed packages to fill in some areas. Again, this can may many $m.
  3. Many are just layering service infrastructure on top of the old stuff but doing a big rethink as to how re-route access through the new layer. Fewer $m, but still significant.

I don't think the issue is a lack of desire for investment in new infrastructure and in re-thinking. That's happening with SOA, to some degree. I think the reason for this disconnect is probably more fundamental, and seems to lie with the education and values of IT architects, similar to the eternal pendulum debates of behaviour-centric vs. data-centric design.

Here is my take on the disconnect:

1. REST approaches are data-centric. It isolates the importance of data -- identifiers, provenance, temporal relevance -- and singles them out as some of the most important aspects of a shared information system architecture.

Anyone that has dealt with data quality, data warehousing, etc. knows that this is a huge problem, but is often ignored outside of small circles in the enterprise. Perhaps this is why so much integration is still accomplished through ETL and batch transfer -- they're the ones that pay attention to the semantics of data & integrity of the identifiers ;-)

Roy, in his thesis, even underlines this in Chapter 1, noting that the vast majority of software architecture -- even in the academic community! -- ignores studying the nature of data elements. His conclusion -- "It is impossible to evaluate [a network-based application] architecture without considering data elements at the architectural level."

COM, CORBA, WS-*, MOM, etc. look at the data elements as messages. They are envelopes, like IP. They don't consider data elements beyond this: send whatever you data want, deal with data issues your way.

REST, on the other hand, looks at this explicitly, even covering data stewardship -- ("Cool URI's don't change", and "The naming authority that assigned the resource identifier, making it possible to reference the resource, is responsible for maintaining the semantic validity of the mapping over time.")

The bright side is that these differences don't preclude COM, CORBA, WS-* from adopting constraints that explicitly deal with data services.

2. SOAP Web Services were originally created to be an XML-oriented replacement for COM, CORBA, and RMI/EJB. This is documented history.

They were intended to:

a. simplify integration, and solve the problems of these old approaches -- make them more MOM-like and asynchronous, and less RPC-focused.

b. also allow richer data structures through XML (vs. the old approaches that required custom marshalling or proprietary serialization).

c. give a chance for Microsoft to get "back in the game" of enterprise systems, as J2EE had pretty muched eclipsed DNA. They would do this by eliminating the competition over programming models & core protocols - changing their old Microsoft-centric stance.

d. traverse firewalls by piggybacking on HTTP

The focus was clearly on XML as a marshaling format. The hidden assumption seems to be that if we fix the above, the "distributed object nirvana" that we longed for from the COM / CORBA days would take hold. SOA added "governance" to this mix. While SOA governance may deal with data problems in isolated cases, there is little consistent *architectural* treatment of data in these aproaches. It's still a mishmash of CBD, object-orientation, and message architecture.

Some articles to read....
September 1999: Lessons from the Component Wars, an XML Manifesto

April 2001: A Brief History of SOAP

Interesting quotes:

  • "SOAP's original intent was fairly modest: to codify how to send transient XML documents to trigger operations or responses on remote hosts"
  • "Component technology has been the cause of many arguments, disagreements, and debates. This component-induced friction can be traced to two primary factors:

    1. Different organizations and corporations want to be the de facto provider of component infrastructure.
    2. Component technology provides more opportunities for different programming cultures to interact.

    There are many lessons to be learned from examining these two factors closely. In this article, we will examine how component technology has evolved to XML."

(As an interesting aside: Both of these articles are by Microsoft's Don Box, though I think he was at DevelopMentor at the time. I think Pat Helland is one of the premier minds behind SOA. Microsoft is responsible for many, if not most, of the protocols we base WS-* style SOA implementations on. Yet, I find it fascinating that many of the SOA industry analysts, vendors, and some customers seem to treat Microsoft as an almost non-player, since they don't ship an ESB, rarely talk about SOA in the abstract, and don't cater to business consultants. )

Today -- SOAP 1.2 and WS-* have evolved this purpose into a general purpose asynchronous protocol, it really is still a way to create a vendor-independent, interoperable replacement for MOM.

This is not to say there is no value in a better MOM -- just that there might also be a lot of value in a better way to integrate data in a distributed system. Which is why I find RESTful archtiectures exciting.

Posted by stu at 03:17 PM

What are the benefits of WS-* or proprietary services?

This was originally part of a post on the Yahoo! SOA mailing list.

I'm firmly a proponent of RESTful architectures (independent of whether they're over HTTP, or SOAP, or whatever underlying transfer protocol), as I believe they objectively lead to more scalable, interoperable and evolvable information systems.

Of course, nothing's perfect, and the implementations & tooling out there doesn't live up to the theory.

So when are alternatives appropriate? Stefan Tilkov suggests three simple factors:

  1. WS-* is "protocol independent", while REST (in all practical relevance) is tied to HTTP.
  2. The WS-* specs address "enterprise" concerns that REST/HTTP can't handle
  3. It's much easier to expose an existing system that has a "transactional" interface (in the TP monitor sense) via WS-* than via REST, since the latter requires a real architectural change and the former doesn't

I think #1 tends to be somewhat theoretical. I've seen lots of MQ out there, but not a lot of SOAP over MQ, for example. Such an approach is not overly interoperable, though I can see benefits of reusing WS-* infrastructure with proprietary infrastructure when within the bounds of a single vendor's stack, like IBM.

#2 true, but the implicit problem is that the term "enterprise" is sort of like "scalability"... it's often a way to shut down debate without studying the specific concerns. Debates on "Reliability", "Security", and "Transactions" for example, tend to require specialist knowledge and, lacking that, seem to hold a mystical status that cloudens debate when RESTful approaches may have very different views on these topics (even if they are well-founded).

I have a longer discussion & historical perspective on #3, which will be in a subsequent entry.

In the meantime, here's my (incomplete) list of scenarios of when you'd want an alternative to a RESTful protocol....

  • When you just need to remotely access or manipulate an object and want to make it feel like developer's local API as much as possible, without need for data sharing, or evolution. CORBA interfaces on network switches are an example of this. They're fine. SOAP and XML are being applied here too. RESTful services may even use these things.

  • When you're tightly coupled, control all the endpoints, and want distributed transactions. SOAP and XML are being applied here (but WS-AtomicTransaction isn't known to be widely implemented or interoperable yet). Arguably this might be easier than IIOP or TIP, the protocols used by CORBA or COM+. Maybe it'll be more interoperable than XA resource drivers, which tend to be the most common way to integrate these transactions. There's some benefit here.

  • When you want a vendor independent MOM for stateful in-order, reliable, non-idempotent messages, and don't have time or inclination to make your data easily reused, study whether your interactions are safe/idempotent (which obviates the need for dupe detection), or your application doesn't lend itself well to statelessness (which obviates the need for an infrastructure to handle retries & dupes). See WS-ReliableMessaging.

    I think this is the approach that many vendors & enterprise architects are thinking will be the ultimately desirable scenario for WS-*. I'm curious how this will pan out, as I don't see a lot of discussion about the tradeoffs of this approach. It likely will succeed to a reasonable degree, though I don't think it actually helps a lot of the SOA desires for agility. Perhaps this is the area where the WS/REST bridges need to be built.

  • When you need stateful, real-time communication. This is clearly for two-way streamed communication, like voice/video. You probably wouldn't use SOAP for this, either. BitTorrent is an interesting hybrid case, where they use HTTP for signalling and discovery, and the BitTorrent protocol for the actual exchange.

  • High speed pub/sub event notification. While there are plenty of attempts to extend and/or emulate this in HTTP, not many have caught on. Of course, that this generally is the case with SOAP today too, since WS-Eventing isn't really implemented or ratified. So there's still a lot of room for MQ, JMS, TIBCO/RV, etc.

I don't really include security as a benefit of other approaches. RESTful web services can already reuse XML Signatures, XML Encryption, S/MIME, SSL, and allows for username/password, OpenID, Kerberos/SPNEGO, and SAML assertions already. WS-Security is just a wrapper for most of these approaches. Authorization rule engines tend to also be independent of whether something is RESTful (whether they're XACML, or proprietary, etc.) Though, a RESTful multi-party secure conversation protocol might be an interesting development in the future.

update: Just a quick clarification, as Stefan notes, that the three points he made were somewhat taken out of context from the SOA mailing list. He doesn't necessarily believe them to be true, just that they are common viewpoints.

Posted by stu at 03:02 PM