 |
Wednesday, June 22, 2005 |
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 |
 |
Wednesday, June 01, 2005 |
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
|
|
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 |
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 |
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
|
|
© Copyright 2006 Nicholas Gall.
|
|
 |
 |
 |
 |
| September 2006 |
| Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
| |
|
|
|
|
1 |
2 |
| 3 |
4 |
5 |
6 |
7 |
8 |
9 |
| 10 |
11 |
12 |
13 |
14 |
15 |
16 |
| 17 |
18 |
19 |
20 |
21 |
22 |
23 |
| 24 |
25 |
26 |
27 |
28 |
29 |
30 |
| Jun Oct |
|
 |
 |
 |
 |
|