Lecture 11 - Service LifeCycle

1. Book Author: Nicolai M. Josuttis
Chapter Eleven: Service LifeCycle
IT-Slideshares http://it-slideshares.blogspot.com/

2. Contents
11.1 Services Under Development
11.2 Services in Production
11.3 Summary

3. 11.1 Service Under Development
 A service is an IT representation of a business functionality. Services are pieces
of software.
 Although the language and format of this software can differ (E.g depending on
the implementation platform and/or the classification of the service) , it has
the usual lifecycle of any software under development.
 Its core consists of phases of design , implementation , integration, and
bringing into production (See Figure 11-1)

4. 11.1.1 Iterative Service Development
 Software development usually should be an iterative process, with results from
earlier phases adjusted due to experiences encountered at later stages.
 A service is part of a more general business process , any modification of a
service’s design or implementation might impact other systems.
 We must think about when it is appropriate to modify a service.
 The design phase usually produces the specification of the service interface.
 This interface includes the semantics and nonfunctional attributes.
 It might be part of one or more contracts between the service provider and the
(initial) service consumer(s).
 Even during the implementation and testing of a service, any changes to its design
may impact other systems.
 Take into account interfaces of services under development may need to
change, and introduce processes that make modifications during the design of
a service possible.
 When a work contract implements the consuming system, this contract should
take into account that the service might not yet be solid.

5. 11.1.1 Iterative Service Development (Cont)
 Figure 11.2 is a modify our initial service lifecycle.
 How often it happens that service designs change during their implementation.
 The quality of the design has a lot to do with this.
 Market pressure tends to lead to situations where there is no time for solid design.
 The best designers make mistakes , and in large systems people who know “everything”
about a topic almost never exist.
 Modifications of a service design will be common during its implementation.

6. 11.1.2 Service Identification
 A typical scenario that leads to new service being created is the design of a (new)
business process , also known as business process modeling (View section 7.5.1).
 Another approach for identifying new services is portfolio management.
 A department or a company introduces new services because they think it make sense to provide
these services.
 New services may also be introduced to meet new requirements for existing services.
 If a modification isn’t backward compatible , a new service (or new service version) is necessary.
 A new service version is typically considered to be , technically , a new service.
 It is common for some sort of procedure to be carried out before the design of a service
begins (See Figure 11.3) (View 7.3 and 8.1.2)

7. 11.2 Service in Production
 After a service is developed, it is typical used.
 Software gets deployed into a running system,
 Performing more or less mission-critical business functionally for the
company, enterprise , or universe.
 This is the moment at which the software that implements a service transitions
from being software under development to software under maintenance.
 In general : SOA is a concept that combines new software under
development with existing software under maintenance.
 However , for systems under maintenance different rules apply.
 For example :
 Modifications become much more critical , especially if the systems have different
owners.
 We must also look at how to modify and withdraw services in
production.

8. 11.2.1 Modifying Services in Production
 As soon as a service is in production, it can be used in mission-critical
scenarios and business processes.
 That means whenever you modify such a service, you are modifying
existing business processes that are in use  If this results in broken
business processes , you’re in trouble.
 We should be careful about drawing an arrow back from the run state
of the service lifecycle to previous states.
 It is a best practice for services in production to be stable.
 The different between a bug fix and a modification is that you typically
want to apply a fix to existing behavior as soon as possible.
 If you find a bug , you will usually want to fix it in the existing running
service , rather than introducing a new version of service.

9. 11.2.1 Modifying Services in Production(Cont)
 We can extend the service lifecycle as shown in Figure 11.4.
 In practice there is a gray area between a service under development and in
production as well as bug fix and modification.
 Note : Introducing a new service (version) as a modification of an existing service
raises the question of how to deal with service versioning.

10. 11.2.2 Withdrawing a Service
 One state in the service lifecycle is still missing : dead (e.g withdrawn from
production).
 This step is shown in Figure 11.5, which illustrates the complete service lifecycle.
 Withdrawal is the final step of service lifecycle.
 The obsolete services and service version should be phased out.

11. 11.2.2 Withdrawing a Service
 Scenarios :
 In a large systems and companies , withdrawing service can be problematic.
 Resource allocation
 An investment in the maintainability of a system.
 It often has a very low priority.
 In a distributed systems have different owners further complicates things.
 It must be the interest of both the service provider and the service consumer(s) to withdraw a service.
 It makes no sense to remove a service without collaboration with the consumer(s).
 Solution :
 you should always follow a set procedure , which might be as follows.
 First, You mark the service as deprecated.
 Then , you monitor whether (or by which systems) the service is still being used .
 If the service continues to be used , you should contact the relevant consumer(s) and discuss a solution.
 You should try to create a common understanding of the benefit of an upgrade for the
whole systems or company.
 An alternative solution is for the provider to provide some concrete incentive for the
consumer to switch to a new service/version, so that there is some benefit for all the
participants.
 “You need a new service? Well , you can get it if you take this opportunity to stop using my
deprecated services.”

12. 11.3 Summary
 Service implementations are software and have lifecycles just like any other
software.
 The lifecycle is usually triggered by some process that identifies the need for a new
service (business process modeling with process decomposition, portfolio
management, modification of an existing service, etc.).
 Although a service design is usually an interface to another system, you should not
fall into the trap of thinking that this interface can’t be modified during the
development of the service.
 Be sure that the contracts you define with external providers are specified in such a way
that interface updates are possible.
 When a service goes into production, the software switches from being governed by
rules for software under development to being governed by rules for software under
maintenance.
 For this reason, generally only bug fixes should be allowed as modifications to existing
services.
 All other changes should result in new service versions.
 Withdrawing a service is an organizational process that requires collaboration.