Use of SOA and Web Services Technologies for EA Migration - Lessons Learned on How to Sort it All Out

1May 22-24, 2007

Washington Dulles HiltonThe Business Transformation Conference

Lloyd DuganSenior Project Director/CTOInformation Engineering Services, Inc. (IES)

SessionTitle:

Use of SOA and Web Services Technologies forEA Migration – Lessons Learned on How ToSort It All Out

Lloyd DuganSenior Project Director/CTOInformation Engineering Services, Inc. (IES)

SessionTitle:

Use of SOA and Web Services Technologies forEA Migration – Lessons Learned on How ToSort It All Out

WelcomeWelcometo Transformation and Innovation 2007The Business Transformation Conference

2May 22-24, 2007


Biographical & Background Information

Speaker:– Over 20+ years in IT industry– Former Deloitte & Touch, Anteon, American Management Systems, and

Information Management Consultants; Duke MBA– Past speaker for AIIM, ARMA, Delphi Group, National BPR Conference,

and Mercury Interactive

Company:– IT management consulting and systems integration services company

founded in 1992 by Myles Reid; www.ie-services.com– Focused on housing, mortgage banking and insurance, real estate

management, securities market– Certified small disadvantage business, registered minority-owned business

enterprise; GSA Schedules– Headquartered in Alexandria, VA

Case Study Background– First project at HUD charged to do EA migration and design using SOA– Eventually settled on using Oracle SOA Suite as the SOA software

3May 22-24, 2007


OutlineLearning Objectives

SOA and Web Services Overview

SOA and Web Services Framework

SOA and Web Services With BPM

SOA and Web Services SDLC Methodology

SOA and Web Services for EA Migration

Final Considerations

References

Questions and Answers

4May 22-24, 2007


Learning Objectives

To Learn the Basics of SOA and Web ServicesWithin the Context of a Case Study

To Appreciate the Methodological ChallengesTo Doing SOA and Web Services Modeling

To Understand How SOA and Web ServicesCan Facilitate Migration To an EA

5May 22-24, 2007


SOA and Web Services OverviewWeb Services – True Reuse and Distributed Computing at Last?!

• Introduced reusability ofobjects and gave birth todesign patterns

• Inheritance inadvertentlymade for more objects(not fewer), leading togovernance problems

• System integrationachieved via specificinterface classes thatworked better in morehomogenousenvironments

• Supported reuse at thelevel of granularity definedby a particular component

• Data exchange viamessages needed tointegrate disparatesystems as components

• System integrationachieved via proprietaryapplication programminginterfaces (APIs) forheterogeneousenvironments

• Supported reuse of commonfunctions (e.g., transactionalintegrity) at application server

• Introduced use of XML asdata exchange format formessaging in support ofsystem integration

• System integration achievedvia standard APIs (for usingthe application server’sfunctions) and other,proprietary APIs (for specificsystems)

• Supports reuse at any levelof granularity applicable forthe underlying service

• Refined use of XML inmessaging and based it onstandards for messaging andtransport

• System integration achievedvia Web Services based onstandards-based APIs (forthe application server) andextensible system adapters(rather than specific APIs)

Object-Oriented

System Componentization

Enterprise Appli- cation Integration

Service-Oriented Architecture

Evolution Of Technologies To Support Reusability and Distributed Computing

6May 22-24, 2007


SOA and Web Services OverviewWeb Services Provisioning – Basic Model

Simple Object Access Protocol (SOAP). An XML-based,extensible message envelope format, with "bindings" tounderlying protocols (e.g., HTTP, HTTPS). J2EEapplication server support is via Java API for XMLProcessing (JAXP) and Java API for XML-based RPC(JAX-RPC). Microsoft has something similar for .NET.

Web Service Definition Language (WSDL). An XMLformat that allows service interfaces to be described,along with the details of their bindings to specificprotocols. It enables abstraction from the technology.

Universal Description Discovery and Integration (UDDI).A protocol for publishing and discovering metadataabout Web Services, to enable applications to find WebServices, either at design time or runtime. Used forPublic discovery of services, either Internet or intranet.Can be bundled with a more robust Service Registrythat supports a more comprehensive management ofWeb Services.

