top of page

Types of Services

  • Writer: Mark Skilton
    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


Featured Posts
Recent Posts
Archive
Search By Tags
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square

Mark Skilton    Copyright 2019  ©

  • White Twitter Icon
  • White Facebook Icon
  • White LinkedIn Icon
  • White YouTube Icon
  • White LinkedIn Icon
bottom of page