SOA @ T-Mobile – Change- und Configuration Management hoch...
Transcript of 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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 3
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 5
SOA Backplane in nutshell
SOA Backplane – overview (simplified)
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 7
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 8
. . . . . .
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.
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 9
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 10
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)
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 11
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 12
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 15
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 17
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 18
CEISeR virtual Environments – in general
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 19
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.
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 20
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.
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 21
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.
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 22
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 24
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?
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 25
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 26
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
!! …
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 27
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 28
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 29
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 30
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 31
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 32
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!
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 33
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
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 34
Discussion
Thank you.
C. Sensler & A. Karalus, CMConf 2008, SOA @ T-Mobile 35