7May 22-24, 2007


SOA and Web Services OverviewXML Schema Document (XSD) – Message Structure Enforcement

XSD Can Be Used To SupportConstruction of the SOAPMessage and Its XML PayloadBy the Web Service Requestor

XSD Should Be Used To Validatethe XML Payload of Inbound andOutbound Messages Transportedor Processed By the Web Service

SOAP Message Contains XML Payload for Exchanging Data Between Service Requester andService Provider that Must Conform To Format Required By XSD Specified for the Web Service

XSD for Business Domain

Services

SOAP Message

WebService

Requestor

XMLPayload

WebService

UserOr System

System

Database

8May 22-24, 2007


SOA and Web Services OverviewMessage Exchange Patterns (MEPs) – Basic Types Supported

A B

Simple One-Way – aka “Fireand Forget”

A

C

D

BOne WayFanned-outOr Routed

Also Supported MEP – AsynchronousMEPs Because Process “A” Does Not

Require a Response Or ReceiptAcknowledgement To Continue

Executing Activities

Note: SOA Technologies Do Not Directly Support Other MEPs (e.g., Publish/Subscribe or Broadcast)

SOA Technologies Utilize Basic MEPs that Support the Simple Object Access Protocol(SOAP), Generally Over Hypertext Transport Protocol (HTTP) Or Secure HTTP (HTTPS)

A BSimple Request/Response– as in a RemoteProcedure Call (RPC)

D

C

A BRequest/ResponseFanned-out OrRouted

Primary Supported MEP – Invoked ComponentCan Respond Immediately In a Synchronous

MEP Or On a Delayed Basis In an AsynchronousMEP, Which May Or May Not Allow Process “A”

To Continue Executing Activities

9May 22-24, 2007


SOA and Web Services FrameworkWeb Service Classifications – Characterization of the Functionality

Domain Directory Service – Provides a single point of access to a “directory” of subordinate services used (e.g.,typically Orchestration Services) within a specific Business Domain (e.g., Case Processing), but may beunnecessary with the use of a Service Registry/Universal Description Discovery and Integration (UDDI) Server

Orchestration Service – “Orchestrates” the execution of business logic and data access, typically for a core end-to-end business process with internal constituents that are more coupled than other services external to theorchestration (e.g., another Orchestration Service), and will be system integration-centric (i.e., oriented towardsintegrating systems or data), human/document-centric (i.e., oriented towards human-mediated activities thattypically involve a document to provide context for the transaction being processed), or some combination

Task-Centric Service – Performs a discrete task or a highly coupled set of tasks that execute compact steps ofbusiness logic and/or data access with basic functionality and limited responsibilities, likely as a common servicethat is reusable and extensible (e.g., error handling, XML schema management, and business rules engine)

Entity-Centric Service – Performs data-related activities (apart from data access but inclusive of data transformationbased on mappings from legacy system data representations to standard ones) around a specific business entity(taken from an enterprise-wide data model representation of core business entities), typically as a common servicethat is reusable and extensible, which can be as Service Data Objects (SDOs) if the specification standard issupported and the data graph transformations (that implement the data mappings) are known

Application Service – Makes legacy system functionality and the data therein available at the invocation of anotherservice, but is constrained by the specific context and characteristics of the legacy functionality and data soexposed (i.e., the granularity of the service is defined by what the program does), with services being thoseprograms that can be invoked as remote procedure calls (RPCs) that can be utilized explicitly with the ServiceComponent Architecture (SCA) specification (i.e., using embedded coding) or implicitly (i.e., with SCA imposed viathe service design and management)

Data Service – Similar to an Application Service, but is a service that is strictly focused on posting to or queryingagainst legacy databases and/or new databases out of a common context rather than by going through the legacysystems themselves, which allows the data to be accessed and transformed in more flexible ways

Interface Service – Performs specific interface-level activities to bridge disparate system platforms via a systemadapter (e.g., Database Connector, CICS Transaction, FTP, etc.) that contains the interface-specific informationneeded to enable and support the connection

