1	Design Patterns are …
2	Design Patterns Design patterns are known solutions for common problems. Design patterns give us a system of names and ideas for common problems.
3	Design Patterns Levels and Types Levels: Types:
4	Design Patterns Levels and Types There are different types and levels of design patterns. For example, the MVC is the architectural level of design pattern while the rest of the patterns from the list above are component level design patterns. The basic types are Behavior, Creational, Structural, and System design patterns. Names are extremely important in design patterns; they should be clear and descriptive. More types: Enterprise and SOA Design Patterns
5	"What" What: Application development or even modification require longer and longer projects Why: Growing applications become more complex and rigid; too firm and inflexible in spite of the name – Software
6	Industry Lessons Learned Design Patterns Business-Driven Architecture How can technology be designed to remain in alignment with changing business goals and requirements?
7	Business-Driven Architecture Solution Business and architecture analysis is conducted as collaborative efforts on a regular basis Impact To keep technology in alignment with the business that is changing over time, it will require a commitment in time and cost to govern
8	Design Pattern - MVC MVC (Model – View – Controller) is well known pattern Name – MVC Problem – Complex object involves user interface and data. Need to simplify structure Solution – Data in one part (Model), user View in another part (View), interaction logic in a third part (Controller) Model maintains state. Notifies view of changes in state. Controller uses state information (in Model?) and user request to determine how to handle request, tells view what to display View must correctly display the state of the Model Consequences Allows "plug in" modules – eg. swap out Model to allow different ways of holding data Requires separate engineering of the three parts, communication between them through interfaces
9	Factory Method Problem – Need to create objects, object type depends on several factors. Objects are used in standard ways. Solution – Creator class has a "getter" method which instantiate the correct subclass (ConcretePrice) Subclass is used through generic interface (Price)
10	Factory-2 (Servlet Best Practices)
11	Design Pattern Canonical Data Model How can services be designed to avoid data model transformation? Problem Services with disparate models for similar data impose transformation requirements that increase development effort, design complexity, and runtime performance overhead.
12	Canonical Data Model Solution Data models for common information sets are standardized across service contracts within an inventory boundary. Application Design standards are applied to schemas used by service contracts as part of a formal design process.
13	Canonical Data Model Principles Standardized Service Contract Architecture Inventory, Service
14	Design Pattern Canonical Protocol How can services be designed to avoid protocol bridging? Problem Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.
15	Canonical Protocol Solution The architecture establishes a single communications technology as the sole or primary medium by which services can interact. Application The communication protocols (including protocol versions) used within a service inventory boundary are standardized for all services.
16	Design Pattern Concurrent Contracts How can a service facilitate multi-consumer coupling requirements and abstraction concerns at the same time? Problem A service’s contract may not be suitable or applicable for all of the service’s potential consumers.
17	Concurrent Contracts Solution Multiple contracts can be created for a single service, each targeted at a specific type of consumer. Application This pattern is ideally applied together with the Service Façade pattern to support new contracts as required.
18	Singleton Design Pattern Problem – need to be sure there is at most one object of a given class in the system at one time Solution Hide the class constructor Provide a method in the class to obtain the instance Let class manage the single instance public class Singleton{ private static Singleton instance; private Singleton(){} // private constructor! public Singleton getInstance(){ if (instance == null) instance = new Singleton(); return instance; } }
19	Provider Design Pattern Context Separate implementations of the API from the API itself Problem We needed a flexible design and at the same time easily extensible Solution A provider implementation derives from an abstract base class, which is used to define a contract for a particular feature. For example, to create a provider for multiple storage platforms, you create the feature base class RDBMSProvider that derives from a common StorageProvider base class that forces the implementation of required methods and properties common to all providers. Then you create the DB2Provider, OracleProvider, MSSQLProvider, etc. classes that derived from the RDBMSProvider. In a similar manner you create the DirectoryStorageProvider derived from the StorageProvider with its subclasses ActiveDirectoryProvider, LDAPProvider, and etc.
20	Adaptable Data Service for Multiple Storage Platforms Multiple storage platforms can be transparent The same basic data operations are implemented by connectors Data structure and business rules are captured in XML descriptors Design Patterns: Model, Adapter, Provider
21	Authentication Service Delegation, Façade and Provider Design Patterns
22	Authentication Service Provider, Façade and Model Design Patterns // read config & build application map on initiation AppsArray[] apps = serviceConfig.getApplicationArray(); // apps maps each application to its data source(s) -------------------------------------------------- // getRoles(appName, userName); AuthServiceDao dao = apps.getService(appName); // dao is one of types: LdapDao, AdDao or DbDao String roles = dao.getRoles(userName);
23	How Façade Design Pattern can help us to Improve Implementations of Internet Services, Increase Reuse and Remove Duplications
24	From Project-based code to Enterprise Services using Façade Design Pattern Internet Services Architecture Proposal
25	Enterprise Services will Shield Applications and Enable Changes from current to better Implementations
26	Design Pattern Delegate Problem Business logics is often customized on client requests creating maintenance pain
27	Delegate Solution Delegate changeable part of business logic to a special component, like a rules service, and simplify changing this logic. Check out the Reference Architecture: Focus on Service Layers document and find examples of using the Delegate and following Agnostic Context Design Patterns in the Target Architecture draft
28	Design Pattern Agnostic Context How can multi-purpose service logic be positioned as an effective enterprise resource? Problem Multi-purpose logic grouped together with single purpose logic results in programs with little or no reuse potential that introduce waste and redundancy into an enterprise.
29	Agnostic Context Solution Isolate logic that is not specific to one purpose into separate services with distinct agnostic contexts. Application Agnostic service contexts are defined by carrying out service-oriented analysis and service modeling processes.
30	Governance Connect System and Enterprise Architectures Connect Business and Technology Architecture Engage Teams in Collaborative Engineering
31	SOA with TOGAF Learn: TOGAF Intro TOGAF ADM Features to Support SOA
32	Why TOGAF & SOA? The Open Group Architecture Framework (TOGAF) TOGAF is a mature EA framework SOA is an architecture style Enterprises struggle to move to SOA TOGAF helps to describe EA and steps for SOA
33	Enterprise Continuum
34	Phase A: TOGAF General Views Business Architecture views Data Architecture views Applications Architecture views Technology Architecture views Baseline Architecture with New Architecture Templates
35	Mapping Business and Technology Views
36	Questions? Please feel free to email or call Jeff: 720-299-4701 We are looking for your feedback: what was especially helpful and what else you would like to know, and what are better ways to work together in a collaborative fashion