Lecture 11 - Service LifeCycle


Published on

Lecture 11 - Service LifeCycle

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Describe of Figure 11.3 This diagram includes all of the steps taken for a service under development. After identifying a (new) service is necessary , we design its interface and contract , implement it, and perform the usual tasks to verify its quality. Note : This process is iterative.
  • Describe Of Figure 11.4When services are in a production state(the “run” phase) you can fix bugs , but this should never have an impact on the design.  It is actually a modification , which should result in a new service(version) that has its own lifecycle.
  • Lecture 11 - Service LifeCycle

    1. 1. Book Author: Nicolai M. Josuttis Chapter Eleven: Service LifeCycleIT-Slideshares http://it-slideshares.blogspot.com/
    2. 2. Contents11.1 Services Under Development11.2 Services in Production11.3 Summary
    3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.