soa @ t-mobile – change- und configuration management hoch...

SOA @ T-Mobile –

Change- und Configuration Management hoch 5 oder

das Pentagon der T-Mobile

CMConf 2008, München, Andre Karalus & Carsten Sensler

Agenda

!! Prerequisites

!! SOA Backplane in a nutshell

!! 1. Challenge: The pentagon …

!! 2. Challenge: 2x4 = 8 != 2

!! 3. Challenge: Configuration Management vs. Model repository?

C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 2

Who we are?

!! Dipl.-Ing. Carsten Sensler

!! Employee of T-Mobile Deutschland GmbH since April 2007

(but since December 2005 working in the SOA Backplane

program )

!! Department of Enterprise Integration

!! System & Solution Designer

!! Functional leader of the international Service Provisioning

Team

!! http://www.sensler.de

!! Dipl.-Inf. Andre Karalus

!! Freelancer,

!! since March 2006 consultant for T-Mobile

!! Designer and developer of the runtime core component of

the ESB in SOA Backplane and of the Core from the Service

Repository


Prerequisites

Corporate Structure.

Subsidiaries and affiliates.

!!Direct or indirect investments by Telekom

Group in companies dealing with mobile communications in twelve countries

!!The T-Mobile brand is represented in

Germany, Austria, Hungary, Great Britain, the Czech Republic, the Netherlands, the

Slovak Republic, Croatia and the USA

!!Almost 125 million customers in the

majority holdings

Deutsche Telekom

T-Mobile International

Hungary

Mace- donia

Croatia

Slovak Republic

T-Mobile Germany

US

A

UK

NL

PL

CZ

Monte- negro

SOA Backplane Participant


SOA Backplane in nutshell

SOA Backplane – overview (simplified)


Business System(s)

Msgs.

SOAP –

JMS

Logs/

Status

WS/

others

Design time Runtime

Routing EMS

(Messaging, ESB)

Adapter(s)

Common Access

Layer (CAL)

Logs

Service

Repository

(CEISeR)

Config

e.g. Corba, Tuxedo,

JMS, …

Message-

/ Log-Store

(LMS)

Xplor

Provisioning time


. . . . . .

TMCZ TMUK

Adapter Adapter

. .

TMD

.

International System

Adapter Service

Repository

(CEISeR)

Central view

on

BAM, Logs & Monitoring

Intention of the SOA Backplane program

!! SOA Backplane will deliver a number of software systems and standards, namely

!! a service bus which is the SOA communication infrastructure

!! Service repository

!! Access layer framework

!! Basic messaging infrastructure (JMS)

!! additional value adding components and functionality including

!! logging, monitoring

!! service contract management

!! business activity monitoring

!! transport components for B2B communication

!! the Backplane Guide and SOA Governance as a set of guidelines and rules as to how SOA will be

implemented within T-Mobile.


SOA Backplane – Service Repository Interfaces

Imports

Authorisation &

contact

information

Technical

environment

definitions

Provider /

consumer

relations & SLA

Exports

Reports

SOA BP Service-

Repository

Tibco EMS

(JMS)

configuration

Common

Access Layer

artefacts

Deployment &

security

configuration

WSDLs *,

XSDs

Round trip is supported

* T-Mobile specific subset of

WSI basic profile 1.1

WSDLs *,

XSDs &

metadata

Xplor

(DSL editor)

internal external


The Service Repository in a nutshell

!! Provide all information needed by service participants for consistent service implementation

and utilisation (architecture)

!! Store definition of different SOA backplane environments and binding of service

participants to these environments (binding)

!! Support fully automated configuration of SOA backplane environments (dev, test, prod, …)

(service provisioning)

!! Support SOA governance (service discovery, reuse) and impact analysis (change / incident

contact information) (management)


SOA Backplane –

Common Access Layer (CAL) - ESB

Synchronous, Asynchronous Communication, Notification

Application

Document Literal

RPC Literal PlugIn

Application

XSLT PlugIn

Application

Binary protocol PlugIn Tuxedo Plug In

JMS invoker

JMS Bus

Socket invoker Http invoker

SOAP/JMS

CAL


Service Provisioning – in general

A. Karalus & C. Sensler, Version 1.3 13

Execute the

service

configuration

event via a job

from CEISeR

GSPA webservice

send the

configuration request

to the ConfigStore

ConfigStore

validates the

configuration event,

splits it into country

specific parts and

sends them to a

special global

queue on the TMO

EMS server

The country

specific LSPA

