exchange breakout notes

© 2008 Progress Software Corporation1 SOA-27: Practical Approaches for Implementing a Service Oriented Architecture

Exchange Breakout Notes

To access the hyperlinks in this presentation, please view in SlideShow Mode

When printing, please select the “Print Hidden Slides” option to get all detailed slides

SOA-27: Practical Approaches for Implementing a Service Oriented Architecture

Michael J. Boyd, CITPServices Portfolio Manager

How to begin implementing aService Oriented Architecture (SOA),

one step at a time

Practical Approaches for Implementing a SOA

What you will learn today


Agenda

The SOA starting point Starting your own evolution

• A tale of two architectures

• Process, process, process

• Think globally, act locally

Case Study Common pitfalls First steps when you get back home



Introducing SOA & SOBA

An approach for building agile and flexible business applications• Loosely coupled services

= flexible business processes

SOA is not A product or application A specific technology A specific standard A specific set of rules

Service-Oriented Architecture > Service-Oriented Business Applications


Progress’ SOA Portfolio

ServicesManagement

Complex Event

Processing

Business Process

Management

Mainframe Integration

Enterprise Service Bus

Registry/Repository

Enterprise Messaging

Data Interoperability

Your World, Your SOATM


SOA In Summary

SOA• The architecture for the

agile business

SOA is a design approach• Not a technology

Take small steps• Evolution, not revolution


Agenda








A Tale of Two Architectures

Communications is conducted point to point, synchronous and unreliable

Process logic is fragmented across applications and platforms and implemented differently in each place

Data comes in multiple incompatible formats

Communications are direct to a centralized service bus

Process logic is coherently defined in a single model which can be edited and redeployed quickly

Data comes expressed as XML

Existing Architecture New Architecture


Example: Using Two Architectures

P3P1P2

OrderMgmt Order

Fulfillment

OrderProcess

Business Applications

Finance

SupplierMgmt

CRM

TrackingService

PartnerBack Office

MFG CRM

Adapter

Adapter

Integration Broker

Enterprise Service Bus (ESB)

New SOA (ESB)Existing Architecture

Adapter


Moving towards SOA…

Zapthink

“Fundamentally, the technology shift is the easy part; changing how people work is the greater challenge facing IT organizations today, as they move to SOA.”


/** MyIntProc1.p **/

DEF INPUT PARAMETER ipcA AS CHAR.DEF INPUT PARAMETER ipcB AS CHAR.DEF INPUT PARAMETER ipcC AS CHAR.DEF OUTPUT PARAMETER opcD AS CHAR.

ASSIGN ipcA = "A" ipcB = "B" ipcC = "C".

RUN MyIntProc2.p (INPUT ipcA, INPUT ipcB, INPUT ipcC, OUTPUT opcD).

DISPLAY opcD.

What is Wrong with this ABL ?

/** MyIntProc2.p **/

DEF INPUT PARAMETER ipcA AS CHAR.DEF INPUT PARAMETER ipcB AS CHAR.DEF INPUT PARAMETER ipcC AS CHAR.DEF INPUT PARAMETER ipcD AS CHAR.DEF OUTPUT PARAMETER opcE AS CHAR.DEF OUTPUT PARAMETER opcF AS CHAR.

FOR EACH ..... :

ASSIGN opcE = ... opcF = ...END.


Process, Process, Process

Cannot “Code your way out of it” Requires developers to:

• Specify contracts and interfaces

• Harvest existing systems for logic

• Wrap legacy systems• Define system monitoring and management• Specify service policies & granularity

Benefit: Parallel development

SODA - Service Oriented Development of Applications


Strategic SOADefine your long-term SOA vision

Think Globally, Act Locally

Succeed by thinking

strategically but acting tactically

Tactical SOAImplement first

elements of your SOA vision on next

business-based project

Add SOA elements into each successive

business-based project until SOA is

realized


P3P1P2

OrderMgmt Order

Fulfillment

OrderProcess

Business Applications

Finance

SupplierMgmt

CRM

TrackingService

PartnerBack Office

MFG CRM

Adapter

Adapter

Integration Broker


New SOA (ESB)Existing Architecture

Adapter

Act Locally – Tactical SOA: Additional Projects

Adapter

Adapter



Think Globally – Strategic SOA

Ronald Ross, “Father of Business Rules” Business Rule Concepts

“In order to be agile, businesses need disposable business rules – ones that are cheap and easy enough to throwaway and replace as business changes.”


