Cars that get one hundred miles to the gallon, perpetual energy machines, sure-thing stock tips, and vendor-neutral, interoperable computer system integration technologies: All of these may sound mythical, but there’s a good chance at least one of them is actually within reach. And you can probably guess which one that is.
Thanks to Service-Oriented Architecture (SOA), district technology leaders now have an appealing technical option for getting their disparate systems to work together and share data. The benefits of SOA include the creation of standardized, vendor-neutral interfaces to your systems, the ability to easily share data within the enterprise or even outside of it, and improved ease of modification to existing systems.
The popularity of SOA is picking up speed in the business world, and while SOA may still only be a buzzword in K–12, it's a concept that bears consideration—particularly for districts that need to connect their IT systems effectively and efficiently. The process of implementing SOA requires careful study and prudent technology choices, so now is the time to learn about SOA and what it can do for you.
How It Works
Service-Oriented Architecture is a technical architecture based on services. In other words, SOA describes an architectural style or concept, a theory of connectivity and communication between services. The “service” an SOA is oriented around is a self-contained, computer-based function that can be performed by one system for the benefit of another system. Facilitating these self-contained functions, and allowing different systems with different functions to communicate and coordinate with one another, are what SOAs do best.
Take, for example, a typical K–12 environment, where looking up student information is a necessary service. Many different systems in a district “need” student data, from assessment applications to those that keep track of student transportation. Prior to SOA, typical options for sharing this information included hand-coding a series of custom interfaces between the student information system (SIS) and other systems, or worse, maintaining multiple copies of the necessary data. With SOA, the SIS becomes the sole source of authoritative data. This data is offered to other applications through a service that is in turn accessible via a common interface.
Furthermore, if a new IT system comes along that needs student data, it can be configured to use the exact same service accessed by all of the other applications (as opposed to recoding all of your interfaces). And if the SIS changes—whether a minor tweak or a complete swap-out to a different application—all that’s needed is a relatively simple backend modification of the service. That’s the beauty of SOA: it decouples the information and processes needed to run your schools from the hardware and software that store and process that information.
Another way to look at it is that with an SOA, you separate what you want from how you get it. It’s similar to being at a restaurant. You order your food through a waiter, but you don't have to know anything about where the ingredients come from or what kind of equipment the kitchen uses to cook the food. The restaurant could replace all of its ovens, and you'd never need to know.
Prerequisites for Success
A service must have certain key attributes in order for it to work properly in an SOA environment. First, the service must be self-contained; that is, not dependant on other services. Second, the service needs to be technology-neutral. One set of services could be written in C# using the .Net framework and hosted on a Windows server, for example, while others are written in Java and served from a Mac OS X or Linux server—as long as the services are written and deployed properly, details like programming languages, hardware, and platform-compatibility are largely irrelevant.
Consider, again, the SIS example. If “student information lookup” is made into a service that can be accessed by other applications in your district, the SIS can be upgraded, modified, or completely replaced without having to recode all its connections to outlying systems. The reverse is true as well. Let’s say your school nurse has a stand-alone health system that accesses student data residing on an SIS. If you decide to replace the health system, recoding the new system should be easy with an SOA enterprise.
Improving on Past Methods
Think you’ve heard this story before? It’s true that a centralized interface architecture has been available for some time from vendors like webMethods. SOA offers the same interoperability and integration, but the difference is that SOA works across a complete range of products and vendors using industry-standard technologies. In fact, webMethods, a strong proponent of SOA, has now largely focused its integration business on Web services–based SOA technology.
Other methods for addressing sticky enterprise integration problems include CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Component Object Model). CORBA was originally intended to be a vendor-neutral and language-independent object model for software interfaces between systems, while DCOM was a Microsoft-designed framework intended to make remote requests across a network to other systems. Both share some striking similarities to SOA, but both have major shortcomings. CORBA-based solutions from different vendors don't always interoperate well, if at all, and DCOM is limited in that it’s only compatible with Windows.
In contrast, Service-Oriented Architecture minimizes these kinds of problems by building on established industry standards. The first of these standards is Web Services, a term that, like SOA, is often misunderstood (see Web Services Explained below). Technically, an SOA is technology-independent, so it doesn't require the use of Web Services. In practice, however, virtually all successful SOA implementations are built upon Web Services and associated technologies.
Next Week: SOA implementation strategies
Richard Hoffman is contributing editor of School CIO.
Web Services Explained
Meet the driving force behind Service-Oriented Architecture.
Web Services is the term for the technology that makes most Service-Oriented Architectures work. In practical terms, this means that for each system that wants to communicate with other systems, one or more Web Services are created and made available. One of the strengths of SOA (and the Web Services used to implement SOA) is that services are language-neutral—they can be written in C++, Java, C#, whatever you prefer. What's under the wrapper isn't important.
The core standard to all of Web Services is Extensible Markup Language (XML), a general-purpose language designed to facilitate data sharing. Web Services uses a form of XML called Web Services Description Language (WSDL) to describe how each service wants to be accessed.
Communication with and between Web Services in an SOA often occurs using a protocol called SOAP (formerly an acronym for Simple Object Access Protocol, or perhaps Service-Oriented Architectural Pattern). SOAP is the key to Web Services, because it describes the lower-level methods of communication and the foundation layer for Web Services, and it typically does this communication via the ubiquitous HyperText Transfer Protocol (HTTP), which has the advantage of being able to pass through most firewalls.
So, to recap, SOA is typically implemented using the Web Services standards. Web Services makes use of an XML-based protocol called Web Services Description Language to announce what services are available, and how to use them. Web Services typically communicate using SOAP messages, which are built using the standard HTTP protocol. Got it?