10May 22-24, 2007


SOA and Web Services FrameworkWeb Service Classifications – General Interaction Pattern [1]

Entity_CentricService

Application Service

Business Process Layer(Users/Uses of Services)

Legacy Layer

Ser

vice

Inte

rfac

e L

ayer

Data Service

LegacyDatabase

LegacySystem

Legacy System or Database Interface

Web Services Interface

System

Orchestration Service

Task_CentricService

Domain Directory Service

Orchestration Service

User

BusinessDomain

Business Domain

Business Domain

InterfaceService

InterfaceService

SupportsPrinciples of SCA

But Does NotExplicitly Rely On

the SCASpecification

–

ShiftsArchitecture fromSystem-focus To

Service-focus!

11May 22-24, 2007


SOA and Web Services FrameworkWeb Service Types – Implementing Technology on Oracle SOA Suite

Business Process Execution Language (BPEL) Web Service– Is a BPEL process (standard term) that is natively already exposed as a web service, and is

best suited for dealing with modestly complex routing logic (e.g., data transformationstogether with multiple conditional routing based on that data) and message exchangepatterns (e.g., asynchronous request/reply communications)

Adapter Web Service– Is a system adapter (standard term) for bridging disparate system platforms (e.g., Database

Connector Adapter) that is natively already exposed as a web service, and further breaksdown by the specific type of adapter needed to bridge to a particular system platform.

AvailableWithInstalledVersion ofOracle SOASuite andUsed in theDesign

Available butNot Used inDesign

NotAvailableWithInstalledVersion ofOracle SOASuite

Enterprise Java Bean (EJB) Web Service– Is an EJB class (standard term) that has been explicitly exposed as a web service, and is

best suited for dealing with highly complex business logic and message exchange patterns

Enterprise Service Bus (ESB) Web Service– Is an ESB project (Oracle term) that is natively already exposed as a web service, and is

best suited for dealing with simple routing logic (e.g., single conditional routing based ondata only) and message exchange patterns (e.g., synchronous request/replycommunications)

Business Rules Engine (BRE) Web Service– Is a BRE dictionary (Oracle term) of one or more sets of business rules (e.g., testing a

business value against regulatory limit) that is natively already exposed as a web service(called the Decision Service), and is best suited for dealing with straightforward businessrules that govern how specific functions occur and/or how specific data is treated

12May 22-24, 2007


SOA and Web Services With BPMWorkflow Patterns (WPs) – Basic Types Supported

A BSequence – One Activity Leads To Another(Process “A” Finishes and then Starts Process “B”)

BC

D

Parallel – One Activity Splits Into SeparateThreads that Continue (Process “B” Splits IntoProcesses “C” and “D” that Execute Together)

EC

D

Synchronization – One Activity Begins AfterFeeder Threads Complete (Processes “C” and “D”Must Both Finish Before Process “E” Can Start)

C

D

E

Merge – Separate ThreadsConverge Into Single Next ActivityWithout Synchronization (Process“C” or “D” Must Finish BeforeProcess “E” Can Start)

EF

G

Choice – Single ExclusiveThread Is Launched Or MultipleThreads Are Launched(Processes “F” and/or “G” StartBased On a Decision AboutData Addressed In Process “E”)

Note: SOA Technologies Do Not Directly Support Other WPs (e.g., Arbitrary Cycles Used for Collaborative Activities)

SOA Technologies Can Support Basic WPs that Support Work Activities,Typically With Compatible Business Process Management (BPM) Tools [2]

13May 22-24, 2007


SOA and Web Services With BPMDifferent BPM – Technology Focus for Business Solution

Shift multiple bi-lateral system-to-systemcommunications to centralized hub-and-spoke

Generally MEP-oriented systemintegration with middleware services

Usually data-oriented (dataflow/synchronization)

Shift multiple disparate user-mediatedactivities to use a single user interface andengine

Generally WP-oriented process integrationof back-office systems

Usually process-oriented (processflow/synchronization)

E

F

G

E

F

G

P

More Human/Document-Centric BPM

O

L

D

N

E

W

A B

DC

S

A B

C D

