In the past, network-based applications were pretty simple. A networked server ran a monolithic application that users accessed via a basic GUI (graphical user interface). Today, organizations struggle to develop feature-rich, network-based applications while also facing business pressure to minimize timescales, maximize quality, and work with legacy systems hosted on different platforms.

To address these challenges and meet business needs, organizations are simplifying application development through reuse supported by Service-Oriented Architecture (SOA). SOA describes an architecture that provides access to, and reuses services transparently across a network. With SOA, services are developed once and accessed by future development via the network across what is known as an Enterprise Service Bus (ESB).

Reuse with SOA reduces cost, simplifies application development, increases business agility, and improves quality. For example, many different applications within an organization can access a central directory system through a single service, eliminating the effort of building point-to-point connections between every application and the directory back end. Over time, the services develop into a complex architecture of interconnected components working together to satisfy many different business needs.

While SOA has been realized in many ways, today Web services are the most compelling way to deploy applications. Web services are based upon open standards (so they are vendor-neutral) and are firewall friendly.

Some Brief History

Figure 1. An example of Tau automatically marking (with a red underline on the diagram) a mistyped reference to the AccountRecord data structure definition.

In the early days of software development, a single monolithic software application delivered the needed functionality. Later, dynamic link libraries (DLLs) or shared libraries could be loaded once and shared (i.e. reused) while the application was still running; reuse was limited to the same processor. To retrieve data at near-real-time speeds and to avoid enforced centralization of this data, technologies such as CORBA and DCOM were developed to allow access to information and services across a network. Applications could be developed in different languages (e.g. one in C++ and another in Java) with these technologies serving as a common protocol to bind the applications. Software applications had to conform to each specific network's data protocol and format. However, these were largely proprietary to the technology owner, and usually were not easily shared with other applications or organizations.

Web services address these issues by building on open standards such as TCP/IP, HTTP, and XML. Because Web services are simultaneously vendor-neutral and firewall friendly, they remove the final emotional and technical barriers to service-enabling the IT infrastructure in businesses. All that remains is to devise a methodology to implement Web services in a formal and consistent manner, which leads us to the idea of an SOA repository.

Applying SOA in the Enterprise

SOA provides a conceptual solution, while Web services and ESB fulfill the technical or implementation solution, but there remains a large gap between the concept and the implementation. For example, the evolving architecture of interacting services must be carefully managed to avoid fragility or chaos that would threaten the entire business. The SOA repository fills this gap by providing a single place to capture a definition of the architecture and by allowing users to browse, search, and update the architecture to enable reuse.

The SOA repository must satisfy some requirements:

  • Reuse has to be actively promoted. The specifiers and developers of new applications must be able to easily and consistently find the reusable services, reference them in new services, and publish these new services into the service repository alongside the existing ones.
  • The repository must manage formally all the architectural information. A traditional relational DBMS is not necessarily the best way to represent the collaborative and evolutionary nature of an SOA, yet its data query and management capabilities are ideally suited to these needs.
  • The repository must promote correctness. Developers need the repository to provide checking and validation with minimal effort on their part.
  • The repository must support the organization by minimizing the need for training and changing the working environment for skilled staff. It should be standards-based and customizable to the organization's terminology and strategies.
  • The repository should graphically represent the architecture to simplify both specification and understanding.

A Repository Solution

Figure 2. A customized ‘Service Dependency Diagram’ provides only the symbols needed to populate it.

In the past, the distribution of shared information often has been achieved through an intranet Web portal. The source of information for the portal is a combination of textual documentation and the expertise of technical authorities in the organization. To meet the requirements of SOA, however, a new form of repository must be considered.

One approach to a repository capitalizes on the formality and structure of a standardized and formal model-driven language such as UML 2.0. This approach is called a Model-Driven Repository (MDR). UML 2.0 products that support formal model-driven development (MDD) allow developers to work at a higher level of abstraction while offering the benefits of graphical presentation and automatic checking. This higher level of abstraction hides details and provides users with role-specific views of the model. Advanced UML environments, such as Telelogic Tau, provide users with the ability to iteratively validate and verify the design at each stage of development, thus ensuring that designs adhere to the specifications and enabling users to detect errors early in the lifecycle.

