- Separation of corcerns
- Architectural views
- Accommodation of change (flexibility)
- Abstraction
- Consistency
- Business derivation
- Facilitation
- Communications
Important Parts of Architecture
- Processes (high-level business functions, often spanning applications or LOBs)
- Services (Modular units of business functionality)
- Integration (Connection to and exposure of existing applications and/or data as services
- Existing systems ( Existing legacy systems, commercial COTS applications, and data that the enterprise wants to leverage
- Documents (high-l.evel units of business information, such as a purchase order, or an EDI document
- Semantics (the underlying meaning of information that is exchanged in processes)
- Transformation (the conversion of information from one format or semantic to another)
- Communications (the ability of services to communicate with each other)
Layered SOA architecture
- Business Process (Enterprise Data [Documents])
- Business Services (Consolidated Data [Semantic Objects])
- Integration Services (Integration Data [Transformation])
- Enterprise Resources (Operational Data [SOR])
SOA aspects of services within an enterprise
- Defining a Service (domain, business, enterprise business process etc.)
- Defining How Services Are Built and Used (Granularity, Type or style of interface, Configuration mechanisms, Other artifacts, Associated information, Dependency management and other patterns)
- Integrating Packaged and Legacy Systems into the Service Environment
- Combining Services into Enterprise Processes
- Specifying the Technology Infrastructure (Communications mechanism, Failover mechanisms, Discovery and location transparency)
- Defining Common Semantics and Data
- Aligning Services with the Business
- Determining How to Use the Architecture
EA and SOA Compared
Business Architecture <-> Business Model
Information Architecture <-> Common Semantics and Data
Technology Architecture <->Service Bus (infrastructure, distributrion, binding, security, performance, etc)
Application Architecture <-> Service, Data, Integration Service, Enterprise Business Process
Software Architecture (4+1 Views)
- Logical View (abstract, platfor, and technology-independent)
- Component View (organized arougn services or service groups)
- Process View (how artifacts assigned to executable processes)
- Physical View (machines, programs, network nodes, hosts, etc)
- Use Cases (in the middle) (capabilities of the system envisioned by end consumer)
Service Contract Includes:
- Service interface
- Interface documents
- Service policies
- Quality of service (QoS)
- Performance
Good Service Characteristics
- Modularity and granularity
- Encapsulation
- Loose coupling
- Isolation of responsibilities
- Autonomy
- Reuse
- Dynamic discovery and binding
- Stateless
- Self-describing
- Composable
- Governed by policy
- Independent of location, language, and protocol
Levels of Granularity
- Enterprise business processes
- Business services
- Domain services
- Utility services (lower-level services that provide common functionality across the enterprise)
- Integration services (expose existing applications as services)
- External services
- Foundation services (fine-grained capabilities used in higher-level services)
Service Dimensions
- Scope
- Ownership
- Granularity
- Construction
Service Types
- Task services
- Entity services
- Decision services
SOA Reference Architecture
SOA Implementation Methodology
*Business Processes
- A group of logically related (and typical sequenced) activities that use the resources of the organization ot provide defined results.
*Information Design
- The semantic data is not the same as the domain data. It defines the information that must be common between processes.
- The semantic information model defines the messages exchanged by services.
- It is possible to introduce the notion of passing the service execution context around as part of the service invocation "thread". In this case, the service interface operations are massively polymorphic and expressed as:
Service.method (XML context in, XML context out)
*Service Identification
- Instead of attempting to decompose applications, it decomposes entire enterprise IT functionality
- A better decomposition approach is based on the decomposition of the enterprise-wide business model
*Service Specification
Business users need to understand what a service does in business terms, which requires answers to the following questions:
- What does the service provide for prospective clients? This includes a description of what is accomplished by the service, limitations on service applicability and quality of service (QoS), and requirements that the service requester must satisfy to use the service succssfully
- How is the service used? This includes a detailed definition of the content of service requests and responses, the conditions under which particular outcomes occur, and, when necessary, a step-by-step description of processes leaing to those outcomes
Technical users need to know how to implement service operations that require answering the following questions:
- How the interact with services? This specifies a communication protocol, message formats, including serialization techniques and service locations
- What are the service invocation policies? This defines specific requirements for service invocation, (security, SOAP headers, etc)
- What are service QoS guarantees? This specifies the quality-of-service characteristics that the service provides, including response time, throughput, availability, planned maintenance, etc
Service Expectations
Interaction Model
- Information model
- Process (behavioral) model
- Service execution model
Service Constraints
- Business-oriented policies (hours of operation, return policies, etc)
- Infrastructure-oriented policies (security, privacy, manageability, performance, etc)
Service Location
*Service Realization
- Buy
- Outsource (rent)
- Build
Buying Services
- Functional alignment with the overall business model, service decomposition, and service inventory
- usage of the enterprise semantic information model for service interface definitions
- Support for the enterprise service infrastructure, including security, logging, exception handling, and so on
Outsourcing Services
- Designed foruse by customers through the Internet
- Hosted off-premises, not on the customer's premises
- Governed by a service contract
Two common approaches to incorporating SaaS into an overall SOA
Building Services
- Service Component Architecture (SCA)
- SCA specifies how to create components, combine them, and expose the component assembly as a service
- SCA defines a common assembly mechanism to specify how those components are combined and exposed as a set of services
Service implementation concerns
Service Life Cycle
1. Service identification
2. Service design and specification
3. Service implementation
4. Service deployment
5. Service usage and enhancement
6. Service retirement
SOA Governance includes
- Policies regulating service definition and enhancements, including ownership, roles, criteria, review guidelines, etc
- Identification of roles, responsibilities, and owners
- Policy enforcement that is integrated directly into the service repository (where appropriate)
- Guidelines, templates, checklists, and examples that make it easy to conform to governance requirements
- Review of service interface definitions fornew services and enhancements to existing services
- Architectural review of applications and services to ensure that they conform to the SOA and EA
*The Service Design Process
Top-Down Approaches
- Enterprise System Analysis
- Business Process Model
Bottom-Up Approaches
- Utility Services
- Service Enabling
Middle-Out
- Business Summary (Activities, Artifacts, Repositories, Governance)
- Process Phases (Architectural Context, Business, Desing, Implementation, Test)
Posts
No comments:
Post a Comment