{"id":14,"date":"2005-04-14T22:42:05","date_gmt":"2005-04-15T05:42:05","guid":{"rendered":"http:\/\/kennyw.com\/indigo\/14"},"modified":"2005-04-14T22:42:05","modified_gmt":"2005-04-15T05:42:05","slug":"layering-as-a-foundation","status":"publish","type":"post","link":"https:\/\/kennyw.com\/?p=14","title":{"rendered":"Baking a Seven Layer Service Cake"},"content":{"rendered":"

Indigo is constructed with layering<\/em> as a central design principle. This means that in essence Indigo is actually a collection of sub-frameworks, each of which can be supplemented by ISV code (or replaced completely for that matter). Each framework is defined by two things:<\/p>\n

    \n
  1. Fundamental unit(s) of data<\/li>\n
  2. Transformations that can be applied to said data<\/li>\n<\/ol>\n

    Which (as you might be thinking) is another way of saying an object is defined by its members and its methods. This is true, but it’s more difficult (but very important) to stay focused on consistent pivots when constructing clean frameworks.<\/p>\n

    \"Messages\"Indigo is built around the concept of a Message object<\/em>. The structure of a Message object loosely represents a SOAP<\/a> envelope, and consists of two distinct parts: the message’s body and an extensible collection of headers. The body is application-defined data, and headers are added\/processed by infrastructure (and can also be used by the application). Access to a header or the body is achieved through XmlReader<\/a>, as it contains structured data. It is this structured primitive which is the core of Indigo’s power (and which departs from the classic networking primitive of a byte array). It allows for extensible, interoperable protocols<\/a> to be built, and for data contracts to be established.<\/p>\n

    At a high level, Indigo consists of two larger frameworks: the Typed Layer<\/em>, and the Channel Layer<\/em>.
    \n\"Indigo<\/p>\n

    The fundamental unit of data for the Channel Layer is Message. Channels are used to Send<\/em> and Receive<\/em> Messages. Channels come in two forms: Transport Channels<\/em> and Layered Channels<\/em>.<\/p>\n

    Transport Channels perform the actual send\/receive of the Message to a network resource, including any necessary serialization.<\/p>\n

    Layered Channels perform a function based on the Message passed in, and then delegate further modification and transmission to their Inner Channel<\/em>. So as you can see, even within a layer we have layers \ud83d\ude42 Some examples of Layered Channels include Protocol Channels<\/em> that use Message headers and infrastructure Messages to establish a higher-level protocol (such as WS-ReliableMessaging<\/a>), and Reshaping Channels<\/em> for changing the Message Exchange Pattern (such as converting an underlying [Send Channel, Receive Channel] pair into a Duplex Channel).<\/p>\n

    Message is a very flexible object, but to fully utilize it requires knowledge of Infosets and XML. What most developers instead will likely interface with is the Typed Layer. The fundamental unit of data for the Typed Layer is a CLR class. In the Typed Layer you create CLR objects that implement Services<\/em> and Typed Proxies<\/em>. The Typed Layer converts parameters and return values into Message objects and method calls into Channel calls. In this way, the Typed Layer builds on the functionality of the Channel Layer, and can transparently leverage any changes\/improvements made to Channels.<\/p>\n

    Next I’ll provide an example to give you a flavor of this layering in action, stay tuned!<\/p>\n","protected":false},"excerpt":{"rendered":"

    Indigo is constructed with layering as a central design principle. This means that in essence Indigo is actually a collection of sub-frameworks, each of which can be supplemented by ISV code (or replaced completely for that matter). Each framework is defined by two things: Fundamental unit(s) of data Transformations that can be applied to said […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[19,26,80,85,91],"class_list":["post-14","post","type-post","status-publish","format-standard","hentry","category-indigo","tag-binding","tag-channel","tag-transports","tag-wcf","tag-work"],"_links":{"self":[{"href":"https:\/\/kennyw.com\/index.php?rest_route=\/wp\/v2\/posts\/14","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kennyw.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kennyw.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kennyw.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/kennyw.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=14"}],"version-history":[{"count":0,"href":"https:\/\/kennyw.com\/index.php?rest_route=\/wp\/v2\/posts\/14\/revisions"}],"wp:attachment":[{"href":"https:\/\/kennyw.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=14"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kennyw.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=14"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kennyw.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=14"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}