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.

Click to enlarge

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).