Checking & Governance

It is common for UML tools to rely on code-generation and even external compilers to provide many error-checking facilities; however, designers do not always generate code when modeling architectures. Placing a requirement for code-generation on the architecture development process simply to enable this type of error-checking would be a prohibitive overhead. The important message here is: pay attention to the checking mechanisms provided by your UML environment to make sure they fit your process (see Figure 1).

To provide the level of error-checking required by your organization's process, Tau can be customized by selectively disabling built-in checks or by defining new ones. For example, if the specification of a new service must be driven by formal requirements, it will probably be helpful to define a custom check that reports all service operations that are not traceable to formal requirements.

An SOA repository also helps ensure compliance with the organization's architectural strategy by constraining the modeling concepts available to repository users. In UML terms, this entails developing a custom UML profile, which restricts the available model diagrams and elements to those designated by the lead architects. In addition, a profile can provide custom diagrams and symbols, based on the underlying formal UML model. When using Tau with such a profile, the symbol toolbars are limited to the profile's restricted/customized symbols, so there is a direct relationship between the domain-specific SOA concepts and the design elements used to model them (see Figure 2).

Some repository users may need to extract information by searching or browsing. These needs may be best satisfied by a more conventional access method such as an intranet portal. In this case, the repository must also support the extraction of information to support the portal, and the textual information can be enhanced with the diagrams extracted from the MDR.

An Expanded Services Lifecycle

One of the significant advantages of an MDR over a conventional textual repository is that the model can provide additional value later in the lifecycle. For example, during the coding phase, the same model is the basis for generating the application's final source code in the developer's choice of C#, C++, or Java; this guarantees consistency with the architectural specification. Since very few of today's SOA projects start entirely from scratch, the developer can adapt existing applications to an SOA approach.

Finally, as service definitions are pulled from the repository and referenced by a newly modeled service, the designer can simulate the new service's functionality by "running" the model. Executable models allow users to verify conformance to the project's requirements by detecting and resolving performance/security trade-off conflicts early in the design process.

The Bigger Picture

Finally — and with a broader perspective — it is important to remember that the MDR is just one piece of the jigsaw. There are other essential pieces and other important issues. For example, compliance requirements such as Sarbanes-Oxley are driving businesses to demonstrate traceability from high-level business needs often expressed as Key Performance Indicators (KPIs), through to detailed activities such as software development and Web site deployment. Requirements management tools such as Telelogic DOORS can automate many of the previously manual activities involved in documenting and demonstrating this compliance by capturing traceability relationships across all levels of the business, and providing management and reporting facilities. Of course the SOA repository must be compatible with these needs such as traceability and configuration management.

Today, businesses need increasing complexity in their enterprise systems with quicker roll-out and increased quality. Development teams have to respond by evolving new approaches to delivering success. The use of simple textual documents for specifying architecture and cataloging services is a dead end: Manually-produced documents are expensive to write initially, are liable to human-introduced errors, cannot be automatically checked for errors, and are quickly outdated so their value reduces rapidly. In addition, informal documents cannot deliver productivity enhancements later in the lifecycle.

Specifying and managing architecture using an MDR introduces formality and propagates automation across the entire development cycle. An MDR promotes "approved" techniques, and minimizes the training required to adapt to the new paradigm. When using advanced UML products like Telelogic Tau as the basis of the MDR, users can test the architectural design by executing it to verify compliance with requirements.

SOA and Web services have significant potential to help development teams build applications that meet business needs. However, realizing this potential requires that these teams embrace more than just the underlying technology; they must also change their processes for developing and managing their application architecture in more formal ways.

This article was written by Ian Barnard, Principal Professional Services Engineer, and Scott McKorkle, Director of Product Marketing at Telelogic, Irvine, CA. For more information, contact Mr. McKorkle at This email address is being protected from spambots. You need JavaScript enabled to view it., or visit .