Service Lifecycle and Versioning SOA 2/2559

Transcription

1 Service Lifecycle and Versioning SOA 2/2559

2 Services Under Development Design Produces the specification of the service interface Contracts Implementation Integration Bringing into production 2

3 Services Under Development Design Implement Run Integrate, test, QA 3

4 Iterative Service Development In practice, software development usually should be an iterative process A special aspect of service to consider: a service is part of a more general business process Any modification might impact other systems When is the appropriate time to modify A service interface can be modified during phase of development 4

5 Iterative Service Development Design Implement Run Integrate, test, QA 5

6 Iterative Service Development The quality of design impact the modification required during development Business issue, e.g. market pressure, may lead to no time for solid design Usually < 50% of designed interfaces remain stable during implementation phase Early implementation experiences can help to identify necessary interface modifications There is a possibility that other problems may occurs when this phase is over 6

7 Service Identification When will new service being created? New business process The business people think that it make sense to provide these service (may not use now but use later) portfolio management New requirements for existing services (in case of no backward compatibility) Before designing analysis phase May called service identification or service discovery 7

8 Service Identification Identify Design Implement Run Integrate, test, QA 8

9 Services in Production SOA is a concept that combines new software under development with existing software under maintenance Different rule apply when maintenance Some situations, e.g. systems have different owners, the modification become critical How to modify and withdraw services in production 9

10 Modifying Services in Production Best practice When behavior of the service in production is modified Introduce service which is independent from current service Bug fixes New service New version of service Current service can be fixed with the condition that there is no impact to the design or behavior 10

11 Modifying Services in Production Identify Design Implement New Cycle Bugfix Change Run Integrate, test, QA 11

12 Modifying Services in Production When modifying service in production without bringing a new service, all service participants must aware of the rule, process and lifecycles 12

13 Withdrawing a Service Final step of service lifecycle Withdrawing the obsolete services is a way to prevent the number of services from ballooning In large systems, withdrawing services can be problematic What problems? Removing the services is an investment in the maintainability of a system no immediate business advantage This often becomes the lowest priority 13

14 Withdrawing a Service To remove the service, both service consumer(s) and service provider must be agreed Recommend step to do when withdrawing Mark the service as deprecated Monitor the usage of the marked service If marked service still be used, contact the relevant consumer and discuss a solution There may be a problem since consumer(s) don t get direct benefit from service withdrawal 14

15 Withdrawing a Service Identify Design Implement New Cycle Bugfix Change Run Integrate, test, QA Withdraw 15

16 Versioning Requirement SOA is a concept for large distributed systems, it s hard to modify all corresponding systems at the same time Then migration is required In principle, there are 2 different requirements regarding the versioning of services: It must be possible to have multiple versions of a service running in the same runtime environment It must be possible to have multiple revisions of a service under development (no need to be available in the same environment) 16

17 Domain-Driven Versioning Enables different version of the same service to be run at the same time in same runtime environment 2 consumers might call the same service using different interfaces One consumer uses a newer version Another consumer uses an older version 17

18 Trivial Domain-Driven Versioning Concept: treat every modification of an existing service as a new service Example: current service GetData() New or modified service GetData_v2() That is using naming policy to show the relationship with the current service 18

19 Trivial Domain-Driven Versioning During development time, modification can be made but not results in new version However, from the moment a service is first used (e.g. in testing process), the service provide should inform existing consumers about modification and discuss them with consumers It is possible to fix bugs without creating a new version at runtime The service interface doesn t change In practice, sometimes it turns out to be modification (but creating new services for each bug fix is more expensive) 19

20 Trivial Domain-Driven Versioning Backward compatibility issues Backward-compatible modifications often turn out not to be as compatible as expected Example: longer running time broke the SLAs The changes often involve data type modification For this issue, making new service that is used by single consumer at first give a chance to observe its behavior other consumers can switch to new service when everything works fine 20

21 Trivial Domain-Driven Versioning Summary Any modification that effect backward-compatible should results in new service versions Incompatible changes must result in new service versions This versioning concept is a policy, not a law The purpose is to give a common guidelines The problem is? Too many versions 21

22 Nontrivial Domain-Driven Versioning In principle Provide a mechanism that ensures service are forward compatible extensions can be added Existing consumers use the interface as they always have New consumers will be able to use the new feature Introducing techniques that allow consumers to use old interface with the new one Example: infrastructure has the mechanism to add the default values for the absent attributes of the new interface 22

23 Nontrivial Domain-Driven Versioning Provide a method of indirection so that different implementations are provided for different consumers Example: a service broker might be able to determine which version of a service is provided for which consumer Web service Using different namespaces for different version Use UDDI registry as a broker the routes service requests differently 23

24 Versioning of Data Types When different versions of services exist, different versions of data types are also involved (if the services use structured data types) Example: Student_info date_of_birth: String home_province: String ID: String New version Student_info date_of_birth: String home_province: String ID: String faculty: String department: String 24

25 Versioning of Data Types To deal with versioning of data types in principle, there are 3 possible options: Use different types for typed interfaces Use the same type for typed interfaces Use generic code so that type differences don t matter 25

26 Using Different Types for different Versions of Data Type Use naming to distinguish between the types Problems: Too many types 26

27 Student_info_V1 Student_info_V2 date_of_birth: String home_province: String ID: String New version date_of_birth: String home_province: String ID: String faculty: String department: String Student_V1 name: String surname: String info: Student_info_V1 New version Student_V2 name: String surname: String info: Student_info_V2 Student_V2 name: String surname: String info: Student_info_V2 New version Student_V3 name: String surname: String graduate_date: String info: Student_info_V2 27

28 Using Different Types for different Versions of Data Type Problems: Complexity Different data types for the same kinds of information Difficult to compare, copy, etc. Have to create functions to compare, copy, etc. Have to deal with different versions of the same type in the same program Program GetStudentInfo_V1 return Student_V1 GetStudentInfo_V2 GetGradStudentInfo_V1 return Student_V2 GetGradStudentInfo_V2 return Student_V3 28

29 Using Different Types for different Versions of Data Type Problem Complexity Can be avoid? Upgrading all services that use a certain data types Lead to another situation a lot of service versions 29

30 Using the Same Type for Different Version of Data Type That means type must contain all the attributes of all the versions of data type All services will use the same type, but they will use only those attributes that they need Problems: Documentation must be done carefully and delicately (which attributes valid for which service version / very complicated for complex data types or types use in different services) 30

31 Using the Same Type for Different Version of Data Type Problems: The data type of older services change over time compile with different version of library resulting in runtime misbehavior have to recompile all other code that used this data type 31

32 Using Generic Data Types Generic data types = types to be specified later Attributes are verified and evaluated at runtime Loose coupling Not a common approach Lose the advantage of finding bugs at compile time 32

33 Configuration-Management-Driven Versioning Multiple revisions of a service under development in different runtime environments Need tools such as version-control systems 33

34 Versioning in Practice Requirements are likely to change very often More versions being rolled out more frequently Modifications should impact only the provider and consumer(s) At SOA design time, the infrastructure should be as generic as possible with respect to domain-specific business functionality If infrastructure has an additional function to check service interfaces during data transfer, each modification must be deployed to the infrastructure component more complicated processes and potential bottlenecks Any specific processing that is influenced by different versions should affect only the endpoint of the infrastructure 34

35 Versioning in Practice Call Constraints should be considered Call constraint: an additional parameter that open up a channel for provider and consumer(s) to handle special cases or to perform some optimizations in case that it is too late to fix the interface 35