Skip to content

Towards a better network programming taxonomy

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)
——– REST
———– ROA
—–Network-independent computing (NIC)
——– SOA
– 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.

{ 22 } Comments

  1. bex | October 9, 2007 at 9:28 am | Permalink

    Why isn’t SOA considered network oriented? Only a poorly written SOA tries to pretend that the network doesn’t exist and everything is local. EJBs tried that crap many times, and the backlash is a huge reason why EJB 3.0 supports POJOs.

    Why are CORBA, DCOM, and EJBs considered SOAs? Their primary abstraction is an OBJECT, not a service. You can do SOA/ROA with any of those losers, but its unnatural.

  2. Pete | October 9, 2007 at 10:04 am | Permalink

    bex: Remember, I’m redefining some existing terms here. In this case, I’ve given SOA a purely technical meaning, and it refers to any NCC design that promotes a service interface of non-uniform methods as its prime abstraction. This is the case with WS-*, DCOM, CORBA, and RMI (of which EJBs are the component model). Doubtless, when anyone is using these technologies they are fully aware of the network. However, these technologies are not in and of themselves resilient in the face of an unreliable, highly latent, ever evolving, independently managed network. Brute force can overcome some of these limitations (so too can alternate programming models), but the limitation is there.

    As to why I consider SOAP, CORBA, DCOM (and RMI/EJB, though I never referenced those) service-oriented when most would consider them distributed object oriented? Mainly to continue to leverage the SOA term. However, what is an object other than the encapsulation of attributes and functionality. Expose that object on the network and you have a collection of operations, where the parameter lists and return types morph into messages. But if the industry had long ago latched onto distributed object-oriented architecture in reference to SOAP (and remember the ‘O’ use to stand for object), I would have used that term. In all cases, though, from the client developer’s perspective, we are given a service/object description of some sort: IDL, MSDL, WSDL, or a Java interface file. Hence, service-oriented.

    Finally, by definition, you cannot do ROA today with anything other than principled use of HTTP and URIs.

  3. bex | October 9, 2007 at 10:31 am | Permalink

    Finally, by definition, you cannot do ROA today with anything other than principled use of HTTP and URIs.

    So, does that mean by definition ROA cannot have server-side state?

    I feel that EJB/SOAP people have co-opted the term SOA, and I don’t like that. A ’service’ doesn’t need to be mapped to an object, it can be procedural or data-driven. I prefer the latter.

    There’s very little “service” orientation in most WSDLs… many are — as you say — little more than object wrappers. Too much of SOAP is just cruft from OO programmers who know nothing of networks. This makes ROA people hate SOA, but I think ROA tricks people into thinking of the problem on the wrong level.

    I’m on something of a mission to rescue the term “SOA” from being associated with bad technology…

  4. Pete | October 9, 2007 at 10:52 am | Permalink

    bex:

    So, does that mean by definition ROA cannot have server-side state?

    No, though (oddly) many people make the mistake of thinking so. Read the post again and note my definition of a resource which states “A resource has state that changes over time.” Without server side state a resource isn’t, well, anything at all. If you’ve encountered the statelessness constrain of REST, what that is referring to is session state, that is the server can’t know anything about prior interactions with the client. You might also be referring to “application state” which is indeed kept on the client. In the sense that a customer is a resource and a collection of customers is a resource, but its an application that provides, say, a user interface to the customer service rep.

    I feel that EJB/SOAP people have co-opted the term SOA, and I don’t like that. A ’service’ doesn’t need to be mapped to an object, it can be procedural or data-driven. I prefer the latter.

    Well, I wouldn’t blame the EJB people (whoever they are), but yes the SOAP people have popularized the term SOA. And despite the fact that the popular definition is fluid, I don’t see anything wrong with it. SOAP is no longer object-centric, it’s a given that you can create services in, say, Perl or PHP while avoiding the OOness that has been grafted on to these languages. However, the most popular languages today are object-oriented or object-capable, so no harm done.

    but I think ROA tricks people into thinking of the problem on the wrong level.

    I strongly disagree. There are no tricks. And thinking in terms of the resource is frequently, though not always, a beneficial if not necessary approach.

  5. Stefan Tilkov | October 9, 2007 at 2:04 pm | Permalink

    I don’t agree ignoring the network is a necessary aspect for SOA. I believe you can do network-oriented computing using WS-*. The (unnamed) WS-* architecture is not that different from REST/ROA in this aspect — it’s different because it doesn’t have a uniform interface (which is, as we agree, a very significant difference).

  6. Pete | October 9, 2007 at 3:09 pm | Permalink

    Stefan: If SOA is defined as above, then I would disagree. For instance, WSDL-based SOAP sucks at versioning which ignores the fact that the network is not entirely under your control and systems evolve indepently. With no support for caching WS-* ignores highly latent networks. And so on.

    That said, I, myself, do not find the distinction that important, at least when discussing architectures. As I refine this I’ll probably bake it down to NCC->ROA and NCC->SOA plus governance and process analysis.

  7. bex | October 9, 2007 at 6:25 pm | Permalink

    So, does that mean by definition ROA cannot have server-side state?

    No, though (oddly) many people make the mistake of thinking so.

    Precisely why I don’t like ReST “purists”… they tried to convince me of 100% stateless. I agree with “session statelessness.”

    However, I think we need a very precise definition of what a “service” is. Since a ReST resource can be a service or data, and since SOAP is all about services, I think its important to explain how they are different.

    At first glance, to me they are philosophically equivalent. But I got into trouble for saying so:

    http://intertwingly.net/blog/2007/10/05/NOC

    BTW, great job thus far.

  8. Pete | October 9, 2007 at 9:11 pm | Permalink

    bex: It’s possible you were misinformed, but it’s more likely that there was confusion around the multiple places where state can reside. Yes, REST has a statelessness constraint, but again that only refers to session state. In short, in REST there are no sessions, every interaction with a resource is as if it were the first.

    In contrast resource state is the resource itself. For instance, a customer resource has state that describes the customer’s name, address, and so on. In addition, that state can change over time (say the customer moves). A resource without any state isn’t anything at all; a network accessible version of /dev/null.

    If you can imagine a universe of thousands or millions or kajillions of resources, then it becomes obvious that resources also don’t maintain application state. A customer resource can’t maintain the state of a CRM app, since it may be in use by any application. It’s the job of an application to access these resources to gather information (in effect altering its own state in doing so), interact with its environment, e.g. a user, and, if necessary, alter the resource’s state by writing a new state back to the resource. So the CRM application pulls down a customer’s state, changes the customer’s address, and pushes it back.

    It’s been argued that from a certain distance resources and services look identical. And I guess that’s true, but only in the sense that rats are look like humans in that they’re both mammals. At the typical level of interaction, however, rats and humans are worlds apart (lawyers excluded).

    At this point we need to go beyond the limits of a blog comment. Here’s what I recommend, pick up the REST Web Services book and give it a read. Then pick an app you want to create and create a RESTful version of it, open it up to critique by the REST knowledgeable if you care to. I can assure you that thinking RESTfully will put things in a completely different perspective.

  9. Dan Creswell | October 10, 2007 at 8:11 am | Permalink

    “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.”

    and:

    “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. ”

    Hmmm so I’m not convinced about this lack of a style argument on the basis of the above. If you are into making remote look like local does it not follow that your “style” is that of local computing which might be based on classes and interfaces or structs etc and involves all those old-style GoF patterns etc? I guess you might argue that’s still not a style but it may be that’s simply due to the fact that you’d have to distill out all the possible local computing styles available of which there are many?

    Also:

    “I’ve given SOA a purely technical meaning, and it refers to any NCC design that promotes a service interface of non-uniform methods as its prime abstraction”

    That’s okay - you are entitled to attach whatever meaning you wish to a term (and heaven knows that’s been done often enough for SOA) but that’s maybe a limiting factor on relevance of the discussion if everyone else’s meaning for that term is different?

  10. Pete | October 10, 2007 at 8:49 am | Permalink

    Dan:

    If you are into making remote look like local does it not follow that your “style” is that of local computing which might be based on classes and interfaces or structs etc

    Interesting. However, I’d say no simply because we would then be referring to the architecture of a single system, rather than a networked architecture. But as I said to Stefan, I think I muddied the water with the NOC and NIC stuff. It’s an interesting (and in some circles important) distinction, but right now it’s just noise. From the feedback so far I think the nomenclature will become: NCC + analysis —> (SOA|ROA) + governance.

    but that’s maybe a limiting factor on relevance of the discussion if everyone else’s meaning for that term is different?

    Understood, but that’s the whole point of this post. Everyone has a different definition of SOA. I’m suggesting we all settle on one. My suggestions is for SOA to keep its technical meaning, and to use NCC instead of SOA when referring to a broader context that can encompass REST and WS-*.

  11. herbalife | November 19, 2011 at 12:41 am | Permalink

    Some truly prize content on this site, bookmarked .

  12. Dr Joseph Obi | December 31, 2011 at 3:42 pm | Permalink

    I have not checked in here for a while as I thought it was getting boring, but the last several posts are great quality so I guess I’ll add you back to my daily bloglist. You deserve it my friend :)

  13. embarazada | January 13, 2012 at 7:59 pm | Permalink

    some genuinely superb blog posts on this site, regards for contribution.

  14. business communication | June 18, 2013 at 3:36 am | Permalink

    Hey there, You have performed a fantastic job. I’ll certainly digg it and in my opinion recommend to my friends. I’m confident they will be benefited from this web site.

  15. replicalouisvuittonp | June 21, 2013 at 10:51 am | Permalink

    Actually when someone doesn’t know then its up to other visitors that they will assist, so here it takes placePete Lacey’s Weblog : Towards a better network programming taxonomy. replica louis vuitton purse http://www.voguehandbagstore.com/wallets-c-1_74.html

  16. fitted kitchens | September 8, 2013 at 4:57 pm | Permalink

    What i do not realize is in truth how you are now not actually much more neatly-preferred than you may be right now. You’re so intelligent. You understand thus considerably in terms of this topic, produced me personally consider it from so many varied angles. Its like men and women aren’t fascinated except it is something to do with Girl gaga! Your personal stuffs outstanding. At all times handle it up!

  17. Jets Jerseys 2013 Nike | November 26, 2013 at 3:02 am | Permalink

    Pete Lacey’s Weblog : Towards a better network programming taxonomy
    Jets Jerseys 2013 Nike http://www.contentmentobx.com/Cheap-New-York-Jets-Jersey/Jets-Jerseys-2013-Nike.html

  18. web | January 28, 2014 at 11:44 pm | Permalink

    This page certainly has all of the information I needed concerning this subject and didn’t know who
    to ask.

  19. bisnis online | June 15, 2014 at 11:37 pm | Permalink

    It is appropriate time to make some plans for the future and
    it is time to be happy. I’ve read this post and if I could I wish to suggest
    you few interesting things orr tips. Perhaps you can write next articles referring tto
    thiis article. I wish to read even more things about it!

  20. small business | July 3, 2014 at 11:40 pm | Permalink

    You ought to be a part of a contest for one of the finest sites on the web.
    I’m going to recommend this blog!

  21. hunt in poland | July 8, 2014 at 5:35 pm | Permalink

    I got what you intend, thank you for putting up.Woh I am glad to find this website through google. “I was walking across the street wearing glasses if the prescription ran out.” by Steven Wright.

  22. Andr | August 2, 2014 at 9:36 am | Permalink

    Web 2.0 = read/write web : people can put their own cneotntWeb 3.0 = semantic web : web applications understand what you wantWeb 4.0 = ?????Web 5.0 = telepatic web : no interface needed, you just think it and know the answer

{ 3 } Trackbacks

  1. [...] read more here [...]

  2. [...] all the details here This entry was posted on Monday, October 8th, 2007 at 10:36 pm and is filed under architecture designs. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. [...]

  3. shox vital | February 9, 2014 at 5:11 pm | Permalink

    shox vital…

    Pete Lacey’s Weblog : Towards a better network programming taxonomy…

Post a Comment

Your email is never published nor shared. Required fields are marked *