Wednesday, June 22, 2005

Cisco launches Application-Oriented Networking. Yesterday, Cisco finally announced AON (Application-Oriented Networking), which is basically the ability to process Web services in a Cisco router. I hope this will wake up the SOA/WS-* world to the fact that for Web services to be anywhere near as big a deal as we are all claiming, then it had better be understood as a new application-level network based the SOAP envelope. Web services is not an RPC, its not a bus (not even an ESB)--its a fully routable SOAP network with SOAP intermediaries handling both business as well as technical functions. Let me also remind everyone that AON also stands for Aspect-Oriented Networking. As I've mentioned before in my blog (see Endpoint services vs. protocol services and Aspect-oriented Networking), the SOAP header processing model enables SOAP features that are effectively aspects. Let me point out some others who are making the connection: Carlos Perez (twice),  Jason Brome, Michael Curry, and Loosely Coupled (sort of). And my favorite reference is this paper, Identical Principles, Higher Layers: Modeling Web Services as Protocol Stack, which I discussed in a previous entry. 7:55:03 AM

Thursday, June 02, 2005

A SOA for Shipping - The 20-Ton Packet. One of my favorite example of Service-Oriented Architecture outside of IT is intermodal containerized shipping. So I can't believe that I haven't blogged about the great Wired magazine article, The 20-Ton Packet, that makes the same analogy between the Internet and container shipping that I do. My analogy goes somewhat deeper into the concept of spanning layer, etc., but the article is great, nonetheless. 5:40:29 AM

Wednesday, June 01, 2005

200 SERVICES! That's great - but how many clients? Here's another Jeff Schneider with another great post about service reuse. Here's a highlight: Service Architects love to brag about the number of services - and I let them. Actually, I encourage them to brag. However, I'm quick to challenge these same people with a very simple question: "200 SERVICES! That's great - but how many clients???" This simple question usually makes the most pompous architect fall to their knees in shame. Of course, this then begs the age old question of how to design services that are highly reusable, which leads to discussions of REST ("The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components") and spanning layers, and the really important architectural issues of SOA. 3:36:48 AM

WS-PaintJob vs. Service Network Architecture. Jeff Schneider at Momentum has a great post about reuse, REACH, and Web services. I'll just give you the punch line: WS-PaintJobs are an easy way to black box systems and increase reach. However, the total number of protocol permutations between any given client and any given service grows exponentially with the size of the service network. This leads to the realization that a protocol mediation strategy is not only useful but mandatory. I just love it when I see people highlighting the need for SOAP intermediaries. Web services is a application NETWORK architecture (or if you like, a Service Network Architecture), not an application POINT-TO-POINT architecture. One other thing I'll point out while I'm on my SOAPbox, SOA is NOT about application integration. Wha? SOA is about designing application protocols that are composable. More on this later. 2:48:37 AM

Monday, March 28, 2005

