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

Developers have always known how to deliver successful SOA!

Developers have always known how to deliver successful SOA! 1

Microsoft Application Platform Conference

11. April 2007

Mads Nissen & Totto

Objectware AS

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

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!

SOA IN OBJECTWARE

Objectwares approach to Service Orientation and Architecture


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

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


http://www.java.net/jag/Fallacies.html



THE CHALLENGESome points to the challenge for successful SOA today


From Legos..


Via duplos..


…to ”Service Orientation”


Or in a protocol view..

TCP/IP

CORBA/COM

RMI/.NET Remoting

SOAP

WS*


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




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..


THE MERCHANT STORY

Mixing up SOA terms with the real world to make your head spin


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)


SERVICE DESCRIPTIONSetter of expectations


RWDL: Real-World Description Language


The Endpoint


RWDL Sets Expectations


Poor Expectations?


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?


THE CLERKAka - what sits behind the service endpoint and boundry


The Clerk


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


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


The Clerk 2.0 aka The Learning Service


• 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

More Clerk Strategies


• Clerk scaling!

HOWTO: MIMIC RWDL

Trying to make Endpoints, Service descriptions, Contracts and Clerks work in software



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


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


• If all your human interactionpoints (H2A) and processes (A2A) use your services, would you make a breaking change?

• What about self service process orchestration?

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


Evolving Service Endpoint Pattern


Enterprise Domain Repository Pattern


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)


TAKK FOR OPPMERKSOMHETEN!

Totto – [email protected]

Mads – [email protected]


Få med dere neste SOA Sesjon:

Software Factories i den virkelige verden

- Inge Stubdal vil stilne kodehungrige sjeler

mailto:[email protected]

mailto:[email protected]

Documents

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