1. Developers have always known how to deliver successful SOA! 1 Microsoft Application Platform Conference 11. April 2007 Mads Nissen & Totto Objectware AS

2. SpeakerBio Totto •President i javaBin siden 1998 •Sun Java Champion •Community Leader, java.net •Sjefskonsulent i Objectware •Arkitekt, utvikler, mentor •J2EE siden 1997, J2SE/J2ME, AOP, Jini/JavaSpaces, UML, RUP, Agile •Programmert professionellt i over 25 år •Sivilingeniør fra NTH/NTNU •... og mye mye mer...  Mads Nissen •Teamleder i Objectware •Arkitekt, utvikler, teknologisk kverulant •MOSS (Sharepoint) •SOA •.NET & C# •Workflow •Microsoft Most Valuable Professional ’05/’06 •Bachelor Computer Science 2The Value of SOA Delivered

3. Purpose of this session •Quickly review The Challenge (or one of them) in the current maturing SOA mindset – related to SOA Governance •Briefly introduce The Categorization Framework for Services •Review the concepts of SOA related to the real world with The Merchant Story: •Service Descriptions and Contracts.. •..in relation to the Client and the Service internals.. •..related to the real world of commerce •This is less stuff – more fluff and food for thought  •Align patterns and technology to the real-world (more stuff again..) 3Developers have always known how to deliver successful SOA!

4. SOA IN OBJECTWARE Objectwares approach to Service Orientation and Architecture 4The Value of SOA Delivered

5. 5 What is Enterprise Design & Architecture?  ”No non-sense” –Enterprise Architecture –Domain Driven Design –Service Oriented Architecture –Enterprise SOA Patterns –Code (reusable & starting points)  ”How IT fits together” –From EA, to SOA categorized services, realized using documented patterns and deployed on both.NET and Java in real projects. The Value of SOA Delivered

6. SOA i Objectware •Vi har utviklet tjeneste-orienterte systemer i lang tid •SOA hypen gikk fra arkitektur til XML og WS-* fokus (definisjon) •Ingen ser ut til å vite hva en tjeneste var.. •Så vi fokuserte på atomet i SOA, nemlig tjenesten.... •..og det var ikke lett å få på plass.... The Eight Fallacies of Distributed Computing 6The Value of SOA Delivered

7. THE CHALLENGE Some points to the challenge for successful SOA today 7Developers have always known how to deliver successful SOA!

8. From Legos.. 8Developers have always known how to deliver successful SOA!

9. Via duplos.. 9Developers have always known how to deliver successful SOA!

10. …to ”Service Orientation” 10Developers have always known how to deliver successful SOA!

11. Or in a protocol view.. TCP/IP CORBA/COM RMI/.NET Remoting SOAP WS* 11Developers have always known how to deliver successful SOA!

12. How far have we gone? •Every level of abstraction allows us to build with larger blocks. •Problem remains the same: Retain evolvability •Dependencies •Versioning •Change and adapt to business requirements But what about: The Eight Fallacies of Distributed Computing The Eight Fallacies of Distributed Computing 12Developers have always known how to deliver successful SOA!

13. Point in question: It works in the real world! •Every major corporation was small once: •McDonalds, REMA, IKEA •They’ve all scaled and evolved and beaten the competition •Can they keep on scaling? •That’s partially up to us IT-folks! •We need to talk about how we talk about services.. 13Developers have always known how to deliver successful SOA!

14. THE MERCHANT STORY Mixing up SOA terms with the real world to make your head spin 14Developers have always known how to deliver successful SOA!

15. Aligning SOA with the Merchant The Merchant is the analogy for a service in a service oriented universe. Tying in well- known SOA principles and artifacts with the merchants endeavors Let’s try to find some service terms in the real world: Endpoint Service Description Request message Response message The Contract Service implementation Human 2 Application Service (H2A) Application 2 application service (A2A) Aggregated Core Service (ACS) Core Service (CS) 15Developers have always known how to deliver successful SOA!

16. SERVICE DESCRIPTION Setter of expectations 16Developers have always known how to deliver successful SOA!

17. RWDL: Real-World Description Language 17Developers have always known how to deliver successful SOA!

