Di 6.1a. Warum naive SOA scheitert Ein Erfahrungsbericht. Adam Bien. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich

Transcription

1 Di 6.1a January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Warum naive SOA scheitert Ein Erfahrungsbericht Adam Bien

2 How To Kill a SOA Project Early? [Warum naive SOA scheitert] Seite 1 Adam Bien () Expert Group Member (jcp.org) of Java EE 6, EJB 3.1, Time and Date and JPA 2.0 Java Champion, (JavaONE) speaker, consultant and author: 7 Germany books, working on Productive Java EE Rethinking The Patterns and about 50 published articles Trainer (since JDK 1.0) Project owner/committer: p j Seite 2

3 Based on: Enterprise Architekturen and Java EE 5 Architekturen und Idiome Productive Java EE 6 Rethinking Best Practices for O Reilly US U.S. weblog: Seite 3 Why this topic? Seite 4

4 SOA: Key Ideas Seite 5 SOA - the definition A service-oriented architecture can be defined as a way of designing and implementing enterprise applications thatt deals with the intercommunication of loosely coupled, coarse grained (business level), reusable artifacts (services). Determining how to invoke these services should be through a platform independent service interface. [SOA Blueprints] Seite 6

5 SOA - the definition A set of components which can be invoked, and whose interface descriptions can be published and discovered d [w3c] A Component capable of performing a task. A WSDL service: A collection of end points [W3C]. A type of capability described using WSDL [CBDI]. Seite 7 SOA - the definition Service Oriented Architecture (SOA) is an evolution (not a revolution) of distributed ib t d computing and modular programming. SOAs build applications out of software services. Services are relatively large, intrinsically unassociated units of functionality, which have no calls to each other embedded in them. Seite 8

6 SOA - the definition They typically implement functionalities most humans would recognize as a service, such as filling out an online application for an account, viewing i an online bank statement, or placing an online book or airline ticket order. Instead of services embedding calls to each other in their source code, protocols are defined which describe how one or more services can talk to each other. This architecture then relies on a business process expert to link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement. Seite 9 SOA - the definition Relative to earlier attempts to promote software reuse via modularity of functions, or by use of predefined d groups of functions known as classes, SOA's atomic level objects are 100 to 1,000 times larger, and are associated by an application designer or engineer using orchestration. In the process of orchestration, relatively large chunks of software functionality (services) are associated in a non-hierarchical arrangement (in contrast to a class's hierarchies) by a software engineer, or process engineer, using a special software tool which contains an exhaustive list of all of the services, their characteristics, and a means to record the designer's choices which the designer can manage and the software system can consume and use at run-time. Seite 10

7 SOA - the definition Underlying and enabling all of this is metadata which is sufficient to describe not only the characteristics ti of these services, but also the data that drives them. XML has been used extensively in SOA to create data which is wrapped in a nearly exhaustive description container. Seite 11 SOA - the definition Analogously, the services themselves are typically described by WSDL, and communications protocols by SOAP. Whether these description languages are the best possible for the job, and whether they will remain the favorites going forward, is at present an open question. What is certain is that SOA is utterly dependent on data and services that are described using some implementation of metadata which meets two criteria. The metadata must be in a form which software systems can consume to dynamically configure to maintain coherence and integrity, and in a form which system designers can understand and use to manage that metadata. [from wikipedia] Seite 12

8 Key Ideas - Conclusion SOA stands for Same Old Architecture It s only a refinement of CBD: Business is more emphasized Granularity is coarser Separation of business and technology is stronger Minimalization of redundancies saving costs in the maintenance Services are enriched with metadata (SLA). Service parameters are often standardized. Semantic Metadata is provided. Seite 13 SOA: The Dream Seite 14

9 SOA The Dream Seite 15 Dreams and Hopes Legacy business logic can be exposed as services Those services can be reused in another context Newer, coarser services can be composed from existing one Everything remains consistent, scalable and performant Seite 16

10 Dreams and Hopes The existing logic can remain unchanged Heterogenous systems can easily interoperate WS-* standardizes different products Money can be saved because of better maintainability Seite 17 What Questions To Ask? Seite 18