Agenda








Case Study: Pharmaceutical Company

Company: Family-owned, global company with 40,000 employees and 135 affiliates that make prescription and over-the-counter (OTC) pharmaceuticals, veterinary drugs, and consumer health care products.

Challenge: Multiple integration strategies and approaches was making integration too complex. Needed to introduce an infrastructure for developing applications following a SOA methodology for current and future business requirements. Applications must offer services reusable across the globe. New applications will be composed of existing and new services.

Solution: Introduce the Sonic™ ESB as a distributed infrastructure capable of offering and interconnecting services. Introduce a common development methodology allowing local teams to develop services that can be reused in other countries.

Results:• Gained experience on the path to SOA by conducting local projects• Realized services and concepts in 3 “incubator” countries, spread the

methodology across the enterprise• Spread the methodology around the OPU’s• Standardized architecture and implementation for integration needs• Decoupled, yet integrated approach to SOA



OPU_DE::DirectoryService

OPU_US:: DirectoryService

OPU_FR::DirectoryService

OPU_IT::DirectoryService

OPU_BE::DirectoryService

OPU_JP:: DirectoryService

OPU_AU:: DirectoryService

OPU_CA:: DirectoryService

Each OPU maintains and develops it’s own ESB segment



Example: Maintain global training requirements

DocumentManagement

Crystal Report Server

EMailCSV attr.1

CSV attr.2

CSV attr..

CSV attr.n

FTP

Filecopy

EMail

CSV File

Attributesfor all

predefined SOPs

Service Provider

• Standard Operating Procedures (SOPs) are maintained centrally

• SOP changes require training of international staff

• Training status and schedule is maintained in OPU specific applications

• Change notification was manually before the ESB




DocumentManagement


XML attr.1

CSV attr.1

CSV attr.2

CSV attr..

CSV attr.n

XML attr.2

XML attr. ...

XML attr.n

CSV File

Attributesfor all

predefined SOPs

Service Provider

• Automate the data exchange

• Develop a central document SOP change notification service

• Define a communication pattern to distribute SOP change events to interested OPUs

• Each interested OPU runs a local project to consume the change events




DocumentManagement


XML

CSV File

Attributesfor all

predefined SOPs

Message generation, not file extraction

Service Provider

Pub/Sub

Step 1:

• Don’t touch the connection to the document management system.

• Define XML based change events formatted in XML replacing the individual files

• Publish the change events on the Sonic ESB

• Use Dynamic Routing Architecture to distribute the change events globally



Example: Maintain global training requirementsStep 2:

• Consume the XML based change event from the ESB

• Define a handling ESB process to update the training database accordingly.

• Typically the process transforms the change event and uses a backend Service for the Training database.

Pub/Sub

TrainingDatabase

XML format Transformation

<title> => <SOPtitle>

Service User 1



Example: Maintain global training requirementsStep 3:

• Leverage the knowledge gained in other OPUs

• Reuse whatever is reusable, amend what needs to change for a specific OPU

• All OPU adhere to the same development and deployment methodology

XML Format Transformation

<Title> =><SOP>



Pub/Sub

TrainingDatabase



SAPHR

Browser

Service User 1 Service User 2

Service User 3



Lessons learned

Traditional development turns slowly into a SOA community• Community like development structures needed

SOA needs • loose coupling • A common infrastructure• Common development principles and guidelines

“Successful establishment of SOA is NOT dependent on technology, but on the acceptance of the organization to support the paradigm shift.”

“Lessons Learned” from SOA Project Review


Case Study: Pernod Ricard Pacific

Ric Hayman Innovation Manager for Pernod Ricard Pacific

“Our ESB allows us to achieve results far more quickly and flexibly than would otherwise be possible.”



150,000 500 100 90 30

Tonnes of Grapes per year

Vineyards

Subcontractors

Day Harvest Season

Minutes


The Business Case• Poor quality wine results in lower sales and bad

reputation

Business Challenges• Minimize value loss that occurs between harvest and controlled

fermentation

Business Objectives• Picking the grapes at their peak• Process and transport to fermentation tanks ASAP



The existing solution

Project Objective• Find a new way for these 2 existing disparate applications to

work as one to deliver real-time results


• Legacy CHUI App

•15 years old

•HP-UX

• CSIRO specialty software

• C++

• Windows

• File based XML

XML

Given a change in base data, could take over 24 hrs

