1. 10. lekcija IBM e-business šabloni Pakalpojumu dizains un SOA principi Pakalpojumu orientētā arhitektūra Autors: Maksims Kravcevs Rīga 2007

2. Lekcijas plāns 1.Pieejas pakalpojumu orientētam dizainam (lejupejoša, augšupejoša un kombinēta) 2.IBM e-biznesa šabloni 3.SOA Principi un pakalpojumu dizains

3. Materiāli 1.SW718: Design SOA Solutions and Apply Project, Technical, and Operational Governance 2.E-Patterns http://www.ibm.com/developerworks/patterns/index.html http://www.ibm.com/developerworks/patterns/index.html 3.Patterns & Anti patterns http://msdn2.microsoft.com/en- us/library/ms954638.aspx 4.Thomas Erl, Service oriented design - Ch 6-11

4. Pakalpojumu orientētais dizains

5. (lekcija 1) Prasības uzņēmuma informācijas sistēmas arhitektūrai Vienkāršība - Iespēja efektīvi komunicēt - Iesaistīto personu kvalifikāciju dažādība Pielāgojamība un uzturamība - Jaunas prasības - IS sadalījums komponentēs - Interfeisi - Komponenšu implementācija Atkārtota lietojamība - Izstrādes izmaksu samazināšana - Koda atkārtota lietojamība - Datu kopiju samazinājums Tehnoloģiju un funkcionalitātes atdalīšana - Tehnoloģiju izmaiņas - Neatkarība no specifiskajiem produktiem vai piegādātājiem

6. (lekcija 1) SOA dizaina principi 1-2 1.Coarse grain (burt rupjš graudiņš) Liela izmēra — Nosāka cik daudz funkcionalitātes jāiekļauj pakalpojumā. Pakalpojuma funkcionalitātes pieaugums dažādi ietekmē implementācijas efektivitāti un vairākkārtējas izmantošanas iespējas. Pastāv kritiska lieluma robeža augot virs kuras, pakalpojumu kļūst grūti vairākkārtēji izmantot. Savukārt pie smalkāka izmērā, ņemot vērā bez stāvokļa īpašību, pakalpojuma izmantošana var kļūt diezgan neefektīva. 2.Interface-based design (Dizains balstoties uz interfeisiem)— Pakalpojuma interfeisa dizains, neatkarīgi no iekšējas loģikas, realizācijas, platformas utt. 3.Discoverable Atradams — Iespēja pakalpojuma patērētājam atrast vajadzīgu pakalpojuma sniedzēju. Ja neviens nezina, ka šis pakalpojums pastāv, diez vai šis pakalpojums tiks izmantots. 4.Single instance Vienīga implementācija — Vienam pakalpojumam konkrēta laika momentā jābūt vienīgai realizācijai.

7. (lekcija 1) SOA dizaina principi 2-2 5.Separation of concern (burt. rūpju atdalīšana) — Funkcionalitāte tiek sadalīta uz atsevišķām sastāvdaļām, kas pēc iespējas mazāk pārklājas, pēc iespējas mazāk atkārtojas, attiecīgi samazinot gan savstarpējas atkarības, gan biznesa loģikas un datu dublēšanu dažādās komponentēs. 6.Asynchronous Asinhronā — Šīs princips atbalsta loose coupling un coarse-grained services. Tas ļauj sasniegt labāku mērogojamību (izmantojot specializētu starpprogrammatūru - rindu vai tml...) 7.Stateless — Pakalpojums neatceras iepriekšēju veiktu darbību un nezina par nākamo nepieciešamo darbību. Pakalpojumi nevar būt atkarīgi no citu pakalpojumu stāvokļa. Tas patiesībā nenozīmē, ka pakalpojums nedrīkst saglabāt savu stāvokli.