More System Integration-Centric BPM

N

E

W

O

L

D

14May 22-24, 2007


SOA and Web Services With BPMBusiness Process Modeling and Management – BPEL

Business Process Execution Language (BPEL) is a standards-based language that is defined andmaintained by OASIS (http://www.oasis-open.org/home/index.php)

– Version 1.1 has widespread deployment, especially among platform vendors– Version 2.0 is well underway

XML-variant that “executes” like script in the BPEL engine (on the J2EE application server) as it isinterpreted

– Runs as a first class citizen in the Java container of the J2EE application server– Supports Web Services, XPath, XSLT, and XQuery technologies– Was a synthesis of predecessor languages (IBM’s WSFL and Microsoft’s XLANG), but has evolved

significantly beyond its beginning

Provides a standards-based, abstract process programming language for expressing businessprocesses

– Independent of the underlying applications that support those activities (as with any Web Service, theWSDL file hides the interface implementation details)

– Generalist, jack-of-all-trades type of BPM product that runs on the J2EE application server– Simple monitoring and management controls embedded with the application server– Wizard-based configuration/scripting via diagramming on an integrated development environment (IDE)

tool to model and create BPEL script– Functionality is implemented more by way of implemented design pattern rather than stand-alone

technology– Requires custom-developed or 3rd party web client user interface if human mediation is required– Relies on adapters and Web Services, and focuses more on system integration problems– Exchanges between pure BPM modelers (those using Business Process Management Notation (BPMN)

are lossy

BPEL processes (BPEL, XSD, and WSDL files) are (theoretically) transferable from one BPELengine to another – though worries about underlying differences in the adapters and J2EEapplication server Java persist (with me anyway!)

15May 22-24, 2007


<process name="Interface_Controller" targetNamespace="http://xmlns.oracle.com/Interface_Controller" xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/" ... > <partnerLinks> <partnerLink name="client" partnerLinkType="client:Interface_Controller"

myRole="Interface_ControllerProvider"/> <partnerLink name="OracleDatabase" partnerRole="oracleDatabaseAdapter_role"

partnerLinkType=" ns7:oracleDatabaseAdapter_plt "/> </partnerLinks> <variables> <variable name= ... > ... </variables> <sequence name="main"> ... <invoke name="Invoke_TransactionInfoQuery" partnerLink="OracleDatabase"

portType=" ns7:oracleDatabaseAdapter_ptt " operation="oracleDatabaseAdapterSelect_transaction_id"inputVariable="Invoke_TransactionInfoQuery_Input"outputVariable="Invoke_TransactionInfoQuery_Output"/>

... </sequence></process>

BPEL Process To Do aDatabase Lookup

BPEL Process is an XMLVariant that Needs theRuntime BPEL Engine (e.g.,Oracle BPEL ProcessManager) To Interpret and“Execute” the Script

Partner Link is To anExternal Service

Provider (e.g., Database)BPEL ProcessInvokes an Interface

Web Service

Corresponds to aWSDL File forthe Web Service

Oracle Database AdapterInvoked as a Web Service

Partner Links Partner Links

ReceiveInput

Assign_TransactionInfoQuery

Invoke_TransactionInfoQuery

client

ReplyInput

OracleDatabase

SOA and Web Services With BPMBPEL Process – Simple Example

16May 22-24, 2007


SOA and Web Services SDLC MethodologyBusiness Domain as Scope for Web Services Modeling

Business Domain Level (Case Processing)

Bottom-Up Approach:• Examine Legacy System for System Functionality and Data• Review Utilized Components for Use as Candidate Services

Top-Down Approach:• Localize Business Domain To a Realistic Set for First SOA

• Preserve Fit Within Larger Context To Facilitate ExtensibilitySingle Family Housing

Loan Origination

Case Processing

Line ofBusiness

Major Functionor Module

Sub-Function

Cold Fusion

Front-end

UnisysMainframe

Back-Office

Portal LevelFunctionalityand Screens

Back-OfficeSystem

Functionality

Utilize Comprehensive Business ProcessModel Or Proxy for Such a Model

BusinessProcesses

LargerGrainedServices

SmallerGrainedServices

Combine Top-Down with Bottom-Up [3] BusinessProcesses

BusinessProcesses

BusinessProcesses

BusinessProcesses

Reverse Engineer Core Systems FromSource Code and Other Documentation

17May 22-24, 2007


SOA and Web Services SDLC MethodologyAssumptions and SOA-Based Modeling Principles

Assumptions:– Minimize Or Avoid Changes Made To the Invocations of Legacy Systems As a Result of Changes Made

To the Calling Service Clients (screens/other systems)

– Anticipate Future Security Issues With Respect To Web Services As Best As Possible By HonoringExisting Protocol for System Accounts and Passwords

– Design for Web Services To Be By HTTP Behind the Firewall for System-To-System Exchanges and byHTTPS (with Transport Layer Security or Secure Socket Layer) Across the Firewall for External Users

SOA-Based Modeling Principles:– Model Web Services As a Stereotype Classes with UML Class Diagrams and Sequence Diagrams,

Incorporating Descriptive Attributes for the Web Services

– Model Web Services To Function In Support of Any Type of Service Requester Interface To PromoteReusability and Extensibility Across the Enterprise

– Adapt Design Patterns for Use With BPEL Processes and Adapters Where Appropriate To Help ToEnsure Sound and Extensible System Design [4]

– Optimize Connections Between Services In Order To Balance Manageability of Services Against theReusability of Services, and To Minimize Overhead

– Keep Common Services at a Basic Level of Functionality With a Limited Set of Responsibilities To BestLeverage Common Usage By Other Services

– Model and Utilize Common Data Structures and Validation Service Where Feasible for Web ServiceXML Payloads To Minimize Data Structure Management Burden

18May 22-24, 2007


SOA and Web Services SDLC MethodologyWeb Services as Modeled and Configuration Managed SDLC Artifacts

Web Service

Basic Level Attributes

Basic Level Operations

Web Service Type

Type Level Attributes

Type Level Operations

Web Service Classification

Classification Lvl Attributes

Classification Lvl Operations

Specializes To

• BPEL Process Name• BPEL Engine Version Number

• Adapter Type• Adapter Version Number

• Web Service Type• Web Service Classification• Web Service Name• Web Service Version Number• WSDL Name• Etc.

• Application RPC Name • Legacy System Interface Information

Specific Web Service Operations Are Defined At This Level – In the Case of a BPEL Process, Operations Correspond To a BPEL Process Diagram and Executable Script

Adapted UML Treats Web Services With Class Diagrams as a Superclass that DecomposesBy Web Service Type (for the Technology) and Classification (for the Functionality)

Specializes To

19May 22-24, 2007


SOA and Web Services SDLC MethodologyWeb Services Modeled To Fit Basic Common Interaction Design Pattern

ServiceInterface

DomainDirectory

ProcessOrchestration

SchemaChecker

ApplicationRPC

DatabaseQuery

SystemAdapter

LegacyInterface

ServiceRequester

RequestService

InvokeService

InvokeXMLCheck

InvokeOrchestration

AssignOrchestration

AssignProcess

InvokeQueryInvokeAdapter

SubmitRequest

ApplicableOrchestration

Option

ApplicableProcessOption

ApplicableProcessOption

TypicalSynchronous

MEPs WithServices and

Systems

CommonBasic WPs

forProcessActivities

AdaptedUML

DiagramsModel theProcesses

InvokeRPCInvokeAdapter SubmitRequest

20May 22-24, 2007


SOA and Web Services SDLC MethodologyXSD Modeling – Simple Data Dictionary Example and Key Concepts

properties

<xsd:name="CAIVRSBorrowerAuthorizationCaseInfo"> <xsd:sequence> <xsd:element name="caseNumber" type="xsd:string" nillable="true" minOccurs="0“ maxOccurs="1"/> <xsd:element name="caseType" type="xsd:string" nillable="true" minOccurs="0“ maxOccurs="1"/> </xsd:sequence></xsd:complexType>

source

used by

caseNumber caseTypechildren

http://www.hud.gov (placeholder)namespace

diagram

requestCAIVRSAuthorization/caseInfoelement

complexcontent

unboundedmaxOcc

0minOcc

0isRef

Hierarchy: Means that the XSD file(like any XML file) contains nestedtagged items, and tagged items canbe subordinate XSD files orelements or a mix, which requiresmodeling of the XSDs

Usage: Means that child XSDs maybe used as constituent componentsin more than one parent, which theXSD model must capture/manage

Mapping: Referencing of XSDs inspecific Web Services can bemapped, including referencing howthe XML payload must look

Optionality: Means that theinstance of an element (i.e., atagged item) or set of elements inan XML file referencing a specificXSD only appears if there is anactual value

Cardinality: Sets the number ofinstances of an element or set ofelements in an XML file referencinga specific XSD

Nillability: Means that the instanceof an element or set of elements inan XML file referencing a specificXSD can appear without a value

Low-Level XSDs Consistof Tagged Elements Only

21May 22-24, 2007


SOA and Web Services SDLC MethodologyXSD Modeling - Modeling XML Payload Characteristics

<firstName>john</firstName>Or

<firstName>john</firstName><firstName>bob</firstName>

Cardinality: Tagged item corresponding to an XSD element means that up to the specified limitcan appear in the XML file (but it could be less)


<firstName></firstName>

Nillability: Tagged item corresponding to a nillable XSD element means that it may appear inthe XML file without any actual value present if none existed

<firstName>john</firstName>


No Element Appears At All

Optionality: Tagged item corresponding to an XSD element only appears in the XML file if thevalue “john” is actually present

<xsd:element name=“firstName" type="xsd:string" nillable=“false" minOccurs=“1“ maxOccurs=“1"/>



<xsd:element name=“firstName" type="xsd:string" nillable=“true" minOccurs=“1“ maxOccurs=“1"/>

22May 22-24, 2007


SOA and Web Services for EA MigrationInitial Highly Coupled Interfaces Between Front-End and Back-Office Systems

Front-End System (Cold Fusion) Back-Office System (Unisys)

U

N

I

A

C

C

E

S

S

Hitachi Mainframe System

Interface File

User

Red Functional Thread = Update Case

Blue Functional Thread = Perform Query

Gold Functional Thread = Submit Application

= Cold Fusion/JavaScript/HTML

= Mainframe COBOL programs

= Control or data flow

= Query flow

= Data record types or tables

= JSPs/HTML/EJBs

= BPEL (or ESB) and Adapters

Key:

* UniAcesss is a type of middleware for Unisys thatpermits a relational database type of connectionbetween a calling client (the Cold Fusion server) andthe mainframe applications (COBOL programs asstored procedures) and database (as RDMS tables)

*

23May 22-24, 2007


SOA and Web Services for EA MigrationLoosely Coupled Interfaces Between New Portal and Back-Office System

U

N

I

A

C

C

E

S

S

New Portal (JSP/EJB+BPEL) Back-Office System (Unisys) Hitachi Mainframe SystemUser

Interface File

** New portal replaces the front-end Cold Fusionsystem (as the calling client) to the back-office Unisysmainframe system (as the server), using JSP/EJB andBPEL code, and continues to invoke the storedprocedures as RPCs and queries of the RDMS tablesnow exposed via Web Services rather than direct calls




= Query flow


= JSPs/HTML/EJBs


Key:

**

24May 22-24, 2007


SOA and Web Services for EA MigrationPartial Replacement of Back-Office System During Parallel Operation/Testing

U

N

I

A

C

C

E

S

S

Interface File

New Portal (JSP/EJB+BPEL) Back-Office Database (Unisys) Hitachi Mainframe SystemUser




= Query flow


= JSPs/HTML/EJBs


Key:

***

*** Business logic previously in COBOL programs nowresides in new J2EE platform as JSP/EJB+BPEL code,but dual database posting (new and old) preservesdata integrity during transition to full replacement

25May 22-24, 2007


SOA and Web Services for EA MigrationFull Replacement of Back-Office System and Standalone Operation

Interface File

New Portal and System (JSP/EJB+BPEL) Hitachi Mainframe SystemUser




= Query flow


= JSPs/HTML/EJBs


Key:

****

**** New portal and system now fully provide the functionality offormer legacy systems, which have now been architected asconstructs of extensible and reusable Web Services

26May 22-24, 2007


Final ConsiderationsSOA and Web Services – Methodological Considerations for EA Migration:

– Waterfall-based SDLC is ill-suited for object-oriented modeling and UML for J2EE design, iterativedevelopment (e.g., RUP), and modeling and migrating to Web Services, but adaptation is possible

– XSD element naming is problematic because of tension between application-level needs (localspecificity and brevity) and enterprise-level standards needs (global specificity and verbosity)

– Must balance EA priorities and objectives with system design priorities and objectives by “architectingglobally” for the Web Services while “designing locally” for the desired interim/replacement systems

SOA and Web Services – Technical Considerations for EA Migration:– Oracle BPEL will work, but full Oracle SOA would be better, including ESB, BRE, Web Service

Manager, and UDDI/Service Registry, but governance issues grow larger– Newness of XML messaging is challenging because of likely network consumption intensity and lack

of UDDI/Service Registry support (for finding Web Services) – may need isolated network segment– Security considerations do not yet account for Web Services, including encryption for the XML

payload in the SOAP messages, but system accounts and passwords with SSL or TLS is still okay

SOA and Web Services – Transition Role Considerations for EA Migration:– Alignment between Client’s vision and LOB EA Migration sometimes can be lacking actionable steps

because of contractual and funding dimensions to modernization activities– Combining Project Management Support Office services and SDLC responsibilities is problematic

because of competing focuses and constituencies, and overlapping EA migration concerns– Reverse engineering legacy systems is often burdened by inadequate and incomplete system

documentation, and incumbent and system owner resistance to (unfunded?!) cooperation– Legacy system operation and maintenance contracts can inhibit transition because of the number of

legacy systems and the many different timetables and activities that are driven by parochial interests

27May 22-24, 2007


References

[1] Many elements of the methodology trace back to principles advocated and suggestions made by a leading SOAexpert, Thomas Erl, in his seminal work titled Service-Oriented Architecture: Concepts, Technology and Design, 2005

[2] (A) For a dated but fascinating comparison of Workflow Patterns and Communication Patterns with BPEL andselected workflow products, see “Pattern Based Analysis of BPEL4WS” (Technical Report FIT-TR-2002-04,Queensland University of Technology) by Petia Wohed (Department of Computer and Systems Sciences, StockholmUniversity/The Royal Institute of Technology, Sweden, [email protected]), Wil M.P. van der Aalst (Department ofTechnology Management Eindhoven University of Technology, The Netherlands, [email protected]), andMarlon Dumas and Arthur H.M. ter Hofstede (Centre for Information Technology Innovation Queensland University ofTechnology (QUT), Australia, [email protected] and [email protected]), 2003; (B) For a comparison ofprocess modeling notations with respect to Workflow Patterns, see “Process Modeling Notations and WorkflowPatterns” by Stephen A. White - IBM, February 2005 athttp://www.bpmn.org/Documents/Notations%20and%20Workflow%20Patterns.pdf; (C) For a different treatment, see“Toward Workflow Block Activity Patterns for Reuse in Workflow Design” by Lucineia Heloisa Thom and CiranoIochepe (Federal University of Rio Grande do Sul, Brazil) and Vinicius Amaral and Daniel Viero (iProcess, Brazil) in2006 Workflow Handbook, Workflow Management Coalition and Future Strategies Inc., ISBN 0-9777527-0-4

[3] See “How To Identify, Specific, and Realize Services for Your SOA” in WebSphere Journal by Ali Arsanjani athttp://websphere.sys-con.com/read/48879.htm.

[4] See Design Patterns – Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, RalphJohnson, John Vlissides, 1995 Edition

28May 22-24, 2007


Questions and Answers

29May 22-24, 2007


ThankYouLloyd DuganSenior Project Director/CTOInformation Engineering Services, Inc. (IES)

Contact Information:

(O) 703-562-0040; (C) [email protected]