Introduction 

Connecting distributed systems has been a core need for businesses and organizations that need to tie together and re-use disparate processes and systems. When I first started in IT, I remember integrations between systems that were done in many different ways, the most primitive being sharing export files using "sneakernet" and the most advanced using a shared SQL database to transfer data. In general, in those days, all interoperability between systems was extremely proprietary and hand-built. Any new connection that needed to be made between systems required a new design and a new strategy for integration, usually resulting in a tight coupling between the systems that was fragile, making system upgrades increasingly more difficult to do over time as the spider web of interconnections was woven increasingly more complex.

Technology has, indeed, progressed over the years with many different communication transports between systems being developed, including Named Pipes, DCOM and CORBA. In the late 90s, XML was becoming more popular as an interoperable data format. HTTP communication was also highly interoperable and development tools and servers to host HTTP became pervasive because of the internet boom. At that time, a number of smart people started designing specifications that allowed systems to communicate using XML over HTTP. Some of the initial work on this was known as XML-RPC, which is still around, but which lead to the design of SOAP 1.0 and then SOAP 1.1.

These technologies have evolved over time into the WS* specifications, which are in wide use today as the basis for interoperability for many connected systems. In general, this messaging architecture using XML over HTTP or HTTPS is known as "web services". The industry has now evolved to the point where it has recognized the need to "architect" the connections between systems so that they are loosely coupled, reliable, scalable, configurable, discoverable, secure, instrumentable, versionable, and robust and that they actually meet the needs of the systems being connected. This formalized concept of the architecture around webservices has become known as Service Oriented Architecture (SOA). There are, indeed, many different definitions of SOA, but in general, the definition being used in this article series is "the design architecture that is used to connect distributed systems, sharing data, workflow, and processing"

While the concept of web services was still being developed, a smart group of people was also building what was to become the Schools Interoperability Framework (SIF), which has many similarities to other XML messaging standards, but was developed to meet interoperabilty needs in a much more specific and architected manner than the more generic SOAP specifications. This article examines the importance of an architectural approach when building solutions based upon the Schools Interoperability Framework. We will peel back the layers, pop the hood, and look at the design of SIF from an SOA perspective. Along the way, we will discover the strengths of the SIF specification, as well as reveal the areas that may need to be looked at in future releases.

This article assumes a working knowledge of the Schools Interoperability Framework, which is an industry standard web service specification used to connect systems in schools, districts, and state education agencies. For more information, see www.sifinfo.org.

Coupling

One of the most important features in a good SOA design is to reduce the amount of coupling between the connected systems. Tight coupling means that one system is very dependent upon another system in a proprietary way. Coupling can occur both at the interface level, in the time dimension, and in other areas. Sometimes the coupling is circular, which is even worse. If one system that is depended upon is removed or replaced, the integration easily fails and the link may need to be recreated, often at great expense. A desirable design is for the systems to be loosely coupled so that each connected system can be modified and other services can be added or removed with minimal impact on the connected systems.

Coupling at the interface level

A desirable architectural design requires the connected systems to not have explicit knowledge of each other, but to conform to a specific design contract. A system that is written to communicate to the outside world using a carefully designed public contract rather than a proprietary link will be much easier to maintain over time as components and services are upgraded. The design contract that needs to be adhered to by an application includes the transport layer used for communicating with the other applications, the specification of the data that is shared, and the communication patterns that are expected or allowed between the systems. Building an integration upon a published standard such as SIF is one way to reduce coupling.

The SIF Specification has many aspects that promote loose coupling between the connected systems. For starters, the SIF specification recommends that the communication between the systems be done by "agents", which define and consume the services available within SIF. This important design concept of writing a seperate agent rather than communicating directly from the application produces a much looser coupling between the application and SIF, allowing the SIF interface to evolve at a pace that is separate from the pace of application development.

Another aspect that promotes loose coupling is that SIF agents never communicate directly with each other. Rather the SIF specification requires that all communication done by the agent is done with a zone, which is an abstract set of web services that is hosted by a service appliance known as the Zone Integration Server (ZIS). The ZIS manages agent registration and provisioning settings so that agents do not have to be concerned about which other agents provide data or are subscribed to data change events. Agents can be added or removed from a zone without disrupting the flow of messaging within the zone or dependencies between the applications.

Coupling in the time dimension

Coupling in the time dimension is one type of coupling that is often easily overlooked in architecture. This type of coupling happens when the integration depends on all connected services to be online and connected at the same time. This can be caused by web service definitions that are defined as being 'synchronous', which requires the response to the service invocation to be returned immediately. An asynchronous approach is often more difficult to both design and implement, but promotes loose coupling in the time dimension. Asynchronous communication between systems promotes scalability, availability, and fault tolerance because the connected systems are not as adversely affected if a system is unavailable or busy at a given point in time.

The SIF messaging architecture is, by design, almost entirely an asynchronous design. The SIF Request/Response, and Event protocols are asynchronous. Agents that provide or consume data can be intermittently offline without causing  disruptions to the capabilities of other agents. If an agent requests data, the request is asynchronous with no real need for the responding system to be online or available at the same instant in time. At some later point in time, the response is created and delivered to the requesting agent. This concept also applies to events. SIF also adds quality of service guarantees to the asynchronous request/response protocol, which will be discussed in a future article.

There are, indeed many other types of coupling that could be discussed. I'll save that discussion for future articles. If you have any comments on coupling as it applies to SOA or SIF, please reply to this post. 

Read the next post in this series: http://sifzone.com/blogs/sifbits/archive/2007/06/21/a-view-of-sif-from-a-service-oriented-architecture-perspective-part-2.aspx