Two emerging architectural styles are becoming popular: Service Oriented Architecture (SOA) and appliances. Both are becoming ever more relevant and popular in enterprise architectures. But SOA and appliances are very different architectural styles. SOA supports distributed architecture while the appliance represents the epitome of standalone applications. Both SOA and appliances have distinct advantages and drawbacks. How should organizations evaluate and choose which architecture is right for them?

There are no standard definitions for the terms "SOA" and "appliance." To provide some clarity, I'll briefly describe each approach.

SOA can be defined as a technology-agnostic architecture comprised of loosely coupled modules called "services" that interoperate to perform desired functionality and foster reuse across an organization. A service is a set of cohesive business logic units of work that are encapsulated into a coarse-grained autonomous module. These services are then loosely coupled to form applications. This approach has many benefits, including reuse, that drive down the total cost of ownership and improve functional consistency. In addition, the loose coupling of SOA allows your organization's internal and external services to be integrated easier.

Appliances are software stacks that are integrated into a solutionand, although comprised of many components, act as a single autonomous service or application. This is similar to virtualization, where a software stack is deployed and managed as a stack from the operating system up. An appliance often implies that the solution resides within hardware, while virtualization usually resides in an emulated runtime environment. Virtualization and appliances are architecturally quite similar when contrasted with a SOA style of architecture that promotes distributed services. For simplicity, the remainder of this paper will refer to both the virtualization and appliance styles of architectures as "appliances."

The benefits of an appliance are derived from its extreme encapsulation of an application from the operating system up. This encapsulation makes appliances relatively easy to deploy, scale, and maintain. All the components within the appliance are managed as one, abstracted behind the appliance. Without the appliance, the individual components that would reside within the appliance would have to be managed independently. An appliance's administration is often done from a single interface, and the administrator isn't aware of the individual components within. Some popular appliances include Linksys routers and TiVo digital video recorders. When a user administers a Linksys router from the appliances interface, for example, the software components within the device aren't visible. To the end user, the component stack that supports the device looks autonomous, like a single piece of software. But in reality, these devices are assembled software technology stacks that include the Linux operating system.

The appliances style of architecture seems to be at odds with the SOA architecture. Appliances are autonomous and tightly coupled software stacks, while SOA promotes distributed, loosely coupled software services. SOA allows for better reuse, because a single service can be consumed by many applications. An appliance is superior in terms of ease of deployment and administration because the complexity of integrating the components to form an application is already done. So which is the better architecture? Which one should your organization choose?

Before answering this question, it's a good idea to look at why these architectures are becoming relevant now. Is it just coincidence that SOA architectures and appliances are arriving on the scene at about the same time? Interestingly enough, the key factors that are contributing to these architectural styles coming of age is the same for both SOA and appliances - Open Source software and open standards. Both appliances and SOA architectures are supported by Open Source software. Open Source excels at assembling components into larger solutions because Open Source solutions are usually standards-based, often heterogeneous due to their community-driven model. Open Source is available at all levels of granularity, from small libraries through entire operating systems and databases. The popular acronym "LAMP" that people use to refer to Open Source software is itself an assembled stack comprised of an operating system (Linux), a Web server (Apache HTTP Server), a database (MySQL), and programming languages (PHP, Perl, and Python).

Of course there are many other Open Source components that can be assembled as part of a software stack. LAMP is an acronym that represents Open Source's potential as an architectural stack rather than the specific solutions defined by the acronym. Components that can be assembled are a primary capability in building appliances. Open Source software also benefits from a licensing distribution model, which allows it to be embedded and deployed in an appliance. A vendor can't easily embed commercial software into an appliance and distribute it freely like many Open Source solutions. SOA also relies on Open Source software and open standards. The inherent properties of Open Source make it a compelling solution for a SOA tasked with integrating heterogeneous services in a standard way. This is why there are so many Open Source solutions available for SOA and middleware in general. And open standards such as JBI, JMS, and the plethora of WS-* standards are crucial to a SOA's success. (For more information on the available Open Source software and standards for SOA, please see the white paper entitled "Service Oriented Architecture and Open Source Solutions" from Optaros.)

So now that both SOA and appliances are gaining traction, how does an organization choose between them? Which option is better - SOA's distributed and reusable architectural approach or the appliance's simplicity and ease of maintenance? The best choice may not be to choose between them, but to choose them both. Perhaps the best way to view these two architectures is how they complement each other. An enterprise should unify both strategies to leverage the strengths each provides - SOA is adept at enterprise architecture, while appliances excel at application architecture. Appliances are a compelling way to build services and SOA eases the effort to integrate services. (See Figure 1)

In this model an application is built by accessing services through the SOA infrastructure and providing an interface. The services are built and deployed as appliances. This marriage seems optimal, benefiting from each architectural style's inherent benefits. This is a great way to develop services and applications when they are built in-house. Some third-party appliances have user interfaces built into them, and thus are standalone applications. For these appliances, it's a good idea to make sure the appliance has an API that can integrate into the organization's SOA infrastructure. Choose appliances that have open and defined APIs so the SOA can discover and leverage their logic and data. For example, if Web Services are a supported endpoint in your organization's SOA, then the appliance can be wrapped with SOAP, a WSDL can be created for the appliance, and the appliance is entered into a corporate discovery database, such as a UDDI repository. With this approach, the appliance will look like a common service to the other services and applications on the SOA that may want to use it.

Looked at this way, SOA and appliances aren't at odds, but can be used to build stronger enterprise architectures. Many organizations are just beginning to evaluate SOA and appliance architectures, so now is a great time to evaluate the architectural differences between these solutions and create a plan to prevent these different architectural styles from pulling each other apart. Instead, they can coexist by leveraging the inherent and powerful advantages provided by each.