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