Service-Oriented Architecture and Web 2.0

Jared T. Howerton

The Internet is quickly replacing the desktop as the medium of choice for modern application development. From its early days as a simple means for sharing information and communicating, the Internet has evolved into a modern day necessity. Consumers rely on the Internet for commerce, banking, email, instant messaging, and a variety of other daily tasks. This current evolution is often referred to as Web 2.0. This term has come to denote the personalization of the Web from streaming video (YouTube), social networking (MySpace), collaboration (blogs and wikis), and updated client technology (AJAX). These new technologies and trends have revitalized the Internet in terms of profitability and usability. With all of the new technology and innovation in Web 2.0, many consumers and professionals are wondering, what's next? The answer just might be a dramatic move toward a service-oriented architecture (SOA).

At the National Nuclear Security Administration Y-12 Complex, SOA is an important part of increasing software efficiency. We purchase new applications that provide services out of the box and we adapt legacy applications to provide service-oriented functionality. For instance, we are leveraging Windows authentication services to provide single sign-on capabilities for many applications. In addition, our information management system, Pegasus, uses multiple Web services to integrate seamlessly with corporate systems such as SAP. The ability to connect disparate applications using a SOA has provided Y-12 with an unprecedented degree of integration. Software is quickly becoming service-enabled out of the box. Enterprise products such as Microsoft SharePoint are focused on services and integrating with other products seamlessly. The days of writing complex middleware to integrate corporate systems is quickly coming to an end.

Though Y-12 is taking advantage of current technology and using the services available in its software portfolio, Y-12 has not yet developed a corporate SOA. This process includes a current evaluation of all existing solutions to determine how they should be connected in an ideal environment. To successfully complete this evaluation, Y-12 must think corporately and determine which applications provide best-in-class functionality. Once this is determined, this functionality must be service-enabled so that other software solutions can leverage this functionality to improve their efficiency. The end state should be an IT architecture where no significant functionality will be replicated between applications.

Understanding SOA

SOA is a buzzword that is often thrown around but seldom understood. The Organization for the Advancement of Structured Information Standards defines SOA as "A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with, and use capabilities to produce desired effects consistent with measurable preconditions and expectations. "Though this definition is comprehensive, it is best explained with a practical example (see Figure 1).

Figure 1. Using the purchase of a meal as an analogy, SOA provides the baseline or enterprise services.

Imagine a nice meal at a restaurant as a new project. To have a successful meal, you would need a table, chairs, glasses, plates, silverware, and napkins. These items must be in place to ensure that the meal will be satisfactory. Once these base requirements are met, a variety of foods and beverages may be added to meet your individual tastes. Combining the baseline needs with the additional requirements constitutes a full solution. Now imagine if, at the end of your meal, you were asked to pay the cost for the table, chairs, and so on, in addition to the cost of your meal ($448). Even worse, imagine if each restaurant patron had to absorb the total cost of his or her meal. It would be absurd.

When it comes to software, the users pay the total bill nearly every time. Almost every software application has a large amount of common functionality. Using the restaurant analogy, why do we continue to pay $448 when we should only need to pay $38? For instance, applications typically manage a set of users, provide authentication, use encryption, and provide error logging. Each new application purchased or developed typically implements coding to handle this common functionality.

The basic concept behind SOA is to provide a basic set of services that each application can access to provide this common functionality. Again, using the restaurant analogy, SOA provides the baseline or enterprise services. In essence, the idea is to write the code once and then use it everywhere. Conceptually, the result is less code, lower cost, and increased standardization.

As a long-time programmer, the idea of less code does not instantly appeal to me. However, from an enterprise level, the benefits are obvious. If less code is needed for a project, the result is that fewer programming hours must be absorbed. Since senior programmers typically fetch high salaries, the cost savings in this area can be significant. In addition, fewer lines of code mean less documentation. The total Software Quality Assurance (SQA) costs should be decreased since there is less code to document and enterprise documentation should already exist for the SOA services. Additionally, fewer lines of code mean less debugging, which also saves programming time. Using a SOA, the programmer needs only to write code to implement the unique functionality for a given project. The result is quicker turn-around times for projects and lower overall costs.

