Most organizations today have internal applications that span across different systems, networks, and technologies. These applications would provide more value to customers if only the data that they manage were exposed. In the past, this was often difficult due to the inability of systems to communicate with one other. However with Web service standards in place for several years now, services are finally gaining acceptance throughout the industry. Consequently, service-oriented architectures (SOAs) have finally come to fruition as companies start to rethink how they build enterprise applications.

In the past, organizations typically approached large-scale development efforts as one monolithic project. This was often due to constraints of the underlying technology as well as the difficulty of making systems communicate. If applications did communicate, they were invariably tightly coupled.

The concept of SOAs has changed the model of large-scale application design. Web service standards now provide the ability for companies to build core services that provide both business agility and functional reuse; as a result, applications become thinner by nature and rely on integrated services to do the heavy lifting.

Web service standards also allow organizations to build service wrappers around existing functionality, thereby getting more value out of existing systems. Finally, services are decoupled from consuming applications, allowing them to be built independently of one another.

The remainder of this article will explain how the aforementioned concepts apply to a real-world SOA implementation recently built by Analog Devices.

The Need for a Service-Oriented Architecture
Analog Devices, Inc. (ADI) designs, manufactures, and markets high-performance analog, mixed-signal, and digital signal processing (DSP) integrated circuits (ICs) used in signal processing applications. ADI's target audience comprises design engineers who evaluate semiconductor products for many different applications. In an effort to support these customers, the company constantly builds Web-based design tools to allow for product evaluation prior to purchasing. These design tools simulate the electrical behavior of an integrated circuit and allow the engineer to study the electrical response based on certain input signals without even touching the soldering iron.

ADI faced several ongoing challenges that impeded their online tool development. First, tools were often tightly coupled around a particular product or small group of products. These tools provided value to the customer for a particular part but did not scale to support multiple parts within a given product line. It would often take many months before a new tool could be created for new or emerging products.

Another problem the company faced is that the information required building design tools for customers resided within different existing internal applications and systems. As with most large organizations, ADI suffered from the dissemination of data throughout their organization. The company needed a way to encapsulate the common functionality required by all design tools and make it available for reuse.

Finally, ADI was looking to leverage a third-party application to build simulation engines that would provide the core value for their online design tools. The product of choice was National Instrument's LabVIEW, a powerful third-party application that provides a sophisticated tool suite to build test and simulation applications. However, LabVIEW was not originally designed for distributed Web-based applications and exposing application functionality from this product via the Web was not seamless.

A new strategy was needed that would solve these business and technical issues.

Approach
ADI, with the help of Molecular, Inc., decided to build a service-oriented design tool framework that would serve as the foundation for future online design tool development. In this architecture there are two types of services: core business services and simulation services.

Core business services encapsulate functionality that could be reused by multiple design tools. These services integrate with the appropriate internal systems necessary to provide the desired functionality as well as adhere to common Web service specifications. These reusable services speed up the development of future design tool applications.

The second set of services allowed ADI design engineers to expose simulation engines built in LabVIEW as services. In this architecture simulation services are tightly coupled to a particular design tool application.

Architecture
Figure 1 gives a high-level illustration of the Design Tool architecture. Each online design tool is developed as an ASP.NET application and integrates with the core set of services as needed. The interface to the specific Design Tool simulation engine (developed in LabVIEW) is wrapped in a standardized Web service SOAP header and made available to the client design tool application.

Service Development
The first step was to identify the core set of services that could be reused by multiple design tools. Common functionality was identified from several internal sources, including ADI's product database, content management system, FTP server, and parametric search applications. For each of these core services, a standardized SOAP interface was created and made available to calling applications.

Next, the team defined the service interface for the design tool simulation engine. This type of service was different from the core services because it was not intended to be used by future design tools. As mentioned earlier, each online design tool consists of a simulation application developed in LabVIEW.

The development team consisted of two groups: design engineers and Web application developers. Design engineers have the ability to build sophisticated simulation engines using the LabVIEW product, but they are not experts in Web application technology. As a result, Web developers built the online Web application and provided the necessary service plumbing to expose the simulation logic. A service-oriented architecture made sense for ADI because each service defined a clear delineation of work between team members.

Rather than create a detailed service interface, the team chose to expose only one parameter in the WSDL, a serialized XML Stream of data that adhered to a valid W3C XML Schema. By simplifying the Web service interface the team was able to focus exclusively on designing the XML data structures that would be passed back and forth, thus abstracting the Web service technologies during initial design.

Once the XML data contracts were agreed upon, LabVIEW application developers were able to go off and design the simulation engine independent of the consuming design tools application. Each simulation engine was compiled as a shared library.dll, imported into a .NET Web Service assembly via DLLImport, and then exposed as an internal Web service.

The team also took advantage of the XSD Sample Code Generator (XsdObjectGen) tool provided by Microsoft. Once the data contract was defined as a valid W3C XML Schema, the XsdObjectGen tool generated a set of managed .NET classes (either VB.NET or C#) that was then used to interface with the service. Application developers interacted with the service via method calls rather than by directly manipulating XML.

Benefits
By leveraging an SOA, ADI was able to achieve the following benefits for their Design Tools Framework:

• The ability to build reusable components that were not dependent on a particular application. By building a set of core services to extract data from existing internal systems and databases, future design tools can now easily incorporate existing functionality with minimal effort.
• Web service standards allowed the company to build service wrappers around existing internal systems and applications that provide a mechanism to expose this knowledge externally to customers.
• The ability to define service interfaces up front allowed the company to better align its core competencies to its areas of expertise. Simulation services were decoupled from the client applications, allowing each to be built independently.
• By streamlining the Web service interfaces, ADI is able to quickly define XML data contracts passed between simulation services and consuming applications.

By identifying existing knowledge that could potentially be bundled as business services, companies can reap the benefits of functional reuse, loose coupling, and technical platform independence.

This article has also shown a real-world example how Analog Devices implemented a service-oriented architecture to build out a new online design tools framework, as well the benefits the company received from using this approach.