8. Teorija un prakse: Coarse-grained un fine-grained metožu piemērs Coarse-grained metodes ir tādas, kas vienā operācijā ietver vairāk funkcionalitātes, tādējādi uzlabojot ātrdarbību, samazinot izsaukumu skaitu. Piemērs: metode, kas atgriež visu klienta profila informāciju var tikt uzskatīta par coarse- grained. Dažādiem klientiem var būt vajadzīga dažāda informācija no šā profila (tikai daži lauki, kopsavilkums). Alternatīvas: 1. Deleģēt nepieciešamas informācijas atlasi klientam 2. Nodrošināt specializētas metodes 3. Piedāvāt pieprasījumā norādīt laukus, kas ir nepieciešami 4. Piedāvāt pārslēgties uz vajadzīgu režīmu

9. Saite starp pakalpojumu, komponenšu un klašu dizainu

10. Pieejas pakalpojumu dizainam

11. 1.Lejupejoša (Top down) a.Pakalpojumus identificē pēc biznesa procesiem un lietošanas scenārijiem. Sāk no vispārīga pieprasītas funkcionalitātes apraksta un turpina ar tās detalizētākiem līmeņiem, samazinot abstrakciju 2.Augšupejoša (Bottom Up) a.Apvienojot pieejamu funkcionalitāti (esošus servisus), lai atbalstītu augstāka līmeņa procesus, pakāpeniski palielinot abstrakciju. 3.Meet in the middle a.Top-down un Bottom-Up apvienošana

12. No biznesa prasībām uz pakalpojumiem

13. (lekcija 3) SOA Etalonarhitektūra: Risinājuma Skats

14. Lejupejošas pieejas ilustrācija 1-2

15. Lejupejošas pieejas ilustrācija 2-2

16. Lejupejošas pieejas iespējamas problēmas 1.Kā identificēt, kuri no procesiem un apakšprocesiem, visticamāk būs atkārtoti lietojami 2.Kā noteikt pakalpojuma realizācijai piemērotu tehnoloģiju

17. Augšupejošas pieejas ilustrācija

18. Augšupejošas pieejas iespējamas problēmas 1.Var novest pie pakalpojumu definīcijām, kas neatbilst biznesa perspektīvai 2.Pārāk liela saistība ar realizācijas datu modeli.

19. Meet in the middle pieeja 1-2

20. Meet in the middle pieeja 2-2

21. (lekcija 3) SOA Etalonarhitektūra - Middleware Services View

22. IBM šabloni e-biznesam

23. Šabloni e-biznesam

24. 1.Biznesa šabloni - apraksta mijiedarbību starp lietotājiem, organizācijām un datu plūsmām. 2.Integrācijas šabloni - apraksta, kā var savienot vairākus biznesa šablonus, kad nevar veidot vienotu sistēmu. 3.Salikts šablons - kas apraksta visizplatītākās biznesa un integrācijas šablonu kombinācijas. 4.Lietojumprogrammu šabloni - konceptuāls lietojumprogrammu komponenšu modelis, kas apraksta kā lietojumprogrammas atbalsta atbilstoša biznesa vai integrācijas šablona datu plūsmas 5.Izpildes laika šablons - kas aprasta nepieciešamu dotam lietojumprogrammatūras šablonam starpprogrammatūru un skaitļošanas mezglu loģisko izkārtojumu un interfeisus. 6.Produktu atbalsts - kas parāda IBM produktu konfigurācijas, kas atbalsta dotos šablonus.

25. Biznesa šabloni

26. Integrācijas šabloni

27. Saliktie šabloni

28. Klientu šabloni

29. Lietojumprogrammu šablons: 1. Self-Service::Directly Integrated Single Channel

30. Izpildes laika šablons

31. Izpildes laika šablons 2

32. Piezīme Programmatūras slāni un pakalpojumu arhitektūras slāni ir neatkarīgi jēdzieni

33. Piezīme turpinājums

34. Produktu atbilstība

35. Self-service lietojumprogrammu šabloni

36. Neatkarīga lietojumprogramma ar vienu kanālu(aka U2B Topology 1)

37. Maršrutētājs (aka U2B Topology 5) (aka U2B Topology 5)