takes the

corresponding

event and executes

the service

configuration to the

ems server and to

the CAL (or to the

staging area)

EMS

CAL

Staging

Area

The service provisioning – enabling

service consumer and provider

communication within one SOA

Backplane environment - is highly

automated.

1. Challenge: The pentagon …

The pentagon - 1

!! SOA Backplane is currently used in 5 NatCos

!! There are 4 SOA Backplane release per year

!! Some NatCos have 4 core releases per year, some have only 3

!! You cannot update round about 15 Server (example CAL) at exactly the same time

!! You have to take care to be every release downward compatible to the old one

!! We schedule a SOA Backplane rollout for 3 days with some constraints

!! The business message flow isn’t broken

!! The added values (logging and monitoring) may not be complete available

!! A service provisioning is not possible within this three days

!! For three days we have a mix of versions of SOA Backplane components in production

!! only two different major versions


2. Challenge: 2x4 = 8 != 2

SOA Backplane test environments

!! Currently we have two international SOA backplane test environments

!! One is always a production reference

!! The other one is the coming release

!! Every NatCo would like to test their next core release with the next release of SOA Backplane

!! But sometimes, due to the asynchronous release cycle, it is necessary to test the already productive core system

with the next release of SOA backplane

!! Providing Services in one test environment can only address one backend

!! If we would use real environments for these regression tests, we have to set up up to 6 real environments

internationally

!! Very expensive

!! Maintenance nightmare


Virtual SOA Backplane environments!!

Virtual Environments in the scope of CEISeR/ CAL

!! Virtual environments allow a rapid creation of new SOA backplane environments without

the overhead currently necessary for the setup of new dedicated software installations of the SOA BP components (like EMS; CAL, Log/MsgStore) for these new environments.

!! The virtual environments are designed to support parallel and decoupled development and

test of multiple SOA backplane based solutions or NatCo releases.

!! You can avoid several physical SOA BP environments to diminish a maintenance nightmare

if a new software version of a SOA BP component is delivered (or a bugfix for an existing version)

!! For example: CAL bugfix (8.1.2) version for CAL 8.1

!! You don’t need to upgrade several CAL instances if you use several virtual environments to simulate

several real environments


CEISeR virtual Environments – in general


Virtual Environment

•!CEISeR virtual Environment B derived from real

environment A

Real environment

•!CEISeR real environment A

Physical Hardware

•!SOA BP software components

Provider A

Endpoint B

Provider A

Endpoint A

Consumer A

URL B

Consumer A

URL A

SOA BP environment

Note: Consumers A and respectively Providers A can consist of the same piece

of software, but they are running in different physical processes

CEISeR virtual Environments – Example – TST1 real

environment – frico virtual env.


Virtual

•!frico

Real

•!TST1

Provider A

Endpoint B

Provider A

Endpoint A

Consumer A

URL B

Consumer A

URL A

http://url.to.soabp:1111/TestInfrastructure1/net-tmobile…

http://url.to.soabp:1111/frico/net-tmobile…

http:/someHost:9603/…

http://someHost:9601/…

Note: Consumers A and respectively Providers A can consist of the same piece

of software, but they are running in different physical processes

Virtual Environments – Constraints

!! To allow individual configurations of the same services in the real environment and different virtual environments the names of the service specific EARs, WARs are extended with the environment

name.

!! The URLs used by service consumers to call a service are extended with the environment name. To

allow an easy migration of the existing test and production environments services bound to a real environment can also be called using URLs without an environment name.

!! Virtual: http://url.to.soabp:1111/frico/net-tmobile…

!! Real: http://url.to.soabp:1111/TestInfrastructure1/net-tmobile…

!! Virtual environments are currently NOT planned to be used for production purposes.

!! The SOA backplane concepts do not allow any generic bridging of service calls between service

participants in different (real or virtual) environments.


Known limitations

!! All virtual environments share the technical infrastructure of the real environment (CAL and

EMS processes, machines, network connections) they are assigned to.

!! There is no guaranteed resource allocation for a single virtual environment. For example

extensive load and performance-tests conducted in a virtual environment can cause performance problems in the underlying real environment and other virtual environments

hosted by the same real environment

!! The LogStore and the MessageStore are currently not aware of virtual environments. All

messages and logs from all virtual environments hosted in one specific real environment

are stored in the same LogStore and MessageStore.


3. Challenge: Configuration Management vs.

Service repository?

Major assets in SCM and SOA repository

!! Identify and store Artifacts

!! Control and audit changes