18. The Endpoint 18Developers have always known how to deliver successful SOA!

19. RWDL Sets Expectations 19Developers have always known how to deliver successful SOA!

20. Poor Expectations? 20Developers have always known how to deliver successful SOA!

21. Service Descriptions •Services are described both explicitly and implicitly •Services need to be aware of their implicit responsibility (customer expectations) and adapt •Customers are trained through extensive marketing and branding •Great service descriptions and their related contracts are often adopted by competitors: •McDonalds & Burger King – What’s the difference? 21Developers have always known how to deliver successful SOA!

22. THE CLERK Aka - what sits behind the service endpoint and boundry 22Developers have always known how to deliver successful SOA!

23. The Clerk 23Developers have always known how to deliver successful SOA!

24. The Clerks Responsibility •REQUIRED: Fulfill the Service Contract •RECOMMENDED: Fulfill the expectations set to Customers by the Service Description (implicitly or explicitly) •LEADING: Surpass the Customers expectations •The clerk must handle anything that is thrown at him/her 24Developers have always known how to deliver successful SOA!

25. The Clerks interface •May interpret many languages – or only one badly •May accept one currency – or several (check exchange rate!) •May understand the request – but have no means of fulfilling it •May attempt to fulfill your request – even though it wasn’t understood completely 25Developers have always known how to deliver successful SOA!

26. The Clerk 2.0 aka The Learning Service 26Developers have always known how to deliver successful SOA! •If our service can adapt to variance on requests we can serve more types of clients •XML, Strings, CSVs, Voice, Morse-code.. •And respond in the same way •If our service at least can record what it doesn’t understand we can train it •Wait for those AI guys at MIT to come along •This internalizes the responsability of serving clients to the service •Good for cohesion •Good for versioning •Good for coupling

27. More Clerk Strategies 27Developers have always known how to deliver successful SOA! • Clerk scaling!

28. HOWTO: MIMIC RWDL Trying to make Endpoints, Service descriptions, Contracts and Clerks work in software 28Developers have always known how to deliver successful SOA!

29. 29The Value of SOA Delivered

30. Changing Contracts •High-level contracts (H2A/A2A) require agile evolvability •Low Cost •Rapid deployment (Time-To-Market) •Low-level contracts (ACS/CS) require stable evolvability •Moderate Cost •Not break existing clients •Controlled deployment 30Developers have always known how to deliver successful SOA!

31. Evolving H2A/A2A services •H2A and A2A layers should be product-centric and thus very evolvable towards their clients •Ex: Sharepoint, BizTalk, Windows Workflow Foundation, K2.NET •H2A and A2A layers depend on ACS and CS services and can evolve on their interfaces 31Developers have always known how to deliver successful SOA! •If all your human interactionpoints (H2A) and processes (A2A) use your services, would you make a breaking change? •What about self service process orchestration?

32. Evolving ACS/CS services •ACS and CS are code-centric and stable and needs architectural evolvable interfaces towards upper layers •Windows Communication Foundation •Enterprise Library 3.0 •Evolving Endpoint Pattern •ACS and CS must be stable upon changing datasources to provide a robust repository •Enterprise Library 3.0 •Enterprise Domain Repository Pattern 32Developers have always known how to deliver successful SOA!

33. Evolving Service Endpoint Pattern 33Developers have always known how to deliver successful SOA!

34. Enterprise Domain Repository Pattern 34Developers have always known how to deliver successful SOA!

35. Key Takeaways •Make sure SOA won’t be Same Old Architecture •Use Service Categorization to place responsibility and achieve good cohesion and coupling for your services •Think about evolvable services that last for 20 years •Think Evolvability •Create services that provide great service like in RWDL! •Implicit and explicit expectations •Evolving endpoints that don’t break existing customers (clients) 35The Value of SOA Delivered

36. TAKK FOR OPPMERKSOMHETEN! Totto – totto@objectware.nototto@objectware.no Mads – mads@objectware.nomads@objectware.no 36The Value of SOA Delivered Få med dere neste SOA Sesjon: Software Factories i den virkelige verden - Inge Stubdal vil stilne kodehungrige sjeler 