Previously I defined and redefined some terms to be used when discussing networked systems. With feedback from Sam Ruby, Josh Haberman (in the comments), and Steve Jones, plus smoe more thought on my part, I would like to present a more refined version of the same. With this post I’d like to introduce some new terms and revisit some old terms, all arranged in a taxonomical structure from most to least general. Note, the definitions given here will differ in places from those given earlier and from some defintions in general use.
Why bother? Principally because the terms in current use are heavily overloaded, especially SOA, which has at least three distinct definitions depending on who you ask. It’s my hope that some agreed upon terminology will help keep people from talking past each other and to better crystalize our thinking on the subject.
This taxonomy only addresses network programming models that are to be used for general-purpose systems. It does not care about anything below layer 7 of the OSI network model and it does not care abouut dedicated network protocols such as LDAP or SQL*Net.
At the top of the stack there is network-centric computing (NCC). NCC is the generally held belief by all interested parties: developers, architects, business analysts, and the business itslef, that exposing functionality directly on the network in a standard and interoperable manner is superior to building application silos. NCC is completely technology independent; it is an approach to systems design, a mind set. Why not just use the existing term distributed computing? Mainly because that term includes extremely tightly bound systems, including distributed systems that are in fact a single system that happens to reside on multiple machines; such as Oracle RAC, or systems that parralellize processing, such as SETI@home.
Next we have NCC designs that take into account the vagaries of the network. These are termed netwok-oriented computing (NOC) designs. NOC systems have incorporated into their design the fact that networks are not reliable, do not have zero latency, etc. In contrast, there are NCC designs that attempt to abstract the network away, such as system exhibits a network-independent computing (NIC) design. Such a design attempts to ease the burden on the developer by modelling remote systems as if they were local.
Either model can be further refined by applying an architectural style. “An architectural style is a coordinated set of architectural constraints that has been given a name for ease of reference.1” In other words, by restricting the universe of possible design approaches an architectural style becomes a way of talking about architectural designs. An architecural design, then, is the blueprint of a running system. And an architecture is the system itself. Typically, as I do here, the latter two terms are conflated so that an architecure is an architectural design. By loose analogy, Art Deco is an architectural style, the plans for the Chrysler Building are an architecural design, and the Chrysler Building itself is an architecture.
The most commonly applied architecural style used in NOC systems is Representational State Transfer (REST). REST is a style that has the resource as it’s key abstraction, where a resource is anything important enough to name. A resource has state that changes over time, and clients interact with the resource via a uniform interface. Critically, resources also point to other related or interesting resources. REST as an architecural style is one step removed from an architecture. One possible implementation of the REST style is the resource-oriented architecture (ROA). ROA is the set of best practices encouraging the principled use of HTTP to create RESTful systems.
As regards NIC designs (e.g. CORBA, DCOM, and WS-*) there is no identified architecural style. Such architectures have evolved over time to address the needs of their creators and users, and later systems are typically modeled after earlier systems. Even so, it is possible to infer certain fine-grained styles inherent in these architecures, such as distributed objects or client server. One thing such systems have in common is the promotion of the interface as the key abstraction, where the interface describes a collection of non-unifrom operations/methods exposed by a service. Collectively, we can refer to these systems as having a service-oriented architecture (SOA).
In my earlier post I claimed that while governance and business process analysis are selfevidently important, that SOA (and ROA) did not exhibit sufficient uniqueness from traitional application design and development to warrant specialized versions of these. I’m backing off that stance. After all, if devolving a network-accessible application into its constituent components can justify not one but six distinct concepts, then certainly the same is true for governance and business analysis. In addition, NCC is indeed different enough that it requires a level and style of governance that needs to be clearly spelled out and executed. Ditto business analysis. I firmly reject, however, the idea that governance and/or analysis equal architecture and that the technology is not important.
As pertains to governance, ROA and SOA are different enough from each other that the policies and processes that govern them should also be distinct. Hence we’ll give them the simple terms ROA governance and SOA governance. But while the governance processes will be different, the governance needs will often be the same. For instance, either architecture could benefit from a directory. In today’s SOA environments that typically means UDDI. While in a ROA environment it is likely a Web page or simply the result of a search. (Or vice-versa.) Therefore, the common governance abstractions (directories, repositories, documentation, etc.) are given the term network-centric governance.
Regarding business process analysis, I don’t think that ROA and SOA warrant specialized techniques (but I’m willing to be convinced otherwise), thus we have simply networked business process analysis.
Summarizing the above taxonomically gives us:
– Network-centric computing (NCC)
—– Network-oriented computing (NOC)
—–Network-independent computing (NIC)
– Network-centric governance
—– SOA governance
—– ROA governance
– Networked business process analysis
(I would have used nested unordered lists, but WordPress keeps horking that up.)
To use these terms in discussion we might have the following:An enterprise that recognizes that application silos are to be avoided and exposes functionality directly on the network for general consumption in a standardized and interoperable manner is undertaking a network-centric computing initiative (an NCC initiative). They may choose to acknowledge that the network imposes certain architectural constraints on this initiative and thus choose a network-oriented computing approach. This would be especially likely whenever crossing network boundaries, but is considered by some to be a good approach to most NCC designs. Alternately, they may choose to abstract the network away by using a network-independent computing approach. This is especially likely when the clients and services are on a single, well managed, local area network.