What is SOA? Soft Design & Websydian A/S

Transcription

1 What is SOA? John Leadbetter Soft Design & Websydian A/S

2 Session abstract > This session will provide a general introduction to SOA. We take a look at how you should perceive SOA, and our take on some very concrete suggestions to start implementing a Service Oriented Architecture with your current applications. 2 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

3 What s a Service? > Many interpretations just try to google service and SOA > There seems to be consensus about Access to functionality [on other systems] Consistent behavior Contract about interface (input / output) > OASIS Reference model for SOA 1.0 > From the perspective p of CA Plex and CA 2E a service is a function Some service are just more business oriented than others 3 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

4 Short trip down memory lane 4 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

5 Black box Structured Design definition > The concept of a black box is a very powerful one, both in engineering and in software design. A black box is a system with known inputs, known outputs, and, generally, a known transform, but with unknown (or irrelevant) contents. The box is black we cannot see inside it. > This is from the mid 70 s Why are not all systems built this way? 5 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

6 Vision of SOA > The great promise of SOA suggests that the marginal cost of creating the n-th application is low, as all of the software required already exists to satisfy the requirements of other applications. Ideally, one requires only orchestration to produce a new application Orchestration: Think of this as AD code where a developer based on input decides what action to take. The developer is the conductor, and thus the term orchestration. > Spend now, gain later (prepare for the future) > I believe we can actually make gains right now 6 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

7 Vendor hype > Vendors cannot deliver business services They have to find something else to deliver > Tools around ESB BPM Security Governance Metrics.. > Lots of existing tools rebranded to fit into SOA 7 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

8 Service usage / Web Service usage CA Plex/CA 2E System Non CA Plex/CA 2E System > 3 basic scenarios External party Request service Provide service Internal application Request service Provide service Or use calls Inter application Request and provide Just use calls 8 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

9 Small SOA example CA Plex/CA 2E version UI Fun A Fun B Fun C 9 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

10 Small SOA example SOA (textbook) version UI ESB Enterprise Service Buss Service A Service B Service C 10 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

11 Small SOA example side by side UI UI 1 1a Fun A ESB Enterprise Service Buss 2 1b Fun B 2a 2b 3a 3b Service A Service B Service C 3 Fun C 11 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

12 SOA word Loosely coupled (1) > XML > Web Services > SOAP But what was the original problem? > The longer time working on a system = The faster we can make changes? Last 10 years have shown that The larger a system The longer time a change can take Why is this? > My view: Butterfly effect a small change in one part of the system can cause unpredictable results in other parts of the system. This is the actual problem 12 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

13 SOA word Loosely coupled (2) > Loose coupling promises Interface change without impact Change of service without impact (using an ESB) > We had a request from a CA Plex system where every call should be replaced with an XML interface Guesstimate was 1000 s of XML interfaces and all of 25 28,000 calls replaced by XML/HTTP > Can the original problem be solved in some other way? With lower cost both development and run-time wise > Stabilize your interfaces! 13 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

14 Traditionel devlopment, CA Plex and CA 2E systems Every circle illustrates an application area or sub-system Read of Item master in one of my solutions is called by 109 functions = large costs when changes occur.

15 Separate your systems

16 SOA define sub-systems and establish interfaces

17 Stabilize interfaces 17 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

18 Stabilize interfaces > Change and test required: Where new functionality is needed Compelling reason to spend time Users motivated to test Lower cost faster implementation Lower risk Sub-systems can implement changes when needed > Known and tested approach from components Let the caller decide when to change 18 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

19 Does loose coupling solve all problems? > With XML you can add fields and alter sequence Only if the receiver has developed using xpath! > Change of data types Depends on how the receiver interprets data > Change of structure Only if the receiver dynamically looks up the schema Extremely costly > Using schema validation would stop processing anyway Using a schema ensures correct pre-conditions Or the schema is very loose, and not very useful 19 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

20 Change of service

21 Change of service The change has no impact on the caller. Interface contract is honored Exactly how a new customer master was introduced at one of our clients.

22 Do you have a complex IT environment? > If the answer is Yes you need SOA But complex is relative to what? > Consider a large bank > Consider a newly started web-shop > Consider a retail outlet with hundreds of shops > Consider software for aircrafts > SOA is not a one size fits all solution You have to carefully look at where SOA can help your business 22 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

23 Future changes at low cost > SOA is interpreted by many as: Write your software prepared for future change > Good management says: Goal in sight Everyone knows what to do and can pull in the same direction > High expectations put pressure on developers Don t know what is expected Can t see how any future change can be implemented at a low cost (or even 0 cost) 23 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

24 Security using Web Services > WS-Security specifications Long number of sub-specifications: SecurePolicy, SecureConversation, Federation, Trust, Authorization,. > Try to stay away unless required by business partners Specifications are changing and very complex Securiwalls should handle this complexity > Simple and known ways SSL and Firewalls combined - if required - with user/password will get you a long way. 24 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

25 Stateless / Statefull > Not much mention of this consideration > Statefull new set of specifications Web Services Transaction WS-Coordination WS-AtomicTransaction WS-BusinessActivity Or application controlled states > Stateless Create majority of services stateless if possible > Important to consider the difference before you start 25 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

26 SOA recommendations > You have to build the services required for your business No piece of technology can do that The trick is in the interface design and not really the technology, and that in many ways has *always* been the trick when designing a decent component set. (David Ing) > Necessary and sufficient Good question to ask when specifying an interface > Try to answer questions and perform business tasks And not just return data and update the database > Hide the underlying DB 26 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

27 SOA recommendations > Start tomorrow by stabilizing interfaces between systems Practice and get the experience Remember the original i problem: Changes at low cost and risk. When you find inline logic you need as a service: Refactor the inline logic into a services And create a commented out call before the original code to the new service. Be at the ready when interfaces are required Publish ensure visibility Next slide shows sample 27 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

28 Visibility of services >Scope >Name > Icons >Lists Useful when SOA was not planned from the start of the project. Rule here is: Search for Service Interface and find services provided. 28 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

29 SOA recommendations > Don t SOA just for the sake of SOA Analysists, various blogs, Martin Fowler (ServiceOrientedAmbiguity) are raising the caution flag. > Don t try to boil the ocean From SOA for dummies > Use Web technology where required > SOA can help you build even better applications 29 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

30 SOA recommendations - summary > Access to DB through services CA Plex & CA 2E has always done this This is why we are more service oriented out of the box > Stabilize your interfaces > Test services not UI s > Rewrite inline business logic into services > We can take the gain already now because we selected CA Plex/CA 2E years ago > Start tomorrow but don t try to do it all at once 30 September 23-25, 2009 Copyright 2009 CA. All rights reserved.

31 Have a great conference > Thank you for listening 31 September 23-25, 2009 Copyright 2009 CA. All rights reserved.