38. Maršrutētājs This Application pattern (aka U2B Topology 5) links multiple presentation tiers to any back-end client without hiding the back end from the user. This design provides fast, highly scalable, highly available Web enablement of existing business transactions with multiple presentation channels and multiple applications. This application is divided into three logical tiers with a one-to-one relationship between the tiers at runtime.

41. Dekompozīcijas šablons (aka U2B Topology 6)(aka U2B Topology 6)

42. Dekompozīcijas šablons 1.The Decomposition application pattern extends the hub and spoke architecture provided by the Router application pattern. It decomposes a single, compound request from a client into several, simpler requests and intelligently routes them to multiple back end application. Typically the responses from these multiple backend applications are recomposed into a single response and sent back to the client.

44. Aģents (aka U2B Topology 7)

45. Sadarbības biznesa šablona lietojumprogrammu šabloni 1.Tieša 2.Caur serveri

46. Virzīta sadarbība

47. Pārvaldāma sadarbība

48. Piekļuves pie informācijas biznesa šablons Piekļūšanas pie datiem šablons

49. Federēšanas ar pagaidu datiem šablons Federation=Cache variation pattern Piekļuves pie informācijas biznesa šablons

50. Paplašinātais uzņēmums

51. Mijiedarbības šabloni

52. Mijiedarbības šabloni piemēri

53. Tieša sasaiste

54. Atklāts maršrutētājs

55. Atklāts sērijveidu process

56. Pakalpojumu dizaina antišablonu piemēri

57. (1. lekcija) SOA principi 1.Reusable Vairākkārtēji izmantojams - sistēmas tiek sadalītas uz biznesa komponentēm, kuras var izmantot vairākkārtēji (dažādos procesus un tml... ) 2.Loosely coupled Vāji saistīts - pakalpojumus izmanto caur skaidri definētiem implementācijas neatkarīgiem interfeisiem 3.Contractual Līgumisks – pakalpojumu aprakstos tiek stingri noteiktas vienošanas 4.Autonomous Autonoms - pakalpojums kontrolē biznesa loģiku un datus, kurus tas satur 5.Abstract Abstrakts - Pakalpojums slēpj biznesa loģiku no patērētājiem 6.Composable Komponējams - pakalpojumus var apvienot, veidojot saliktus pakalpojumus 7.Stateless Bezstāvokļa - pakalpojumu no pakalpojuma sniedzēja var izmantot jebkura patērētāja instance, pakalpojuma sniedzējs neuztur kādu papildus informāciju 8.Discoverable Atrādams - pakalpojumu var atrast un pēc viņu apraksta izmantot

58. (1. Lekcija) SOA dizaina principi 1-2 1.Coarse grain (burt rupjš graudiņš) Liela izmēra — Nosāka cik daudz funkcionalitātes jāiekļauj pakalpojumā. Pakalpojuma funkcionalitātes pieaugums dažādi ietekmē implementācijas efektivitāti un vairākkārtējas izmantošanas iespējas. Pastāv kritiska lieluma robeža augot virs kuras, pakalpojumu kļūst grūti vairākkārtēji izmantot. Savukārt pie smalkāka izmērā, ņemot vērā bez stāvokļa īpašību, pakalpojuma izmantošana var kļūt diezgan neefektīva. 2.Interface-based design (Dizains balstoties uz interfeisiem)— Pakalpojuma interfeisa dizains, neatkarīgi no iekšējas loģikas, realizācijas, platformas utt. 3.Discoverable Atradams — Iespēja pakalpojuma patērētājam atrast vajadzīgu pakalpojuma sniedzēju. Ja neviens nezina, ka šis pakalpojums pastāv, diez vai šis pakalpojums tiks izmantots. 4.Single instance Vienīga implementācija — Vienam pakalpojumam konkrēta laika momentā jābūt vienīgai realizācijai.

