Current State of Affairs in Current State of Affairs in SOA Along with Migration SOA Along with Migration

Strategies and Strategies and MethodologiesMethodologies

www.oasis-open.org

John HarbyJohn Harby

John HarbyJohn Harby is currently working with MIRO Technologies, a global aerospace defense contractor headquartered in San Diego. He specializes in the SOA and middleware areas. He is a member of several OASIS Technical Committees and is also on several JSR expert groups.

He was co-author of The Middleware Company SOA Blueprints initiative. He has previously worked in product development for vendors including Oracle, BEA Systems and was a Sr. Architect in the HP Web Services (e-speak) lab. His first experience in SOA was in the mid-90's developing systems for U.S. Intelligence using CORBA/C++

PGFSOA Practical Guide to Federal SOA Are using OASIS standards such as

the SOA Reference Model <hint>Still accepting volunteers</hint>

The Standards have Arrived OASIS SOA RM, SCA, SDO WS-Transaction WS-Addressing Etc.

Product Maturity Orchestration – IBM, BEA, Oracle,

et al are maturing Registries, ESBs, etc. also no longer

new Many support tooling now exists,

e.g. management tools

Open Source Contributions JBoss – jBPM, ESB Mule ESB ServiceMix Synapse

External to Technology Governance Methodologies Management

REST Approach Further decoupling through

abstraction of contract Lack of declarative standardization Can one use REST within SOA?

Practices, What Works? Choose pilots carefully Governance always comes first Vendor selection matters even more

Practices, What Works? SOA as a pattern Migration strategies Platform integration

Novel approach – AOP/SOA Services can be woven rather than

orchestrated. Especially useful for lightweight

services with many join points. Examples, logging, properties, etc.

The Jaffa framework employs some of these strategies.

REST – Friend or Foe REST exhibits more simplicity than

the other alternatives REST offers further decoupling than

SOAP/WSDL/etc. REST potentially violates the SOA

contract requirements

ROA vs. SOA My opinion is to strive for a blend OASIS SOA-RM: “A contract …

represents an agreement by two or more parties”

Does the level of abstraction of the contract really matter?

Why does this matter? Adds capability to the SOA Further enablement of end-end

enterprise architecture

Platform migration Seek a generalized methodology Migration strategies are available Initially target the “low hanging fruit”

SOA Migration Path

SOA Migration Path

SOA Migration Path

Service Locator Transaction Service Business Service DTODAO

invoke()

getData()

returnData()

<<Persistence >><<SLSB>><<Registry>>

Some Interesting Links Web Methods SOA Master Class:

http://www.soamasterclass.com/index.php?option=com_content&task=view&id=74&Itemid=88888964

Estimate SOA costs:

http://weblog.infoworld.com/realworldsoa/archives/2006/11/how_much_will_y.html

REST FAQ:

http://rest.blueoxen.net/cgi-bin/wiki.pl?RestFaq

Two IBM SOA success stories:

http://www.soainaction.com/blog/2007/03/post_4.php

Web Services Standards poster:

http://www.innoq.com/soa/ws-standards/poster/