11 How To Change an Interface? Seite 19 How To Change An Interface? A once deployed service (e.g. WSDL, Java interface, WADL, IIOP etc.) cannot be changed any more. Every change breaks all clients (potentially from other departments). In some protocols - even minor interface changes can break the contract. So, what is the strategy for the release management? Seite 20

12 How To Change An Interface? How the existence of a certain service is communicated? Who communicates changes of an interface to its users / consumers? Who implements features / requirements from service consumers? Do the service owner has actually a budget for the extension / requirement realization? Seite 21 What s about governance? Seite 22

13 What s about governance? Because a service cannot be changed - new copies (versions) of slightly changed service have to be deployed. So, how many versions of one service your department like to maintain? Seite 23 What s about governance? What happens in case an existing service has to be extended? The additional, organizational, overhead slows down changes and development. Is it o.k. for your client? An already deployed service cannot be changed. So every time a new service has to be deployed. d But: how many services are you actually able to maintain in parallel? (just think about branching ) Seite 24

14 How to remain consistent? Seite 25 How To Remain Consistent? Monolithic services are orchestrated inside one process in a local transaction - now they are distributed - and distributed (XA, 2PC) transactions are needed. Does it really work? Seite 26

15 How To Remain Consistent? Use Cases are often defined in request response manner. An Use Case is comprised of activities, which are atomic per definition how to model composite Use Cases? Services are distributed per definition. Does it mean distributed transactions? Who defines compensative transactions? ti What happens in case their fail? Seite 27 How To Remain Consistent? Is your client ready for the rework of the functional and non- functional requirements? Seite 28

16 SOA and Robustness Seite 29 Robustness and the weakest part of the system The robustness of the whole systems becomes as good, as the weakest service. Can your customer live with that? Seite 30

17 Robustness and the weakest part of the system You have to live with partial failure - this problem was unknown so far in monolithic silos. How to deal with it from the business perspective? How to scale, reusable, fine grained services? Who covers the costs of reuse (better hardware, higher requirements for monitoring, auditing and security) Seite 31 SOA and Reuse Seite 32

18 SOA And Reuse It is hard to find a semantically valuable service, which is interesting enough to different departments. Business Domain Objects like "Customer", "Invoice", or even "Address" are different concepts for each department. So will the service be actually reused at the end? Seite 33 SOA and Reuse Are your services and entities really interesting for other departments / users? How many flavors of the essential entities do actually exist in your company? Is your service really interesting inside the enterprise? Seite 34

19 SOA and Redefining The Business Seite 35 SOA and Business The abstractions and distributions and TX coordination do cost performance - synchronous transactions becomes asynchronous, or have to be split to many fine transactions coordinated by the end-user. Is your client ready to change the already existing process to adapt SOA? Seite 36

20 SOA and Business SOA s distributed nature has impact on business. The way how business processes are defined and realized has to be changed fundamently. Synchronous invocations become asynchronous, consistent invocations inconsistent. Partial failure, higherh latency require additional errorhandling The end-user becomes the transaction coordinator! Seite 37 The Impact Seite 38

21 The SOA impact Once deployed service cannot be changed it is frozen A consistent version/lifecycle management strategy is crucial Service Level Agreements becomes even more important, than the functional requirements (especially scaleability, performance, HA) Load and robustness tests are crucial Seite 39 The SOA impact Development becomes more expensive, but the maintenance could be cheaper. Corporate/enterprise instead of department thinking is needed. Reuse is expensive in the development phase, so more budget is needed. d Only trivial services can be combined to complex one, in Seite 40 efficient way.

22 The SOA impact SOA is especially suitable for typical workflow applications. SOA could standardize EAI (just think about the WS-standards). SOA = EAI + meta data Everything which can be easily developed with procedures can be also easily transformed to SOA. Seite 41 The SOA impact There is no ACID in SOA Because distributed transactions are not robust enough for distributed ib t d services, the business logichastobechanged g Consistent request-response style of communication in a composite service is not possible. everything becomes fire and forget. Seite 42

23 Discussion Seite 43