59. (1. lekcija) SOA dizaina principi 2-2 5.Separation of concern (burt. rūpju atdalīšana) — Funkcionalitāte tiek sadalīta uz atsevišķām sastāvdaļām, kas pēc iespējas mazāk pārklājas, pēc iespējas mazāk atkārtojas, attiecīgi samazinot gan savstarpējas atkarības, gan biznesa loģikas un datu dublēšanu dažādās komponentēs. 6.Asynchronous Asinhronā — Šīs princips atbalsta loose coupling un coarse-grained services. Tas ļauj sasniegt labāku mērogojamību (izmantojot specializētu starpprogrammatūru - rindu vai tml...) 7.Stateless — Pakalpojums neatceras iepriekšēju veiktu darbību un nezina par nākamo nepieciešamo darbību. Pakalpojumi nevar būt atkarīgi no citu pakalpojumu stāvokļa. Tas patiesībā nenozīmē, ka pakalpojums nedrīkst saglabāt savu stāvokli.

60. Anti-šablons #1: CRUDy Interface Konteksts: Esošai komponenšu lietojumprogrammai pievieno servisu slāni Pieeja: Servisa interfeiss tiek veidots pēc entitiju komponenšu parauga ar CRUD (Create, Read, Update, Delete) operācijām. _ Public Sub Create( ByVal CompanyName As String, ByVal ContactName As String, ByVal ContactTitle As String, ByVal Address As String, ByVal City As String, ByVal State As String, ByVal Zip As String, ByVal Country As String, ByVal Telephone As String, ByVal Fax As String) _ Public Function MoveNext() As Boolean End Function _ Public Function Current() As Object End Function _ Public Sub UpdateContactName( ByVal NewName as String) End Sub _ Public Function CommitChanges() End Function

61. Kas tiek uzskatīts par nepareizu 1.Būtu labāk izmantot dokumenta pieeju nekā RPC stilu 2.Paredzamas pārāk daudz interākcijas 3.CRUD metodes atbilst iekšējai loģikai, kurā tiek nevajadzīgi ielikta interfeisā 4.Interfeisā tiek piedāvāta funkcionalitāte ( MoveNext(), Current ), kas paredz stavokļa saglabāšanu 5.Sub - nav atbildes 6.Abstrakti tipi - Objekts, kuru atgriež Current, nenosāka kontraktu 7.Dati var būt atstāti “mainīgā” stāvoklī, ja klients neizsauks CommitChanges. Pakalpojuma sniedzēji nevar paļauties, ka klienti veiks operācijas pareizi

62. Kā uzlabot? 1.Izveidot atbilstošu XML dokumenta shēmu 2.Paslēpt iekšējas datu manipulācijas metodes 3.Pieprasījuma apstiprinājuma saņemšana visām metodēm

63. Anti-šablons #2: Loosey Goosey Konteksts Mērķis ir nodrošināt elastīgumu un servisa atkārtou izmantošanu. Risinājums Servisa dizains tiek veidots vispārīgās datubāzes loģikas izsaukumam _ Public Function QueryDatabase( ByVal Database as String, SQLQuery as string) As DataSet _ Public Function Execute( ByVal Command as Integer, Arguments as string) As Boolean

64. Kas tiek uzskatīts par nepareizu 1.Nav nekāds kontrakts - klients nevar zināt, kā izmantot šo pakalpojumu (piemēram kādi ir Command argumenti). 2.Tiek sagaidīts ka klientiem jāzina dotas datubāzes loģika, kurā rezultātā veidojas cieša saistība starp klientiem un šo datubāzi. 3.Ātrdarbība - jo, lai šis serviss darbotos, jābūt izmantota vēla saistīšana, ka arī lai verificētu pieprasījumus (citādi var būt drošības)

65. Kā uzlabot? 1.Jānodrošina XML shēma, kas precīzi apraksta operāciju semantiku

66. Šablons http://msdn2.microsoft.com/en-us/library/ms954638.aspx Principles of Service Design: Document Centric Pattern. Principles of Service Design: Idempotent Pattern. Principles of Service Design: Reservation Pattern. ClipsAndTacksF2 :)

