real-world soa in .net

Real-World SOA in .Net

Matt Terski

©Copyright 2005 Serlio Software

Too muchSOA hype?

Now WithSOA!

Order Now!!


Service-Oriented Architecture

Why? What? How?


leg·a·cy

a gift by will especially of money or other personal property

sys·tem

brittle but important


Why SOA Matters

• As developers, we need to:– Leverage what we have

• Don’t apply new tools to old problems• Extend existing software assets• Solve a new problem

– Build new systems to last• Be resilient to change• Evolve gracefully


What is SOA?

• Not a technology but, an architectural style

`

`

`

`

Mainframe Client/ Server

N- tier


N-Tier Application Silos

Application A Application B Application C


Solving the Silo Problem

1. Do nothing– Let the users deal with it

2. Build a monolithic application– Efficient (maybe), but unmanageable– Not realistic

3. Make the applications talk– The only real choice– How?


• Tight coupling– At both design-time and run-time

Application B

Why Not Distributed Objects?

Application A

Application DApplication C


Terski’s 2am Theorem of Distributed Objects

1. Distributed objects lead to tight coupling.2. Tightly coupled applications must be

deployed together.3. Vital applications cannot be deployed

during peak times. 2am is better.4. Terski prefers to be in bed sleeping at

2am.5. Ergo, Terski avoids distributed objects.


What is a Service?

Service

DataApplication

Logic


SOA: The Four Tenets

• Services are autonomous• Services share schema, not type• Service boundaries are explicit• Services negotiate via policy


Tiers Are Not Layers

Pre

sent

atio

n

Bus

ines

s Lo

gic

Dat

a A

cces

s

DB

This isn’t a service


New Application Metatypes

InventoryService

CustomerWeb App

DMZ

Partner Web Service

Customers

BusinessPartners

Trusted Network

Order ManagementService

Distribution CenterWeb App

Accounting Service

Credit Bureau

Intranet App


Healthy Skepticism

• “It’ll never perform.”– Crossing boundaries is expensive– XML serialization is expensive– HTTP is expensive

• My response– Performance: just one of many constraints– SOA brings:

• Scalability, robustness, resilience• And maybe performance


Demo Background

Mobile Meter Reader App

CustomerWeb App

DMZ

Accounts

Gas Company Customers

Trusted Network

Account Service

Accounts

Meter Reader Web App

Meter Reader

Serlio Gas Company

Billing Service


Building a Service

1. Ponder the seven fallacies of D.C.2. Design the messages3. Set up the solution4. For each message

a. Model the collaborationb. Implement the message processing

i. service layerii. types layeriii. business layeriv. data access layerv. service agent layer


The Seven Fallacies of Distributed Computing*

1. The network is reliable.2. Latency is zero.3. Bandwidth is infinite.4. The network is secure.5. Topology doesn’t change.6. There is one administrator.7. Transport cost is zero.

*Peter Deutsch


Message Patterns

Client Service

Request/Response

One Way

Dialog


Choosing a Message Pattern

Request/Response

Dialog orOne-way

Dialog One-way

Data is:

More

vola

tile

Read-only

More

sta

ble

Read-write

Processing the message is:


Message Design

• Avoid CRUD– Leads to concurrency conflicts– Provides no business meaning– Think of “business actions” instead

• Design idempotent messages


Create the Solution

• It is the unit of deployment• Challenges:

– Manage class dependencies– Make it easy to build

• Shift+Ctrl+B and you’re done


Create the Solution

Service Business Data

Project References

Types

ServiceAgentProjects/Assemblies

UnitTest


Model the Collaboration

• Challenges:– How do I separate transport logic from

business logic?– How do I abstract-away data and service

details?


Implement the Message Processing

• Challenges– How do I make this version-able?– How do I handle exceptions?– How do I manage transactions?– How do I instrument my service?– How do I monitor my service?– How do I authorize users?


Handling Exceptions

• Exceptions don’t make it to the caller, SOAP faults do

• Client faults– e.g. Business rule violations

• Server faults– e.g. The database is down.

• We share details about client faults, but not server faults


Messages and Transactions

• Transaction Scope– Receive a message– Update any service data– Generate outgoing messages– Send a response

Service

Data

Transaction Boundary

ApplicationLogic


Getting Ready for Indigo

• Think “messages”• Use .asmx web services• Use EnterpriseServices, Remoting, or

MSMQ inside of your services• Avoid/abstract-away HttpContext• Use WSE 2.0 for security, policy, etc.

if you need it


Selected Resources

• Microsoft– http://www.microsoft.com/resources/practices– http://msdn.microsoft.com/webservices/– http://msdn.microsoft.com/architecture/

• Shadowfax– Enterprise Development Reference Architecture– http://workspaces.gotdotnet.com/shadowfx

• Clemens Vasters– http://staff.newtelligence.net/clemensv/

http://www.microsoft.com/resources/practices

http://msdn.microsoft.com/webservices/

http://msdn.microsoft.com/architecture/



http://workspaces.gotdotnet.com/shadowfx

http://workspaces.gotdotnet.com/shadowfx

http://staff.newtelligence.net/clemensv/




A Word From our Sponsor

• Serlio Software– http://www.serlio.com

• My blog– http://www.terski.com

http://www.serlio.com/


Parting Thoughts

• Embrace and extend existing assets• Build new apps to last• Think

– Resilience– Robustness– Scalability

• Think services and messages

real-world soa in .net

Documents

service data application

service boundaries

service details

application b application

serviceoriented architecture

message design

expensive http

away data