SOA insight: interoperability enables evolvability. As I mentioning in a previous post, I've been doing a lot of deep thinking about Service-Oriented Architecture recently. Over the past couple of years, I've been relentlessly positioning SOA as essentially a set of architectural principles for interoperability. One of the most important interoperability principles is the internetwork principle, which SOA inherited from the Internet: an interoperable network must be designed as a network of (heterogeneous) networks. But in working with organizations implementing SOA (and its preferred SO- technology, Web services), I've noticed that while they achieved dramatic improvements in basic interoperability, as advertised, they failed to achieve dramatic improvements in extensibility. This is ironic, given the central importance of XML, the eXtensible Markup Language, in SO- technologies. So I've spent the last six months really thinking hard about extensibility specifically and evolvability generally (or course I'm always thinking about evolvability). I've come up with what I think is a pretty profound insight: interoperability enables evolvability. In fact, to push the point, I'd argue that they are two sides of the same coin. Both are very slippery terms, so let's get specific. Interoperability deals with how different systems interact to form a unified system. Often, the concept is centered on the interaction between offerings from two or more different vendors. For example, if modems from several vendors can interact to communicate, we say they are interoperable. Interoperability is enabled by a common protocol implemented by multiple vendors. But now think about a product from a single vendor as it evolves from version to version. If the versions need to interact (e.g., communicate directly by some protocol or indirectly by sharing files), then we have what is commonly know as a compatibility issue (specifically forward and backward compatibility). The crux of my insight is that compatibility and interoperability are merely different aspects of fundamentally the same concept: interaction. Interoperability is focused on the interaction among vendors' products implementing a specific protocol version, while compatibility is focused on the interaction among one vendor's products implementing different protocol versions (which includes file or document versions). But in both cases we are really dealing with variations (versions) of a common protocol. In both cases, a vendor is modifying its implementation of a protocol to add new behavior, remove old behavior, or change current behavior. If products implementing different versions of a protocol can successfully interact then they are said to be interoperable, when the products are from different vendors, or compatible if the products are from one vendor. But despite the different labels, it's the same concept underlying them. To put it succinctly: Compatibility is simply interoperability between old, current, and new versions. Accordingly, the better an SOA enables interoperability, the better it should enable compatibility. Of course, the concept of a spanning layer (the narrow waist of the hourglass) is key to compatibility as well. If a spanning layer can be used to unify heterogeneous resources in the bottom of the hourglass, such resources can be different because they are from different vendors or because they are different versions from one vendor. Viewed this way, a rolling upgrade (whose formal definition I cannot seem to find on the web) is simply a federation across old, current, and new versions--in principle no different from a federation across systems from different vendors. I'll have a lot more to say about interoperability and compatibility; but for now, just think about it. 11:34:11 PM

Saturday, November 13, 2004

The network lasts longer than the computer. Just skimmed the recently released Architecture of the World Wide Web, First Edition, which is now a Proposed Recommendation. It is a lot more complex and opaque than the first version, published a little over two years ago. It was the first version that inspired my definition of Service-Oriented Architecture, which I repeat here: An SOA is a dynamic, modular, general purpose, extensible, federated interoperability architecture that defines all processes as services delegated to service providers via generic envelope-based service interfaces. Such generic interfaces describe only the interactions between service providers and service consumers and solely in terms of extensible identifiers, formats, and protocols (IFaPs). Such generic service interfaces are intended to be dynamically bound to a diverse array of specific concrete service transport technologies and endpoint service provider technologies that are both federated by envelope-processing service intermediaries. [emphasis added] Here is the original definition of the WWW Architecture from the first version: The World Wide Web (or, Web) is a networked information system consisting of agents (programs acting on behalf of another person, entity, or process) that exchange information. This architecture consists of: 1. Identifiers. A single specification to identify objects in the system: the Uniform Resource Identifier (URI) [RFC2396]. 2. Formats. A nonexclusive set of data format specifications designed for interchange between agents in the system. This includes several data formats used in isolation or in combination (e.g., XHTML, CSS, PNG, XLink, RDF, SMIL animation), as well as technologies for designing new data formats (XML, XML Namespaces). 3. Protocols. A small and nonexclusive set of protocol specifications for interchanging information between agents, including HTTP [RFC2616], SMTP, and others. Several of these protocols share a reliance on the Internet Media Type (or, "MIME") the metadata/packaging system [RFC2046]. The current "definition" is not nearly so definitive, especially concerning IFaPs: The World Wide Web (WWW, or simply Web) is an information space in which the items of interest, referred to as resources, are identified by global identifiers called Uniform Resource Identifiers (URI). Examples such as the following travel scenario are used throughout this document to illustrate typical behavior of Web agents... This scenario illustrates the three architectural bases of the Web that are discussed in this document: 1. Identification (§2). URIs are used to identify resources. In this travel scenario, the resource is a periodically updated report on the weather in Oaxaca, and the URI is “http://weather.example.com/oaxaca”. 2. Interaction (§3). Web agents communicate using standardized protocols that enable interaction through the exchange of messages which adhere to a defined syntax and semantics. By entering a URI into a retrieval dialog or selecting a hypertext link, Nadia tells her browser to perform a retrieval action for the resource identified by the URI. In this example, the browser sends an HTTP GET request (part of the HTTP protocol) to the server at "weather.example.com", via TCP/IP port 80, and the server sends back a message containing what it determines to be a representation of the resource as of the time that representation was generated. Note that this example is specific to hypertext browsing of information—other kinds of interaction are possible, both within browsers and through the use of other types of Web agent; our example is intended to illustrate one common interaction, not define the range of possible interactions or limit the ways in which agents might use the Web. 3. Formats (§4). Most protocols used for representation retrieval and/or submission make use of a sequence of one or more messages, which taken together contain a payload of representation data and metadata, to transfer the representation between agents. The choice of interaction protocol places limits on the formats of representation data and metadata that can be transmitted. HTTP, for example, typically transmits a single octet stream plus metadata, and uses the "Content-Type" and "Content-Encoding" header fields to further identify the format of the representation. In this scenario, the representation transferred is in XHTML, as identified by the "Content-type" HTTP header field containing the registered Internet media type name, "application/xhtml+xml". That Internet media type name indicates that the representation data can be processed according to the XHTML specification. As you can see, protocol was replaced by interaction, which is fine. But the IFaP point that was so clearly made in the first version is now relegated to a comment at the end of the Intro section: In the remainder of this document, we highlight important architectural points regarding Web identifiers, protocols, and formats. We also discuss some important general architectural principles (§5) and how they apply to the Web. [emphasis added] However, the latest draft absolutely nails an essential point about the longevity of network IFaP architectures vs. software architectures, that I've been making for quite a while: 5.4. Protocol-based Interoperability The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the syntax, semantics, and sequencing constraints of the messages interchanged. Protocols designed to be resilient in the face of widely varying environments have helped the Web scale and have facilitated communication across multiple trust boundaries. Traditional application programming interfaces (APIs) do not always take these constraints into account, nor should they be required to. One effect of protocol-based design is that the technology shared among agents often lasts longer than the agents themselves. [emphasis added] Hence, the title of this post: The network lasts longer than the computer. You can be sure I'll be quoting §5.4 and my pithier version quite a bit from here on. I'll probably have further comments when I've read the draft in detail. 12:01:13 AM