67. SOA principi un pakalpojumu dizains

68. Contract

69. Short Definition “Services share standardized contracts.” Long Definition “Services within the same service inventory are in compliance with the same contract design standards.” Goals To enable services with a meaningful level of natural interoperability within the boundary of a service inventory. This reduces the need for data transformation because consistent data models are used for information exchange. To allow the purpose and capabilities of services to be more easily and intuitively understood. The consistency with which service functionality is expressed through service contracts increases interpretability and the overall predictability of service endpoints throughout a service inventory. Note that these goals are further supported by other service-orientation principles as well. Design Characteristics A service contract (comprised of a technical interface or one or more service description documents) is provided with the service. The service contract is standardized through the application of design standards.

70. Contract Implementation Requirements The fact that contracts need to be standardized can introduce significant implementation requirements to organizations that do not have a history of using standards. For example: Design standards and conventions need to ideally be in place prior to the delivery of any service in order to ensure adequately scoped standardization. (For those organizations that have already produced ad- hoc Web services, retro-fitting strategies may need to be employed.) Formal processes need to be introduced to ensure that services are modeled and designed consistently, incorporating accepted design principles, conventions, and standards. Because achieving standardized Web service contracts generally requires a “contract first” approach to service- oriented design, the full application of this principle will often demand the use of development tools capable of importing a customized service contract without imposing changes. Appropriate skill-sets are required to carry out the modeling and design processes with the chosen tools. When working with Web services, the need for a high level of proficiency with XML schema and WSDL languages is practically unavoidable. WS-Policy expertise may also be required. These and other requirements can add up to a noticeable transition effort that goes well beyond technology adoption.

71. Standardization of Functional Service Expression Listing #1 Listing #2 Princips - visiem servisiem un operācijām jāizmanto vienādas vienošanas šim izsaukumam Specifiskie datu tipi Standartizēti datu tipi

72. Standardization of Service Data Representation 1.One of the key goals of service-oriented computing is to allow for the agile and even adhoc assembly of service compositions. It is through service compositions that we will be exercising most of the reuse opportunities that come our way. If two service capabilities within a composition represent the same type of data using different representations (data models, schemas), then their relationship is based on non-standardized data representation. This scenario usually leads to the need for data transformation.

73. Standardization of Service Data Representation +

74. Standardization – Key Summary The main areas in which standardization is applied to services are functional expression, data representation, and policies. Naming conventions play a large role in ensuring that the functionality of services is consistently expressed. Data representation standardization comes down to how the underlying data model of a service is defined. By increasing the consistency between service data models, interoperability is improved. Policy standardization primarily revolves around the creation of standardized assertion vocabularies and the consistent use of WS- Policy language features

75. Contracts and Service Design 1.Contracts form the foundation for communication between services and therefore represent the most fundamental architectural element of an SOA. 2.Service-oriented design is a process dedicated to ensuring that necessary factors and issues are taken into account when shaping a service contract through service-orientation. a.Data Representation Standardization and Transformation Avoidance b.Standardization and Granularity c.Standardized Service Contracts and Service Models (Business Services, Information Services etc...)

76. Risks 1.Versioning 2.Technology Dependencies

77. Vāja saistība

78. Coupling 1.A level of coupling is comparable to a level of dependency. 2. Software coupling simply represents a connection or relationship between two programs or components. 3. Many past architectural models established tightly coupled relationships among their parts. 4.Loose coupling piemēri a.Mainframe and terminal b.No programmas un hardware - Driver software: c.Client program and databases – JDBC vai ODBC

79. Loose coupling Short Definition “Services are loosely coupled.” Long Definition “Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.” Goals By consistently fostering reduced coupling within and between services we are working toward a state where service contracts increase independence from their implementations and services are increasingly independent from each other. This promotes an environment in which services and their consumers can be adaptively evolved over time with minimal impact on each other. Design Characteristics The existence of a service contract that is ideally decoupled from technology and implementation details. A functional service context that is not dependent on outside logic. Minimal consumer coupling requirements.

