real-world soa in .net

Post on 21-Jun-2015

215 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Real-World SOA in .Net

Matt Terski

©Copyright 2005 Serlio Software

Too muchSOA hype?

Now WithSOA!

Order Now!!

©Copyright 2005 Serlio Software

Service-Oriented Architecture

Why? What? How?

©Copyright 2005 Serlio Software

leg·a·cy

a gift by will especially of money or other personal property

sys·tem

brittle but important

©Copyright 2005 Serlio Software

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

©Copyright 2005 Serlio Software

What is SOA?

• Not a technology but, an architectural style

`

`

`

`

Mainframe Client/ Server

N- tier

©Copyright 2005 Serlio Software

N-Tier Application Silos

Application A Application B Application C

©Copyright 2005 Serlio Software

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?

©Copyright 2005 Serlio Software

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

Application B

Why Not Distributed Objects?

Application A

Application DApplication C

©Copyright 2005 Serlio Software

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.

©Copyright 2005 Serlio Software

What is a Service?

Service

DataApplication

Logic

©Copyright 2005 Serlio Software

SOA: The Four Tenets

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

©Copyright 2005 Serlio Software

Tiers Are Not Layers

Pre

sent

atio

n

Bus

ines

s Lo

gic

Dat

a A

cces

s

DB

This isn’t a service

©Copyright 2005 Serlio Software

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

©Copyright 2005 Serlio Software

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

©Copyright 2005 Serlio Software

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

©Copyright 2005 Serlio Software

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

©Copyright 2005 Serlio Software

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

©Copyright 2005 Serlio Software

Message Patterns

Client Service

Request/Response

One Way

Dialog

©Copyright 2005 Serlio Software

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:

©Copyright 2005 Serlio Software

Message Design

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

• Design idempotent messages

©Copyright 2005 Serlio Software

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

©Copyright 2005 Serlio Software

Create the Solution

Service Business Data

Project References

Types

ServiceAgentProjects/Assemblies

UnitTest

©Copyright 2005 Serlio Software

Model the Collaboration

• Challenges:– How do I separate transport logic from

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

details?

©Copyright 2005 Serlio Software

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?

©Copyright 2005 Serlio Software

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

©Copyright 2005 Serlio Software

Messages and Transactions

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

Service

Data

Transaction Boundary

ApplicationLogic

©Copyright 2005 Serlio Software

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

©Copyright 2005 Serlio Software

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/

©Copyright 2005 Serlio Software

A Word From our Sponsor

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

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

©Copyright 2005 Serlio Software

Parting Thoughts

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

– Resilience– Robustness– Scalability

• Think services and messages

top related