Patterns: A Common Vocabulary for Information Technology Professionals

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Patterns: A Common Vocabulary for Information Technology Professionals

Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0

Microsoft Corporation

patterns & practices Developer Center
Web Service Security: Home
December 2005

Download	Download this guide in PDF format
Community	Web Service Security Community Workspace [Content link no longer available, original URL:https://go.microsoft.com/fwlink/?LinkId=57044]

Contents

Overview
The Challenge
The Solution
Conclusion and Recommendation
More Information

Overview

In the last decade or so, Microsoft and its competitors have focused a lot of attention on finding better ways to capture, persist, and organize information gained through analysis of data, so that knowledge can be shared effectively between people.

Early knowledge management solutions focused on capturing knowledge in documents and providing access through rudimentary tagging and search mechanisms. Over time, more sophisticated solutions have evolved that incorporate advanced collaboration technologies alongside sophisticated tools that generate taxonomies for the knowledge in an organization.

This paper demonstrates the need for the Information Technology industry to focus on establishing a similar knowledge management solution to increase the effectiveness of communications among software engineers including architects, software designers, developers, and testers. Such a solution will increase the effectiveness of application development, and will also increase our ability to communicate clearly and consistently within large organizations and across organizational boundaries.

The Challenge

Communication across large organizations is difficult. Some key factors are organizational, cultural, time and geographical. For software engineers in particular, the problem has increased over time due to the lack of a single, standard mechanism for persisting knowledge about proven software designs which has often resulted in, at best, inconsistent reinvention of the wheel, and at worst, overlapping or duplicated functionality.

It is interesting to note that these symptoms are similar to those facing knowledge workers in organizations without sophisticated knowledge management solutions. Workers duplicate efforts, quality is compromised through inconsistent analysis, and the organization is less able to leverage agility to its competitive advantage.

Due to the similarity of these symptoms our hypothesis is that a similar solution to the one that is currently being deployed for knowledge workers is required for architects and developers.

The Solution

The solution is a knowledge management solution for software engineers. Such a solution should incorporate the following capabilities:

• A standard notation for describing proven architectural designs that incorporates information such as when the design is applicable, tradeoffs associated with using the design and a solution that is reproducible.
• A standard vocabulary to describe architectural designs.
• A searchable repository for publishing, sharing, and locating architectural designs.
• A layered model for describing taxonomies of architectural designs, including support for composite designs.
• A means of incorporating architectural designs, and models based upon those designs, into integrated development environments such as Visual Studio.

In the last few years, the IT industry has thought about many of these capabilities and has developed solutions with various degrees of acceptance. The Microsoft patterns & practices team is also working on a set of solutions to each of these challenges with the goal being to contribute to the development and adoption of a common vocabulary across the IT industry.

We will briefly describe individual solutions that are available with the goal being to encourage and increase adoption of patterns as a standard means of communicating architectural designs.

A Standard Notation for Designs - Design Patterns

Patterns provide an effective means of communicating best practices for solving recurring design challenges. Patterns use a template that incorporates a pattern name, the context in which the pattern exists, a description of the problem the pattern solves, a solution to the problem, and consequences or tradeoffs that arise from using the pattern.

In the IT industry we often remark how similar a problem is on latest technologies to something we solved a decade ago on technologies long since retired. A good example of this is the way in which we used to design CICS applications on a mainframe–an approach called pseudo-conversational development was a primary design pattern for building scalable CICS applications. This varied from the conversational (and significantly less scalable) equivalent used within the TSO environment on a mainframe.

The conceptual lessons learned from the mainframe are just as applicable to development in .NET and J2EE. In fact, had our industry standardized on a standard vocabulary for describing such problems 20 years ago it might be simpler to transition developers from the mainframe to newer technologies. At minimum the issues surrounding how state and connections should be maintained in scalable online application would have been better understood and resulted in a lot fewer eCommerce organizations experiencing outages due to poor resource management when their applications experienced spikes in traffic.

A significant benefit from using design patterns is their inherent longevity–in many cases architecture and design patterns outlast the platform upon which they were first described. The Microsoft patterns & practices team deliberately separates the implementation of patterns from the corresponding architectural or design patterns that they implement. This allows the implementation to be demonstrated on multiple products (for example, .NET Enterprise Services, WCF, and BizTalk) and allows the implementation to be replaced as our technologies evolve (for example, from WSE 2.0 to WSE 3.0 to WCF to...).

It is difficult to measure the success of a design pattern or even patterns-based guidance. Consider the impact that the original Design Patterns: Elements of Reusable Object-Oriented Software book has had on the software industry, were it measured in terms of actual sales it would probably be considered moderately successful–but would never appear on a New York Times best seller list. Now, consider how frequently you hear software engineers, often working in different teams, organizations, or geographic locations, describe solutions to problems by referencing patterns such as the Façade or Abstract Factory–and you get some insight into the value of patterns and their importance as part of the software engineering vocabulary.

A Standard Vocabulary - Pattern Languages

Design patterns are named so that the solutions they encompass can be communicated and discussed with clarity. Over time, the names establish a common understanding of the key characteristics of their implementation, just as has been the case for algorithms such as Bubble Sort and Quick Sort.

There is an emerging trend for design patterns to be created as a group to help establish vocabulary within a particular domain. Gregor Hohpe's Enterprise Integration Patternsis a good example–it provides a common vocabulary for architects focusing on integration and messaging.

People often reminisce about similarities between technologies that are prevalent for developing distributed applications. This may or may not be true, but imagine how much simpler it would be to move developers from J2EE, CORBA, and COM+ to .NET and SOA if all distributed applications had a common understanding of key message exchange patterns and an understanding of the roles and responsibilities of key concepts, such as the naming service, the stub, skeleton, and even IDL. Sure, new messaging patterns would emerge as our technologies evolve, but these patterns would build off a well established base reducing the learning curve and expediting adoption of new technologies.

The Microsoft patterns & practices team has been working on a series of architecture and design patterns focused on the domain of service orientation. The first release establishes a vocabulary around Web service security, with future releases aimed to focus on messaging and data consistency. If used effectively, such a vocabulary allows underlying products to change, while still helping developers to understand core concepts that need to be addressed by each pattern.

Figure 1. Patterns of Service Orientation

A Layered Model - The Pattern Frame

As described earlier, the ability to describe architectural and design level challenges independent of their implementation allows the patterns to truly transcend the life of a particular product. A great example of this is provided by the original Design Patterns: Elements of Reusable Object-Oriented Software design patterns - they initially provided implementations in C++, but all of these patterns have since been implemented in C, SmallTalk, Java, C#, and Visual Basic. NET.

The organizational frame used within Microsoft's Enterprise Solution patterns provides a basic model that allows patterns to be organized not just by levels of abstraction - but also based on the area of technology with which the pattern is focused.

Figure 2. The basic model provided by Microsoft's Enterprise Solution patterns

Frequently, guidance to software engineers on the use of technologies is at the implementation level - which means that every time a technology changes, the guidance needs to change and software engineers have to relearn how to solve the same problem with new technologies. Focusing on architectural and design level guidance, and then showing implementations on particular products, is not only more efficient - it also establishes a group memory for software engineers.

A more sophisticated model has also been developed that allows organizations to describe enterprise architectures in terms of patterns - allowing for increased visibility into the organization's architecture and underlying relationships between systems. For more information on this model, see Describing the Enterprise Architectural Space.

IDE Integration - Guidance Automation Toolkit (GAT)

A critical aspect of empowering developers in using patterns as the basis for describing designs is to incorporate such patterns into IDE's such as Visual Studio. As mentioned earlier, this is important for enterprise developers who are often more capable of addressing complex business problems (such as how to calculate housing loan interest rates) than they are at solving complex technical challenges (such as ensuring a password stored within a database is stored using an appropriate hashing mechanism).

The Guidance Automation toolkit, developed by patterns & practices, is an extension to Visual Studio 2005 that allows architects to author rich, integrated user experiences for reusable assets including frameworks, components and patterns.

A pattern such as Direct Authentication, which simply describes how a client and a service can authenticate using a shared secret, can appear trivial at the surface. However, when you consider aspects such as: how to ensure the shared secret is stored in a database in a secure (hashed) format, how to hash the shared secret, whether to hash it on the client or the service and what the implications are for securing the message–you get some idea of why a pattern describing what the associated best practices are, is valuable.

If you then examine the number of factors that you need to consider when implementing such a simple solution–for example, a custom UsernameToken manager, a custom hashing algorithm, WSE 3.0 security policy and modifications to the Web.config file and associated Web service interface–it becomes clear why patterns and their implementations in Visual Studio are so important.

Figure 3. A prototype of GAT based guidance

Figure 3 is a prototype of GAT based guidance that has been developed to accompany the patterns & practices Web service security pattern's initiative. For more information, join the Web Service Security community workspace [Content link no longer available, original URL:https://go.microsoft.com/fwlink/?LinkId=57044].

Conclusion and Recommendation

A pattern based knowledge management solution will allow software engineers to start capturing proven software designs and reusing them across organizations. The pattern language that naturally emerges from such a solution will also, over time, form a technical vocabulary that will increase effectiveness of communications - not just across teams within an organization but also across our industry - resulting in better communication, increased productivity and of course better quality.

The capabilities presented within this paper already exist in varying degrees of maturity. In some cases the capabilities have existed for at least a decade, and in others the capabilities exist only as prototype work within the Microsoft patterns & practices team. To truly reap the benefits of a unified knowledge management solution for software engineers, all of these capabilities must be considered collectively.

Author: Jason Hogg, Microsoft Corporation

Reviewer and Editor: Paul Slater, Wadeware LLC

Reviewers: Per Vonge Nielsen, Edward Jezierski, David Trowbridge, Matt Deacon, Microsoft Corporation; Ward Cunningham

More Information

Hohpe, Gregor, and Bobby Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Reading, MA: Addison-Wesley Professional, 2003, ISBN: 0321200683.

Enterprise Solution Patterns Using Microsoft .NET, Redmond: Microsoft Press, 2003, ISBN: 0735618399. Also available on MSDN.

Web Service Security: Scenarios, Patterns, and Implementation Guidance community workspace [Content link no longer available, original URL:https://go.microsoft.com/fwlink/?linkid=52393&clcid;=0x409].

Describing the Enterprise Architectural Space.

Gamma, Eric, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Reading, MA: Addison-Wesley Professional, 1995, ISBN: 0201633612.

Buschmann, Frank, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal, Pattern-Oriented Software Architecture, Volume 1: A System of Patterns, Hoboken, NJ: John Wiley & Sons, 1996, ISBN: 0471958697.

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.