Software Architecture Offers New Possibilities
 |
| Service-oriented architecture (SOA) allows applications from different vendors to interoperate and to be modified to conform to changing technologies. SOA-based tools will help commercial and civilian government organizations to upgrade and enhance their computer networks more effectively. |
An emerging design methodology allows system designers to connect different vendor applications to share information across a network or networks and to adapt rapidly to changing technologies. With this structure, a variety of software tools can interoperate and organizations can establish metrics to monitor system use and data sharing between internal departments or external agencies.
Service-oriented architecture (SOA) is a technique for building software applications that allows loose links between components so they can be reused and information can be shared. According to Jan Popkin, chief strategist for Telelogic, a New York City-based developer of enterprise architecture and business process products, SOAs provide organizations with added levels of detail and flexibility for data. They also permit users to plan the interconnectivity between decision support systems and the various levels in a firm or agency.
By accessing information through applications such as decision support systems, SOAs can broadcast data across an organization’s many levels. An SOA permits the creation of management or executive information views in addition to operational and technical perspectives. “The SOA provides the kind of information that you can reuse and exchange and then potentially move it up to help at higher levels. Besides reconfigurability, interoperability and multivendor play, it offers the opportunity to repurpose information,” Popkin says.
SOA systems also provide decision-support applications by connecting data feeds. “As an organization, I want to operate the system or business process—or taxpayer service—and along the way, I want some metrics and information to provide decision support so I can make good decisions today and in the future,” he explains.
But SOA deployments in the commercial and civilian government sectors are still in their early phases. Popkin notes that the original intention behind SOA was to have multiple vendors and external entities communicating with each other. Although it is an emerging capability, he believes that companies and government agencies are sticking to much of the original intent for SOA. However, the technique has not extended to information sharing between different organizations. “Rather than building new business entities, they are exchanging information in a collaborative fashion. I think it’s more internal and information flow-oriented rather than a full SOA interaction,” he says.
Popkin defines SOA as loosely coupled services interacting to provide an application or a capability. This approach is different from client-server architectures, which use large Windows or Unix clients to communicate with server applications on fast local area networks. SOA products are available from commercial vendors such as Microsoft, IBM, Sun, and Oracle.
At its heart, the SOA design permits services to interact and to disseminate data. He notes that the term “loosely coupled” refers to slow or fast data exchange. “You can ask for information and get it back instantaneously, but it generally means in some time frame that could include tomorrow, depending on the needs of the application,” he says.
Linking services across many applications and vendors breaks with conventional architecture design because it allows interaction without requiring users to care about the sources behind the service. SOAs can be either commercial or support applications, and they can provide interoperability across systems, either in civilian or U.S. Defense Department environments. But SOAs require standards for multiple vendors to cooperate.
According to Popkin, two of the best-known SOA standards are the simple object access protocol (SOAP), which standardizes data calls between applications, and the business process execution language (BPEL), which is a variant of Extensible Markup Language (XML). He adds that groups that are developing the standards are still working on regulating how different applications interact. “Some of the standards are well understood, and some of them in BPEL are still evolving. It’s not like we’re done in the standards world. We have many things that work, and some things are still under discussion,” he says.
However, many vendors have agreed upon a general SOA framework that is now available. Users building new systems may design them around the architecture, whereas those with legacy systems can “wrap” them by putting an SOA service interface over them. Popkin notes that this type of structure may become fairly common because many available applications must interact with other software but are not ready for a code rewrite or reimplementation.
From an enterprise architecture perspective, the SOA allows designers to consider other issues besides information technology requirements. Administrators can ponder the business aspects of an architecture such as manual work, authorizations, regulations and data movement. Popkin explains that many enterprise architecture components and SOA aspects fit together because they encompass more than the immediate technology structure.
Popkin cautions that at higher system levels, the architecture may require additional capabilities. Because it is meant to loosely connect multiple vendors, a new concept of agile and reconfigurable applications and services must be considered. For example, the SOAs can provide these flexible attributes if a customer requires a system reconfiguration to meet changing needs. “Without rebuilding everything, you can reconnect things or add new services that provide additional services that are part of the business or operations model,” he explains.
But planning is required to make these reconfigurable systems work, which is where architecture considerations become important, Popkin maintains. The SOA manages a network’s information technology component, while standards such as the BPEL operate below this level and allow the system to implement. But at the architecture’s higher levels, a blueprint is needed to determine which applications communicate with each other. Because an SOA is not a monolithic application, designers must carefully identify essential services in their planning, he notes.
SOAs differ from well-designed monolithic applications because the SOAs’ overarching design blueprints are collaborative and allow for configuration and reconfiguration. Popkin explains that if a network were described as the blueprint for a building, one floor of that structure could be generic and reconfigured in different ways. But to do this, an architect must know where underlying infrastructure such as power outlets and air conditioning ducts are located. Careful planning also indicates the underlying infrastructure points for use in future system configurations.
Some SOA applications are not new. Popkin notes that systems have been connected in the past, but that these were linked with standards such as XML to provide the syntax. New standards such as the BPEL feature an execution language to describe the architecture. Rather than building many individual connections, the standards and the SOA architecture allow existing links to be reconfigured for future growth. “We are trying to do the one connection we need today and to allow for the two, three or four end connections we may need in the future,” he says.
Differences also exist in how enterprise architecture and an SOA are discussed by industry and civilian government as opposed to how the Defense Department discusses them. The civilian aspect concerns connecting systems, while military SOA use is for support services such as purchasing equipment and moving data.
Another aspect is enterprise system engineering, which is common in the aerospace and defense worlds. Popkin explains that because the government has its own requirements, it uses its own standard—the Department of Defense Architectural Framework (DODAF)—to achieve an SOA. The DODAF is a multiyear effort to develop an architectural framework for a common vocabulary to assign rules in a system, to compare architecture and to provide a road map. He adds that the
Both the commercial world and the Defense Department use an SOA to build agile, robust, interoperable and collaborative networks. The commercial and military sectors also rely on enterprise architecture, which is closely related to SOA. He observes that while aerospace and defense groups approach an SOA from the aspect of enterprise system engineering, the commercial and civilian government organizations approach it from a framework and information technology planning perspective.
But building agile and configurable SOAs calls for a balance between creating a system that meets an organization’s current needs and providing for future growth. The wrong combination of capabilities means that an organization may have a system that could be highly reconfigurable but is never completed. “Getting it right means you have an existing system now that can be reconfigured over time at some expense,” he says.
Popkin explains that another important consideration is selecting the right services at the right levels. “When you’re going to an agile, reconfigurable network, there needs to be real architectural thinking about what services are useful now and in the near future. Chosen well, you get a configurable system that has some agility to it over time and serves the current purpose. Chosen wrong, you’ve basically put in a lot of details that are not interesting or are at such a high level that it’s not useful. You have to have the right levels of connectivity that are applications explicit and are meaningful to the taxpayer service or the operational needs of the service you are dealing with,” he maintains.
Organizations are challenged with getting configurable systems built to meet their current needs within time and budget limits. They must sculpt their requirements to meet their long-term information technology plans. But he confides that these priorities must be set above specific industry standards because it may imply to outside users that they must connect to a particular product, which is not the goal.
A final issue is selecting the right level of configurability and services so the system does not require major upgrades in the future. Popkin observes that these considerations compel users to seek an operational level that is not too high or too low. “That requires some architecture and some thinking, and therefore there’s a bit of investment up front,” he says.
Web Resources
Introduction to Service-Oriented Architecture: www.onjava.com/pub/a/onjava/2005/01/26/soa-intro.html
Web Services and Service-Oriented Architecture: www.service-architecture.com