!! Organize Artifacts

!! Create baselines at milestones and refer to them

!! Record and track requests for change

!! Support independent changes

!! Integrate early and often

!! Ensure reproducibility


Identify and store Artifacts

!! Which artifacts must be controlled?

!! Usually you‘d think of:

!! Source code and database schemas

!! Design models, requirement documents, Use case documents

!! project plans and documentation

!! libraries and executables and/or standardized development environment

!! The content of the service repository is also an essential part of the whole system!

!! Which services exist?

!! What is their current state?

!! In which version are they deployed in test / production?

!! Of which architectures does the latest release consist of?

!! Can I apply changes to a productive version independent of the current development version?


Control and audit changes

!! Control access to the service repository

!! The access is subject to proper authentication

!! The account is managed in the company’s central LDAP

!! Restrict changes according to the organizational structure

!! The privileges to modify contents of the repository are subject to authorization

!! It’s modeled with user and roles, roles have different privileges and relate to namespace

hierarchies (every object in our repository belongs to a namespace)

!! Audit what was changed, by whom and why

!! The set of changes applied to the repository belong to a transaction

!! The transaction can be reviewed later on, the changed objects and the user that did it and a

description are recorded


Organize Artifacts

!! It is not possible to name every single object when referring to the configuration - it

becomes necessary to group single objects in order to have a larger granularity thus enabling manageability

!! Usually you have components, packages, modules, subsystems or the like

!! The soa repository itself determines the structure by it’s meta model

!! layers are interface, architecture, binding, infrastructure, policy, …

!! Top level objects are used to refer to a logical subsystem

!! Application

!! BindingSet

!! Environment

!! …


Create baselines at milestones and refer to them (1)

!! Typical milestones are the begin of QA phase or the productive release

!! We use the branching and tagging concept, this is a feature of the soa repository (i.e. the

underlying core platform and it’s build into the persistence layer)

!! We are able to label a certain state of the repository and use it later on

!! To refer on it while browsing the repository

!! To build a service configuration on top of that state

!! To generate a report of that state


Create baselines at milestones and refer to them (2)

!! It‘s possible to create a branch from a certain repository state

!! This branches can be referred and fixes can be applied

!! Changes can be merged back and this is documented


TA12

TA13

TA14

TA15

TA16

TA18

TA21

TA24

TA25

TA26

TA29

TA32

TA17

TA19

TA20

TA23

TA22

TA31

TA27

TA28

TA30

main

branch_1

branch_3

branch_2

Merge documentation

Branch dependency

TAxx CEISeR transaction xx

Record and track requests for change

!! We use the tool HP Quality Center to record requests for changes to the repository and for

service provisioning requests

!! There are special groups modeled regarding change request affectiing the soa repository

and the service provisioning


Support independent changes

!! Each set of changes to the repository belongs to a transaction

!! transactions are of course ACID, technically they are implemented with optimistic locking

!! Changes applied to different subsystems (differentiated by their namespaces) can be

executed concurrently

!! Changes applied to different branches in the repository are totally independent


Integrate early and often (1)

!! Using and the providing part of a communication scenario are often modeled by different

users because they are accounted by different parties

!! Compared with a source code repository you would define stable interfaces and different

parties can implement against these interfaces

!! When using interfaces it is possible to check in more frequently code changes even if the

different components depend upon each other

!! The concept in the soa repository to be used are proxies


Integrate early and often (2)

!! Related changes can be applied to the SOA repository independently because of the proxy

concept and the configurable constraints (use case specific constraints)

!! If an object that is referred to is not yet existing, then the soa repository automatically created a

proxy for that object thus the set of changes needs not to be rejected

!! At the time when the information is contributed to the repository (Use case Import of data) a

certain set of constraints is applied to the set of changes, thus it is possible to create an

incomplete communiction scenario but not violating other basic constraints

!! If the lacking objects (being proxied) are created later on by another transaction, the proxies are

substituted with the real objects

!! When the service configuration is generated (to be provisioned) another set of constraints is

applied, for this use case will fail in case of incomplete communication scenarios

!! => Early integration is encouraged and supported!


Ensure reproducibility

!! All objects in the repository are versioned - certain states of the repository are tagged

!! It is possible to create a „diff“ report between two states of the repository thus checking all

differences

!! The service configuration can be reproduced by referring to a label

!! It is possible to view the repository in that state and audit all changes that led to that state


Discussion

Thank you.


soa @ t-mobile – change- und configuration management hoch...

Documents