Types of Services
- Mark Skilton
- Nov 15, 2007
- 2 min read
Notes on current ideas and reading on service granularity explanations
Types of services
Presentation services (usability services)
Executable Business Processes
Composite services
Atomic services (IT Services)
Infrastructure services
SOA Governance
Alignment of domains of change
Definition of SOA Governance (from traditional governance)
Service Lifecycle
SOA Governance Lifecycle
Rules and tools
Skills and competences (doing what you can with what you have/can access)
Security
Service behaviour (collaboration)
The total enterprise lifecycle
Strategy and Domains
Service partitions
Channels
Components
Service Facades/ Gateways
Integration points / channels
Service behaviour : Collaboration and interaction model of service
Service Definition
Service
Service consumer
Service producer
Service Specification
Service Contract
Architectural styles
Architectural patterns
Service architectures (SOA platforms)
IBM Redbook 12 patterns from JK Enterprises
Factor composition logic away from business process logic
How services combine could be ws. Bpel, fragments that involute. This logic is also encapsulated from the final use of the service or composite service in a business process sequence (business process logic)
Factor atomic reusable logic into lower reuse layers
Remove embedded logic in apps into service meta schemas. Decouple
Factor application specific logic out of reuse layers
Private application components maintained inside blackbox
Base architecture on business relevant things
Service behaviour (collaboration)
Service portfolio (APER and dimensions of portfolios)
Manage complexity using SO systems
APER etc. Good SOA design moved variability into the service layer
Derive atomic services from a domain model
Use data domain class types as a way of defining partitioning
Incrementalism
Boundary management
Service enable non-SO systems
Wrap, migration
Model data ownership
Payload and semantics, structured, semi-structured and un-structured combinations
Keep service operation signatures meaningful
Keep operations as meaningful as possible
Avoid modelling operations as a request-response message pair
Use meaning parameter types gained from the data domain class model(use data classes to describe operational context)
Name parameters helpfully e.g. newCustomer: Customer for the createCustomer operation
IP, URLs semantics choices
Keep architectural elements total decoupled
Use shared messages and parameter types
Drive applications using business processes
The differences between principles, policies and patterns
Principles are axiomatic approaches to design choices.
Policies are principles defined as edict choices to control choice selection
Patterns are solutions to common repeated problems
SOA Principles
Reuse
Agility
Flexibility
+20-30% commonality in business process steps
+50% commonality of applications
+30-50% Data reuse
+50% interface design for reuse
Service oriented – define the exchange of information between business and IT
Agnostic meaning - Canonical Information Management and Service operation defintion– define common logical language for reuse
Encapsulation - Service Contract – define interface exchanges as contracts
Pattern governance - Reuse – create managed IDE and SDM and ARB procedures.
Decoupled – design solution for business independent of IT framework – use services to decouple front and backend systems
Abstraction - split data, application business logic and presentation into service layers
Composition – Develop a registry of services. Create standards for agile reuse
Community – design for communities of service consumers and producers – not point to point
Federation flexibility – Secure Service Access – control security and design for end use access methods
Inheritance control - Service Version – create strong version management
Mark Skilton
Sydney, Australia
Nov 2007
Comments