A SOA also results in increased standardization for the enterprise. Since new applications will use the SOA to implement base functionality, a higher degree of consistency will exist between applications. This consistency can be leveraged in the SQA world to obtain higher Capability Maturity Model certifications. In addition, less coding raises assurance for safety-related systems and quality management systems (ISO 9001). Finally, standardization helps businesses simplify their enterprise architecture and forces more up-front planning.

Though the SOA provides great benefits in the quality world, the biggest bang for the buck may ultimately be in cybersecurity. Lack of standardization is perhaps the largest cybersecurity vulnerability in most organizations. The multitude of software packages, operating systems, and Web technologies available results in a patching and configuration management nightmare. The result is an enterprise that is complex and costly to maintain. One goal of a SOA is to simplify this model. Figure 2 shows an enterprise authentication service used to manage the login process for multiple applications.

Figure 2. Three applications that must authenticate a user before allowing access to the system.

Figure 2 shows three applications that must authenticate a user before allowing access to the system. Rather than each application developing its own authentication mechanism, they will each use the enterprise authentication service. This approach has several benefits. First, any vulnerability found in the authentication service would require only one patch to the enterprise service rather than three separate patches for the applications. Second, this approach simplifies user management. For instance, if employee Jane Doe leaves the company, one database update removes her from all applications. However, if the applications did not share this authentication service, the user would have to be removed from each database to ensure that no unauthorized access could occur.

The Drawbacks

Given the benefits of a SOA, why haven't more businesses moved to the SOA framework? The answer lies in the fact that SOAs have several inherent drawbacks. First, the biggest benefits are achieved through upfront enterprise planning. For a mature existing business, the enterprise architecture probably was not designed to support a SOA. As such, a migration to this architecture would require a great degree of planning, reprogramming, and procurements. Most businesses do not have budgets to make such a shift when the current architecture is functional.

Second, the SOA is not necessarily as scalable or available as other solutions. Since a SOA often relies on XML and network communications, it's subject to outages and increased transaction time due to parsing and serialization. For highly scalable solutions, this latency is typically addressed through additional hardware which adds to the implementation costs.

Finally, many businesses are reluctant to put all their eggs in one basket. If an enterprise service fails, it could potentially disable multiple applications that would cripple the business. As such, redundancy and contingency planning are important parts of a SOA.

If a company wished to move toward a SOA, the most common implementation is via Web services. Web services are popular primarily due to their use of XML for data- and platform-neutral communications. The idea behind Web services is to write the code once and then be able to reuse it through multiple applications. Using Figure 2, an authentication Web service would be developed that could then be called from a desktop program, PDA, mobile phone, enterprise resource planning (ERP) system, or other system. The Web service can be consumed by Java, Microsoft .NET, or most any other programming platform. As such, it is an ideal replacement for traditional integration techniques such as Component Object Model and shared dynamic linked libraries. In addition, Web services can act as traditional classes that describe both data and processes. Therefore, you can view Web services as object-oriented programming for the enterprise.

Leveraging SOA to Move Forward

The beauty of Web services is that you can easily adapt almost any code to become a new Web service. In Microsoft .NET, you can apply a one-line wrapper to any function that then makes it available as a Web service. If your business does not have the capability to create new Web services, it can still work toward a SOA. Many ERP systems such as SAP are enabling functionality as Web services out of the box. For organizations that have invested large sums in their ERP system, the new Web service functionality should be heavily leveraged to maximize their investment.

Conclusion

In the future, every company will potentially have to face the decision to move toward a SOA. The SOA allows for agile development that will give many companies a competitive advantage. Web services are an enabling technology that will move businesses forward and speed process evolution. Web 3.0 is around the corner. Businesses that leverage SOA concepts and techniques will simplify their architecture, lower their operating costs, reduce the average IT project turnaround time, and increase cybersecurity effectiveness to ensure long-term business viability.

Jared T. Howerton is an information technology specialist at the National Nuclear Security Administration Y-12 Complex. Contact him at howertonjt@yso.doe.gov.