The Indigo Architecture

The Indigo framework is a layered architecture. You generally interact with the top layer (known as the service layer ) and work in terms of program abstractions ” methods , events, and callbacks. The service layer converts these abstractions into messages, which it delivers to lower layers ”a process that eventually result in the message transmission.

The SOAP specification defines messages at the XML Infoset level. The XML Infoset defines a hierarchical structure for information. Specifically, it does not require that information be represented by angle-bracket-encapsulated data. Angle- bracket encapsulation just happens to be one particular serialization format for an XML Infoset. Soap requires a sender to pass an XML Infoset to a receiver; however, the actual serialization of the XML Infoset could be text or some other representation. It s the job of the formatter to convert an Infoset to and from a particular serialized representation.

SOAP does specify how a message gets from one place to another. Delivery and receipt of messages is the function of the transport layer, which deals with wire-level details. The transport layer defines abstract classes and interfaces you can use to implement any wire protocol. The transport layer also provides default implementations of those interfaces for TCP and Hypertext Transfer Protocol (HTTP) wire protocols.

Figure 6-1 shows the layered architecture of the Indigo system. The following sections describe each layer in more detail.

Figure 6-1: The Indigo architecture and important classes

The Service Layer

The service layer is the top-most layer in the Indigo architecture and provides a managed application programming interface (API) to both the service and client applications. It contains the classes that provide the basis for building services using the system-provided implementations. Using the service layer enables you to harness the power of the underlying layers without needing to understand the details of their implementation.

The service layer is a set of managed classes that implement strongly typed message sending and receiving. Your application calls a method with a return value when it wants to send a message and receive a response to that message (known as a correlated message pair ). Similarly, your application implements an event handler, and the Indigo services call your event handler when a service receives the appropriate message. While you can process the actual messages directly, it s much easier to use traditional methods, events, and callbacks and let the underlying serialization system build, send, read, and convert messages.

Typed Channels

The methods provided by the service layer translate the method calls to and from a message-based protocol. The service layer passes strongly typed messages to a typed channel. A typed channel exchanges strongly typed messages by using a general messaging pattern, depending on the kind of typed channel. For example, a datagram typed channel sends a strongly typed message without any guarantees of delivery. A dialog exchange typed channel sends a strongly typed message with reliable delivery. There will typically be a typed- channel for each type of message you send or receive.

Untyped Channels

A typed channel sends its messages using an untyped channel. Basically, the typed channel provides the type-safe wrapper around use of the untyped channel. It s actually the untyped channel that implements a particular message exchange pattern ”either datagram or dialog exchange. An untyped channel sends its messages via a port.

Ports

A port exchanges messages from untyped channels to the underlying transport and vice versa. A port contains a pipeline of one or more untyped channels that process messages from and to the transport and the untyped channel.

Transports and Formatters

A transport represents an adapter for an underlying wire protocol, such as TCP or HTTP. The transport handles connections, addressing, and flow control, but it delegates serializing of a message to a formatter. Conceptually, a transport accepts a message from a port, requests a formatter to serialize the message into a particular wire format, and sends the formatted message using a particular adapter. Of course, it also performs the inverse operations.

Transports receive messages from or pass messages to their associated Port message pipeline. Transports are the only objects in the hierarchy that deal with message formats. All higher levels always handle message objects. You can see this structure in Figure 6-1, which shows the layer architecture of the Indigo system.

Managers

The Indigo manager objects provide most, if not all, of the complex functionality supported by Indigo service applications. When an application makes what seems like a simple request to the service layer ”for example, Send this message, and wait for the response ”a complex series of messages might result. For example, the system might time out while waiting for the response and might need to resend the request. Or the request might require sending authentication messages to the recipient. Whatever the situation, the managers handle the complexities resulting from your application requests. Managers often inject port extensions into the port message pipeline and take ownership of messages they need to process to provide the service your application requests. Figure 6-2 provides a picture of how managers interact with the port and untyped channels.

Figure 6-2: Managers acquiring messages from a port