Design Principles

Get Started. It's Free
or sign up with your email address
Design Principles by Mind Map: Design Principles

1. Service Composability

1.1. Goals

1.2. Terms

1.2.1. Composition (Instance)

1.2.2. Composition Member

1.2.2.1. Composition Member Capability

1.2.3. Composition Controller

1.2.3.1. Sub-Controllers

1.2.3.2. Composition Controller Capability

1.2.3.3. Designated Controllers

2. Service Reusability

2.1. Goals

2.1.1. High ROI

2.1.2. Increase business agility

2.1.3. Enable agnostic service models

3. Service Autonomy

3.1. Goals

3.1.1. Increase runtime reliability, performance, predictability

3.1.2. Increase control

3.2. Types

3.2.1. Runtime Autonomy

3.2.1.1. Execution performance

3.2.1.2. Reliability

3.2.1.3. Predictability

3.2.1.4. Security control

3.2.2. Design-Time Autonomy

3.2.2.1. Scalability

3.2.2.2. Enhance hosting environment

3.2.2.3. Change technology

3.3. Levels

3.3.1. Service Contract Autonomy

3.3.2. Shared Autonomy

3.3.3. Service Logic Autonomy

3.3.4. Pure Autonomy

4. Service Statelessness

4.1. Goals

4.1.1. Increase scalability

4.1.2. Improve service reuse

4.2. Types

4.2.1. Active

4.2.1.1. Stateless

4.2.1.2. Stateful

4.2.1.2.1. Session data

4.2.1.2.2. Context data

4.2.1.2.3. Business data

4.2.2. Passive

4.3. Levels

4.3.1. Non-deferred State Management (low-to-no statelessness)

4.3.2. Partially Deferred Memory (reduced statefulness)

4.3.3. Partial Architectural State Management Deferral (moderate statelessness)

4.3.4. Full Architectural State Management Deferral (high statelessness)

5. Service Abstraction

5.1. Goals

5.1.1. Keep the contract detail concise and balanced

5.2. Types

5.2.1. Technology

5.2.2. Functional Capabilities

5.2.3. Programmatic Logic

5.2.3.1. Internal details

5.2.3.1.1. Design

5.2.3.1.2. Source code

5.2.4. Quality of Service

5.2.4.1. SLA

5.2.4.1.1. Concurrent threshold

5.2.4.1.2. Availability limitations

5.2.4.1.3. Business Rules

5.3. Measuring

5.3.1. Contract Content Abstraction Levels

5.3.1.1. Detailed

5.3.1.2. Concise

5.3.1.3. Optimized

5.3.2. Access Control Levels

5.3.2.1. Open Access

5.3.2.2. Controlled Access

5.3.2.3. No Access

6. Standardized Service Contract

6.1. Goals

6.1.1. Natural operability

6.1.2. Less data transformation

6.1.3. Capabilities are better understood

6.2. Design Characteristics

6.2.1. Service contract provided

6.2.2. Standardized through design standards

6.3. Implementation requirements

6.3.1. Design standards and conventions

6.3.2. Formal processes for service modeling

6.3.3. Contract first approach

7. Service Loose Coupling

7.1. Goals

7.1.1. An environment where Services and Consumers can evolve with minimal impact

7.2. Coupling Types

7.2.1. Logic-to-Contract

7.2.1.1. "Contract First"

7.2.2. Contract-to-Logic

7.2.3. Contract-to-Technology

7.2.4. Contract-to-Implementation

7.2.5. Contract-to-Functional

7.2.5.1. Parent Process Coupling

7.2.5.2. Service-to-Consumer Coupling

7.2.5.3. Functional Coupling and Task Services

7.2.6. Consumer-to-Implementation

7.2.7. Consumer-to-Contract

7.2.7.1. Coupling Levels

7.2.7.1.1. Non-Centralized

7.2.7.1.2. Centralized

8. Service Discoverability

8.1. Goals

8.1.1. Highly discoverable services

8.1.2. Purpose and capabilities clearly expressed

8.2. Types

8.2.1. Design-Time discovery

8.2.2. Runtime discovery

8.2.2.1. UDDI

8.2.3. Discoverability Meta Information

8.2.3.1. Functional

8.2.3.2. Quality of Service