80. Loose coupling Implementation Requirements Loosely coupled services are typically required to perform more runtime processing than if they were more tightly coupled. As a result, data exchange in general can consume more runtime resources, especially during concurrent access and high usage scenarios. To achieve the right balance of coupling, while also supporting the other service-orientation principles that affect contract design, requires increased service contract design proficiency. Web Service Region of Influence As we explore different coupling types in the next section, it will become evident that applying this principle touches numerous parts of the typical Web service architecture. However, the primary focal point, both for internal and consumer-related design considerations, remains the service contract.

81. Kontrakta un loģikas saistība

82. Citi saistības veidi 1.Contract-to-Technology Coupling 2.Contract-to-Implementation Coupling 3.Contract-to-Functional Coupling (the coupling of the service contract to external logic) a.Parent Process Coupling b.Service-to-Consumer Coupling c.Functional Coupling and Task Services

83. Tieša un pastarpināta saistība

86. Saistības samazināšana 1.The key motivation for decoupling a service contract from its implementation is to avoid having service consumers indirectly couple to service implementation details. 2.The Contract Centralization pattern requires that consumers interface only with the official service contract and not with other potentially available service entry points. 3.Consumer-to-contract coupling is an approach used to avoid consumer-toimplementation coupling. However, when based on a poorly designed service contract, consumer-to-contract coupling can still result in the consumer becoming coupled to the service implementation.

87. Service Loose Coupling and Service Design

88. Contract centralisation

89. Service Loose Coupling and Granularity Consumers are further required to submit to whatever level a capability’s data granularity is set at. If the required data exchanges are too fine-grained, the consumer may not receive sufficient information and may be required to invoke additional services. And on the flipside, if the data is too coarse, the consumer may receive more information than it actually needs, which can waste bandwidth and consumer processing cycles.

90. Contract denormalisation

91. Loose coupling risks 1.A common design concern with the logic-to-contract approach is limiting the logic to just one service contract. 2.Another possible risk associated with loosely coupled consumer relationships is the introduction of runtime performance overhead and inadvertent implementation coupling.

92. Abstrakcija

93. Abstraction The commercial “black box” concept, APIs, and middleware are all historic applications of abstraction that have influenced this principle. By wrapping commercial software programs into compiled black boxes, a high level of intentional abstraction is attained. The advent of the commercial API enabled programs to expose specific subsets of their functionality, while continuing to abstract the rest.

94. Abstraction Short Definition “Non-essential service information is abstracted.” Long Definition “Service contracts only contain essential information and information about services is limited to what is published in service contracts.” Goals Many of the other principles emphasize the need to publish more information in the service contract. The primary role of this principle is to keep the quantity and detail of contract content concise and balanced and prevent unnecessary access to additional service details.

95. Abstraction Design Characteristics Services consistently abstract specific information about technology, logic, and function away from the outside world (the world outside of the service boundary). Services have contracts that concisely define interaction requirements and constraints and other required service meta details. Outside of what is documented in the service contract, information about a service is controlled or altogether hidden within a particular environment. Implementation Requirements The primary prerequisite to achieving the appropriate level of abstraction for each service is the level of service contract design skill applied. Web Service Region of Influence The Region of Influence part of this profile has been moved to the Types of Meta Abstraction section where a separate Web service figure is provided for each form of abstraction.

96. Informācijas veidi Technology Information—Meta data that describes the technical implementation of the underlying service logic. Functional Information—Meta data that describes what the service is capable of. Programmatic Logic Information—Meta data that describes how the service carries out its capabilities. Quality of Service Information—Meta data that describes service behavior, limitations, and interaction requirements.

97. Technology Information Abstraction

98. Functional abstraction

99. Programmatic Logic Abstraction

100. Quality of Service Abstraction

101. Service Abstraction and Service Design