to generate a new vintage plan


The Solution• Investigate functionality and harvest


Webspeed

Progress Subscriber

Sonic

Direct entry to the Viticultureapplication

Œ

field data

Shared drive…

/

.../…/ Sample data

ŽŒ

Ž

Ž

Ž

Generate Block

bidsheet.shXML Rules

Consolidated

Œ

‘’

“

ExcelSubscriberWindows Server

Sonic 5

cbs

Block.xmlŽ

Recipient

”



– Application functionality was there– The supporting data was there– But the whole PROCESS suffered from ….


1. A batch processing mentality

2. accidental architecture




CSIRO maturity prediction

CSIROvintage

planning

Viticulture Database

Calculate and store maturity predictions

• Draw up the process flow and interactions

Generate a vintage plan

Emailer




CSIRO maturity prediction

CSIROvintage

planning

Viticulture Database

• Draw up the process flow and interactions• Some basic experimenting and prototypes

CSIROvintage

planning

Emailer



SonicESB

Database Service

CSIRO vintage

planning

Transformation Service

XMLServer

Email Service

CSIRO maturity

prediction

The Solution (cont)• Service Policies

Calculate and store maturity predictions



SonicESB

Database Service

CSIRO vintage

planning


XMLServer

Email Service

CSIRO maturity

prediction

The Solution (cont)• Service Policies

Generate a vintage plan


Case Study Lessons• Think in terms of process flows• Whiteboards• Iterative approach• Prototyping and experimentation• Get the process right first (using service stubs), then

full out the services• Good interface contracts (Message Book)• Good stringent test cases (Positive & Negative)



Case Study: Pernod Ricard Pacific – ASN2

SonicESB

Database Service

CSIRO vvp(vintage

planning)


XMLServer

CSIRO matprid (maturity

prediction)

•Vintage plan direct from MS Excel

Web Service

Web Service



SonicESB

Database Service

CSIRO vvp(vintage

planning)


XMLServer

CSIRO matprid (maturity

prediction)

• Expose vintage plan to growers

Web Service

Web Service



• New way to calculate maturity predictions (agility)

SonicESB

Database Service

CSIRO vintage

planning


XMLServer

Email Service

CSIRO maturity

prediction

CSIRO maturity

prediction 2


Case Study: Pernod Ricard Pacific – ASN3?

SonicESB

Database Service

CSIRO vintage

planning


XMLServer

Email Service

CSIRO maturity

prediction

????? ?????

• More bright ideas, more brilliant results


Agenda








Common Pitfalls

Communication Breakdowns Not Enough Process Initial Project Failure Not Working Incrementally


Agenda








First Steps to Take When you Get Back Home

A SOA strategy is incremental and progressive• Have clear, realistic objectives

Be Strategic AND Tactical• Set your Vision and Implement in Steps

Success Factors

Steps to Success Define a SOA Vision to achieve business agility

Use high-value business projects for your first steps

Build and refine “just enough process” for your needs

Determine where you are in the SOA Maturity Model, your key goals and key practices to achieve the next level


For More Information, go to…

PSDN• A New Service-Oriented Architecture (SOA) Maturity Model

• Principles of a Service-Oriented Architecture• Service-Oriented Architecture: Overview and Business Drive

rs

• Design Best Practices: Methodology using Patterns • SOA Worst Practices, Volume 1• OpenEdge Evaluation Kit and Product Tour

Progress eLearning Community:• 4GL Development with XML• Consuming Web Services from OpenEdge• OpenEdge Development with Sonic ESB• SOAP for OpenEdge Developers• Service Oriented Integration with Sonic ESB


Relevant Exchange Sessions

Go Back and Review SOA-1: Applied SOA:Building Out Your SOA Environment with

OpenEdge SOA-4: Introduction to OpenEdge Integration Technologies SOA-11: Common Applications of Sonic ESB SOA-14: Continuous Integration in SOA Projects SOA-17: Introducing Native Invocation with the OpenEdge Adapter

for Sonic ESB SOA-15: Using Portal and Sonic ESB to Integrate Information from

Public Resources SOA-23: Enterprise Integration Patterns in Sonic ESB

Still to Come SOA-32: Progress SOA Portfolio Roadmap SOA-37: SOA Management with Actional for Sonic Live at Work SOA-41: Enabling Your OpenEdge Application with Web 2.0


Questions?


Thank You

exchange breakout notes

Documents