102. Service abstraction summary Service Abstraction raises design-time considerations associated with the technical service contract, service design specifications, and source code, as well as non- technical contract documents, such as SLAs. The location of data constraints and validation logic is a primary (long-term) contract design consideration when it comes to applying this principle. Service Abstraction directly affects the Standardized Service Contract and Service Loose Coupling principles but also helps shape the application of others

103. Vairākkārtēja izmantojamība

104. Reuse Short Definition “Services are reusable.” Long Definition “Services contain and express agnostic logic and can be positioned as reusable enterprise resources.” Goals The goals behind Service Reusability are tied directly to some of the most strategic objectives of service-oriented computing: To allow for service logic to be repeatedly leveraged over time so as to achieve an increasingly high return on the initial investment of delivering the service. To increase business agility on an organizational level by enabling the rapid fulfillment of future business automation requirements through wide-scale service composition. To enable the realization of agnostic service models. To enable the creation of service inventories with a high percentage of agnostic services.

105. Reuse Design Characteristics The service is defined by an agnostic functional context— The logic encapsulated by the service is associated with a context that is sufficiently agnostic to any one usage scenario so as to be considered reusable. The service logic is highly generic—The logic encapsulated by the service is sufficiently generic, allowing it to facilitate numerous usage scenarios by different types of service consumers. The service has a generic and extensible contract—The service contract is flexible enough to process a range of input and output messages. The service logic can be accessed concurrently—Services are designed to facilitate simultaneous access by multiple consumer programs. A service is agnostic when its logic is independent from its business processes and proprietary technology or application platforms.

106. Implementation Requirements From an implementation perspective, Service Reusability can be the most demanding of the principles we’ve covered so far. Below are common requirements for creating reusable services and supporting their long-term existence: A scalable runtime hosting environment capable of high-to-extreme concurrent service usage. Once a service inventory is relatively mature, reusable services will find themselves in an increasingly large number of compositions. A solid version control system to properly evolve contracts representing reusable services. Service analysts and designers with a high degree of subject matter expertise who can ensure that the service boundary and contract accurately represent the service’s reusable functional context. A high level of service development and commercial software development expertise so as to structure the underlying logic into generic and potentially decomposable components and routines. These requirements place an emphasis on the appropriate staffing of the service delivery team, as well as the importance of a powerful and scalable hosting environment and supporting infrastructure.

107. Web Service Region of Influence This principle can affect all parts of a Web service. Contract design, the use of system messaging agents, and the underlying core logic can all be shaped by a service’s reusability requirements

108. Pakalpojumu krājumi

109. Loģikas centralizācija

110. Problēmas Logic Centralization requires project teams and IT staff to use designated services as the primary or sole means of accessing information sets and associated capabilities. When positioned as an enterprise standard, it may be impractical to apply Logic Centralization across an entire enterprise, especially within larger organizations. Therefore, the option to apply it to subsets of the enterprise, as per the Domain Inventory pattern can be explored. Most of the obstacles to achieving Logic Centralization to a meaningful extent are organizational and cultural in nature.

111. Service Reusability and Service Design The refinement of existing service capability candidates so as to make them more generic and reusable. The definition of additional service capability candidates that go beyond the functionality required for the automation of the business process that formed the basis of the service modeling process.

112. Risks Cultural Concerns & Governance

113. Risks

114. Kopsavilkums par riskiem The greatest challenges and risks to achieving reusability within services on a consistent basis are primarily organizational. Infrastructures and architectures need to be designed to accommodate increased security, performance, and reliability concerns. Building services with high reusability results in prolonged delivery processes that can run contrary to tactical fulfillment requirements and agile development methodologies. The initial delivery of reusable services can be counter-agile but the availability of these services eventually leads to an environment in which the agility of solution delivery is dramatically increased.

115. Autonoms

117. Short Definition “Services are autonomous.” Long Definition “Services exercise a high level of control over their underlying runtime execution environment.” Goals To increase a service’s runtime reliability, performance, and predictability, especially when being reused and composed. To increase the amount of control a service has over its runtime environment. By pursuing autonomous design and runtime environments, we are essentially aiming to increase postimplementation control over the service and the service’s control over its own execution environment.

118. Design Characteristics Services have a contract that expresses a well-defined functional boundary that should not overlap with other services. Services are deployed in an environment over which they exercise a great deal (and preferably an exclusive level) of control. Service instances are hosted by an environment that accommodates high concurrency for scalability purposes. Implementation Requirements A high level of control over how service logic is designed and developed. Depending on the level of autonomy being sought, this may also involve control over the supporting data models. A distributable deployment environment, so as to allow the service to be moved, isolated, or composed as required. An infrastructure capable of supporting desired autonomy levels.

119. Design and run time autonomy Runtime autonomy represents the amount of control a service has over its execution environment at runtime. Design-time autonomy represents the amount of governance control a service owner has over the service design. As a rule of thumb, the greater the amount of design-time autonomy, the greater the amount of attainable runtime autonomy

120. Service Autonomy is one of the three principles applied during both analysis and design stages. The higher up a service is in a typical composition hierarchy, the less autonomy it tends to have due to dependencies on other composed services. Achieving a higher level of autonomy is an especially important consideration for agnostic services, such as those based on the entity and utility service models.

121. Misjudging the Service Scope Wrapper Services and Legacy Logic Encapsulation The service adapter used to implement the service is inflexible and does not allow sufficient customization. This can compromise standardization and discoverability design characteristics. The underlying legacy environment is not customizable, thereby jeopardizing the application of other service- orientation principles.

122. Stateless 1.Short Definition “Services minimize statefulness.” 2.Long Definition “Services minimize resource consumption by deferring the 3.management of state information when necessary.” 4.Goals To increase service scalability. 5. To support the design of agnostic service logic and 6.improve the potential for service reuse. 7.Design 8.Characteristics 9.What makes this somewhat of a unique principle is the 10.fact that it is promoting a condition of the service that is 11.temporary in nature. Depending on the service model 12.and state deferral approach used, different types of 13.design characteristics can be implemented. Some examples 14.include: 15. Highly business process-agnostic logic so that the 16.service is not designed to retain state information for 17.any specific parent business process. 18. Less constrained service contracts so as to allow for the 19.receipt and transmission of a wider range of state data 20.at runtime. 21. Increased amounts of interpretative programming routines 22.capable of parsing a range of state information 23.delivered by messages and responding to a range of 24.corresponding action requests.

123. 1.Implementation 2.Requirements 3.Although state deferral can reduce the overall consumption 4.of memory and system resources, services designed 5.with statelessness considerations can also introduce some 6.performance demands associated with the runtime 7.retrieval and interpretation of deferred state data. 8.Here is a short checklist of common requirements that can 9.be used to assess the support of stateless service designs 10.by vendor technologies and target deployment locations: 11.The runtime environment should allow for a service to 12.transition from an idle state to an active processing 13.state in a highly efficient manner. 14. Enterprise-level or high-performance XML parsers 15.and hardware accelerators (and SOAP processors) 16.should be provided to allow services implemented as 17.Web services to more efficiently parse larger message 18.payloads with less performance constraints. 19. The use of attachments may need to be supported by 20.Web services to allow for messages to include bodies 21.of payload data that do not undergo interface-level 22.validation or translation to local formats. 23.The nature of the implementation support required by 24.the average stateless service in an environment will 25.depend on the state deferral approach used within the 26.service-oriented architecture.

125. Statelessness and Service Design 1.Messaging as a State Deferral Option 2.Service Statelessness and Service Instances

126. Risks 1.Dependency on the Architecture 2.Increased Runtime Performance Demands 3.Underestimating Delivery Effort

128. Separation of concern Suppose there are 2 entities: Cars and Drivers. Should the table that relates cars to drivers (or drivers to cars) be part of the Cars entity? the drivers entity? both?