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

Welcome
to Transformation and Innovation 2007
The Business Transformation Conference

Lloyd Dugan
Senior Project Director/CTO
Information Engineering Services, Inc. (IES)
SessionTitle:
Use of SOA and Web Services Technologies for
EA Migration – Lessons Learned on How To
Sort It All Out

May 22-24, 2007 1
The Business Transformation Conference Washington Dulles Hilton

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

May 22-24, 2007 2

Outline
Learning 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
May 22-24, 2007 3

Learning Objectives

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

To Appreciate the Methodological Challenges
To Doing SOA and Web Services Modeling

To Understand How SOA and Web Services
Can Facilitate Migration To an EA

May 22-24, 2007 4

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

Evolution Of Technologies To Support Reusability and Distributed Computing

Object- System Enterprise Appli- Service-Oriented
Oriented Componentization cation Integration Architecture

• Introduced reusability of • Supported reuse at the • Supported reuse of common • Supports reuse at any level
objects and gave birth to level of granularity defined functions (e.g., transactional of granularity applicable for
design patterns by a particular component integrity) at application server the underlying service
• Inheritance inadvertently • Data exchange via • Introduced use of XML as • Refined use of XML in
made for more objects messages needed to data exchange format for messaging and based it on
(not fewer), leading to integrate disparate messaging in support of standards for messaging and
governance problems systems as components system integration transport
• System integration • System integration • System integration achieved • System integration achieved
achieved via specific achieved via proprietary via standard APIs (for using via Web Services based on
interface classes that application programming the application server’s standards-based APIs (for
worked better in more interfaces (APIs) for functions) and other, the application server) and
homogenous heterogeneous proprietary APIs (for specific extensible system adapters
environments environments systems) (rather than specific APIs)

May 22-24, 2007 5

Web Services Provisioning – Basic Model

Simple Object Access Protocol (SOAP). An XML-based,
extensible message envelope format, with quot;bindingsquot; to
underlying protocols (e.g., HTTP, HTTPS). J2EE
application server support is via Java API for XML
Processing (JAXP) and Java API for XML-based RPC
(JAX-RPC). Microsoft has something similar for .NET.

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

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

May 22-24, 2007 6

XML Schema Document (XSD) – Message Structure Enforcement

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

XSD for
XSD Can Be Used To Support XSD Should Be Used To Validate
Business Domain
Construction of the SOAP the XML Payload of Inbound and
Message and Its XML Payload Outbound Messages Transported
Services
By the Web Service Requestor or Processed By the Web Service

System
SOAP Message

Web
XML Web
User Service
Payload Service
Or System Requestor
Database

May 22-24, 2007 7

Message Exchange Patterns (MEPs) – Basic Types Supported

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

Simple One-
Simple Request/Response
A B Way – aka “Fire
– as in a Remote A B
and Forget”
Procedure Call (RPC)
C
C Request/Response One Way
A B Fanned-out Or Fanned-out
A B
Routed Or Routed
D
D

Primary Supported MEP – Invoked Component Also Supported MEP – Asynchronous
Can Respond Immediately In a Synchronous MEPs Because Process “A” Does Not
MEP Or On a Delayed Basis In an Asynchronous Require a Response Or Receipt
MEP, Which May Or May Not Allow Process “A” Acknowledgement To Continue
To Continue Executing Activities Executing Activities

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

May 22-24, 2007 8

Web 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 be
unnecessary 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 the
orchestration (e.g., another Orchestration Service), and will be system integration-centric (i.e., oriented towards
integrating systems or data), human/document-centric (i.e., oriented towards human-mediated activities that
typically 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 of
business logic and/or data access with basic functionality and limited responsibilities, likely as a common service
that 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 transformation
based 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 service
that is reusable and extensible, which can be as Service Data Objects (SDOs) if the specification standard is
supported 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 another
service, but is constrained by the specific context and characteristics of the legacy functionality and data so
exposed (i.e., the granularity of the service is defined by what the program does), with services being those
programs that can be invoked as remote procedure calls (RPCs) that can be utilized explicitly with the Service
Component Architecture (SCA) specification (i.e., using embedded coding) or implicitly (i.e., with SCA imposed via
the service design and management)

Data Service – Similar to an Application Service, but is a service that is strictly focused on posting to or querying
against legacy databases and/or new databases out of a common context rather than by going through the legacy
systems 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 system
adapter (e.g., Database Connector, CICS Transaction, FTP, etc.) that contains the interface-specific information
needed to enable and support the connection

May 22-24, 2007 9

Web Service Classifications – General Interaction Pattern [1]

Business Process Layer System
User
(Users/Uses of Services)
Web Services Interface
Business Business

Service Interface Layer
Business
Supports
Domain Domain
Domain
Principles of SCA Domain Directory
But Does Not Service
Explicitly Rely On
the SCA
Specification Task_Centric Entity_Centric
Orchestration Orchestration
Service Service
– Service Service
Shifts
Architecture from
System-focus To
Service-focus!
Application Data
Service Service
Interface Interface
Service Service

Legacy System or Database Interface

Legacy Legacy
System Database
Legacy Layer

May 22-24, 2007 10

Web Service Types – Implementing Technology on Oracle SOA Suite

Business Process Execution Language (BPEL) Web Service
Available
With – 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 transformations
Installed
together with multiple conditional routing based on that data) and message exchange
Version of patterns (e.g., asynchronous request/reply communications)
Oracle SOA
Suite and Adapter Web Service
Used in the – Is a system adapter (standard term) for bridging disparate system platforms (e.g., Database
Design Connector Adapter) that is natively already exposed as a web service, and further breaks
down by the specific type of adapter needed to bridge to a particular system platform.

Enterprise Java Bean (EJB) Web Service
Available but
Not Used in – 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
Design

Enterprise Service Bus (ESB) Web Service
Not – 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 on
Available
data only) and message exchange patterns (e.g., synchronous request/reply
With
communications)
Installed
Version of Business Rules Engine (BRE) Web Service
Oracle SOA
– Is a BRE dictionary (Oracle term) of one or more sets of business rules (e.g., testing a
Suite 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 business
rules that govern how specific functions occur and/or how specific data is treated

May 22-24, 2007 11

Workflow Patterns (WPs) – Basic Types Supported

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

Merge – Separate Threads
Sequence – One Activity Leads To Another
A B
Converge Into Single Next Activity
(Process “A” Finishes and then Starts Process “B”) C
Without Synchronization (Process
E
“C” or “D” Must Finish Before
D
Parallel – One Activity Splits Into Separate Process “E” Can Start)
C
Threads that Continue (Process “B” Splits Into
B
D Processes “C” and “D” that Execute Together)
Choice – Single Exclusive
Thread Is Launched Or Multiple
F
Synchronization – One Activity Begins After Threads Are Launched
C
E
E Feeder Threads Complete (Processes “C” and “D” (Processes “F” and/or “G” Start
G
D
Must Both Finish Before Process “E” Can Start) Based On a Decision About
Data Addressed In Process “E”)

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

May 22-24, 2007 12

Different BPM – Technology Focus for Business Solution

More System Integration-Centric BPM More Human/Document-Centric BPM

A B A B E E
O N O N
L S E L F P F E
D W D W
C D C D G G

Shift multiple bi-lateral system-to-system Shift multiple disparate user-mediated
communications to centralized hub-and- activities to use a single user interface and
spoke engine

Generally MEP-oriented system Generally WP-oriented process integration
integration with middleware services of back-office systems

Usually data-oriented (data Usually process-oriented (process
flow/synchronization) flow/synchronization)

May 22-24, 2007 13

Business Process Modeling and Management – BPEL
Business Process Execution Language (BPEL) is a standards-based language that is defined and
maintained 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 is
interpreted
– 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 business
processes
– Independent of the underlying applications that support those activities (as with any Web Service, the
WSDL 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 BPEL
engine to another – though worries about underlying differences in the adapters and J2EE
application server Java persist (with me anyway!)

May 22-24, 2007 14

BPEL Process – Simple Example
Partner Links Partner Links
BPEL Process To Do a
Database Lookup

Partner Link is To an
ReceiveInput

External Service
BPEL Process Provider (e.g., Database)
Invokes an Interface
Assign_TransactionInfoQuery

Web Service
client

OracleDatabase
Invoke_TransactionInfoQuery

Corresponds to a
WSDL File for
ReplyInput
the Web Service

<process name=quot;Interface_Controllerquot; targetNamespace=quot;http://xmlns.oracle.com/Interface_Controllerquot;
xmlns=quot;http://schemas.xmlsoap.org/ws/2003/03/business-process/quot; ... >
<partnerLinks>
<partnerLink name=quot;clientquot; partnerLinkType=quot;client:Interface_Controllerquot;
myRole=quot;Interface_ControllerProviderquot;/>
<partnerLink name=quot;OracleDatabasequot; partnerRole=quot;oracleDatabaseAdapter_rolequot;
partnerLinkType=quot; ns7:oracleDatabaseAdapter_plt quot;/>
BPEL Process is an XML
</partnerLinks>
Variant that Needs the
<variables>
Oracle Database Adapter
<variable name= ... >
Runtime BPEL Engine (e.g.,
...
Invoked as a Web Service
Oracle BPEL Process
</variables>
<sequence name=quot;mainquot;>
Manager) To Interpret and
...
“Execute” the Script
<invoke name=quot;Invoke_TransactionInfoQueryquot; partnerLink=quot;OracleDatabasequot;
portType=quot; ns7:oracleDatabaseAdapter_ptt quot; operation=quot;oracleDatabaseAdapterSelect_transaction_idquot;
inputVariable=quot;Invoke_TransactionInfoQuery_Inputquot;
outputVariable=quot;Invoke_TransactionInfoQuery_Outputquot;/>
...
</sequence>
</process>

May 22-24, 2007 15

Business Domain as Scope for Web Services Modeling

Utilize Comprehensive Business Process
Model Or Proxy for Such a Model
Top-Down Approach:
Line of • Localize Business Domain To a Realistic Set for First SOA
Single Family Housing
Business • Preserve Fit Within Larger Context To Facilitate Extensibility
Major Function
Loan Origination
or Module Larger
Sub- Grained
Business Domain Level (Case Processing)
Case Processing
Function Services
Business Business
Processes Processes
Combine Top-Down with Bottom-Up [3] Smaller
Business
Grained
Processes
Services
Business Business
Processes Processes
Reverse Engineer Core Systems From
Source Code and Other Documentation

Portal Level Back-Office
Bottom-Up Approach:
Functionality System
• Examine Legacy System for System Functionality and Data
and Screens Functionality
• Review Utilized Components for Use as Candidate Services
Cold Unisys
Fusion Mainframe
Front-end Back-Office

May 22-24, 2007 16

Assumptions 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 Honoring
Existing Protocol for System Accounts and Passwords
– Design for Web Services To Be By HTTP Behind the Firewall for System-To-System Exchanges and by
HTTPS (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 Promote
Reusability and Extensibility Across the Enterprise
– Adapt Design Patterns for Use With BPEL Processes and Adapters Where Appropriate To Help To
Ensure Sound and Extensible System Design [4]
– Optimize Connections Between Services In Order To Balance Manageability of Services Against the
Reusability of Services, and To Minimize Overhead
– Keep Common Services at a Basic Level of Functionality With a Limited Set of Responsibilities To Best
Leverage Common Usage By Other Services
– Model and Utilize Common Data Structures and Validation Service Where Feasible for Web Service
XML Payloads To Minimize Data Structure Management Burden

May 22-24, 2007 17

Web Services as Modeled and Configuration Managed SDLC Artifacts

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

• Web Service Type
Web Service • Web Service Classification
• Web Service Name
Basic Level Attributes
• Web Service Version Number
• WSDL Name
Basic Level Operations
• Etc.
Specializes To

Web Service Type
• Adapter Type
• BPEL Process Name
Type Level Attributes
• Adapter Version Number
• BPEL Engine Version Number
Type Level Operations

Specializes To

Web Service Classification

Classification Lvl Attributes • Application RPC Name • Legacy System Interface Information

Classification Lvl Operations
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

May 22-24, 2007 18

Web Services Modeled To Fit Basic Common Interaction Design Pattern

Service Service Domain Process Schema Application Database System Legacy
Requester Interface Directory Orchestration Checker RPC Query Adapter Interface
RequestService
InvokeService Typical
Synchronous
InvokeXMLCheck
Adapted
MEPs With
UML
Services and
Diagrams
Systems
AssignOrchestration
Model the
Processes Applicable InvokeOrchestration
Orchestration
Option AssignProcess

Applicable InvokeRPC
InvokeAdapter
Process SubmitRequest
Option
Common
Basic WPs
for
Applicable
Process InvokeQuery
InvokeAdapter
Process
Activities
SubmitRequest
Option

May 22-24, 2007 19

XSD Modeling – Simple Data Dictionary Example and Key Concepts
Hierarchy: Means that the XSD file
(like any XML file) contains nested
tagged items, and tagged items can
be subordinate XSD files or
elements or a mix, which requires
modeling of the XSDs
diagram
Low-Level XSDs Consist
Usage: Means that child XSDs may
of Tagged Elements Only
be used as constituent components
in more than one parent, which the
namespace http://www.hud.gov (placeholder) XSD model must capture/manage

Mapping: Referencing of XSDs in
children caseNumber caseType
specific Web Services can be
mapped, including referencing how
used by
the XML payload must look
element requestCAIVRSAuthorization/caseInfo

source <xsd:name=quot;CAIVRSBorrowerAuthorizationCaseInfoquot;>
<xsd:sequence> Optionality: Means that the
<xsd:element name=quot;caseNumberquot; type=quot;xsd:stringquot; nillable=quot;truequot; minOccurs=quot;0“ maxOccurs=quot;1quot;/> instance of an element (i.e., a
<xsd:element name=quot;caseTypequot; type=quot;xsd:stringquot; nillable=quot;truequot; minOccurs=quot;0“ maxOccurs=quot;1quot;/> tagged item) or set of elements in
</xsd:sequence> an XML file referencing a specific
</xsd:complexType> XSD only appears if there is an
actual value
properties
Cardinality: Sets the number of
isRef 0
instances of an element or set of
elements in an XML file referencing
minOcc 0
a specific XSD
maxOcc unbounded
Nillability: Means that the instance
content complex
of an element or set of elements in
an XML file referencing a specific
XSD can appear without a value

May 22-24, 2007 20

XSD Modeling - Modeling XML Payload Characteristics

Optionality: Tagged item corresponding to an XSD element only appears in the XML file if the
value “john” is actually present
<xsd:element name=“firstNamequot; type=quot;xsd:stringquot; nillable=“falsequot; minOccurs=“1“ maxOccurs=“1quot;/> <firstName>john</firstName>

<firstName>john</firstName>
<xsd:element name=“firstNamequot; type=quot;xsd:stringquot; nillable=“falsequot; minOccurs=“0“ maxOccurs=“1quot;/>
Or
No Element Appears At All

Cardinality: Tagged item corresponding to an XSD element means that up to the specified limit
can appear in the XML file (but it could be less)
<xsd:element name=“firstNamequot; type=quot;xsd:stringquot; nillable=“falsequot; minOccurs=“1“ maxOccurs=“2quot;/>
Or
<firstName>bob</firstName>

Nillability: Tagged item corresponding to a nillable XSD element means that it may appear in
the XML file without any actual value present if none existed
<xsd:element name=“firstNamequot; type=quot;xsd:stringquot; nillable=“truequot; minOccurs=“1“ maxOccurs=“1quot;/>
Or
<firstName></firstName>

May 22-24, 2007 21

Initial Highly Coupled Interfaces Between Front-End and Back-Office Systems

User Front-End System (Cold Fusion) Back-Office System (Unisys) Hitachi Mainframe System

ce File
Interfa

U
N
I
A
C
C Key:
Red Functional Thread =
Update Case E = Cold Fusion/JavaScript/HTML
Blue Functional Thread = S = Mainframe COBOL programs
Perform Query
S = Control or data flow
Gold Functional Thread =
= Query flow
Submit Application *
= Data record types or tables
* UniAcesss is a type of middleware for Unisys that
permits a relational database type of connection = JSPs/HTML/EJBs
between a calling client (the Cold Fusion server) and
= BPEL (or ESB) and Adapters
the mainframe applications (COBOL programs as
stored procedures) and database (as RDMS tables)

May 22-24, 2007 22

Loosely Coupled Interfaces Between New Portal and Back-Office System

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

ile
eF
rfac
Inte

U
N
I
A
C
C Key:
E = Cold Fusion/JavaScript/HTML
S = Mainframe COBOL programs
** New portal replaces the front-end Cold Fusion
system (as the calling client) to the back-office Unisys = Query flow
mainframe system (as the server), using JSP/EJB and
BPEL code, and continues to invoke the stored
procedures as RPCs and queries of the RDMS tables
= JSPs/HTML/EJBs
now exposed via Web Services rather than direct calls

May 22-24, 2007 23

Partial Replacement of Back-Office System During Parallel Operation/Testing

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

ile
eF
rfac
Inte

U
N
I
A
C
C Key:

E = Cold Fusion/JavaScript/HTML

S = Mainframe COBOL programs


= Query flow

*** Business logic previously in COBOL programs now = JSPs/HTML/EJBs
resides in new J2EE platform as JSP/EJB+BPEL code,
but dual database posting (new and old) preserves = BPEL (or ESB) and Adapters
data integrity during transition to full replacement

May 22-24, 2007 24

Full Replacement of Back-Office System and Standalone Operation
User New Portal and System (JSP/EJB+BPEL) **** Hitachi Mainframe System

ile
eF
c
rfa
te
In

Key:

= Cold Fusion/JavaScript/HTML

= Mainframe COBOL programs

= Control or data flow

= Query flow


= JSPs/HTML/EJBs
**** New portal and system now fully provide the functionality of
former legacy systems, which have now been architected as
constructs of extensible and reusable Web Services

May 22-24, 2007 25

Final Considerations
SOA and Web Services – Methodological Considerations for EA Migration:
– Waterfall-based SDLC is ill-suited for object-oriented modeling and UML for J2EE design, iterative
development (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 (local
specificity and brevity) and enterprise-level standards needs (global specificity and verbosity)
– Must balance EA priorities and objectives with system design priorities and objectives by “architecting
globally” 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

May 22-24, 2007 26

References

[1] Many elements of the methodology trace back to principles advocated and suggestions made by a leading SOA
expert, 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 and
selected 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, Stockholm
University/The Royal Institute of Technology, Sweden, petia@dsv.su.se), Wil M.P. van der Aalst (Department of
Technology Management Eindhoven University of Technology, The Netherlands, w.m.p.v.d.aalst@tm.tue.nl), and
Marlon Dumas and Arthur H.M. ter Hofstede (Centre for Information Technology Innovation Queensland University of
Technology (QUT), Australia, m.dumas@qut.edu.aul and a.terhofstede@qut.edu.au), 2003; (B) For a comparison of
process modeling notations with respect to Workflow Patterns, see “Process Modeling Notations and Workflow
Patterns” by Stephen A. White - IBM, February 2005 at
http://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 Cirano
Iochepe (Federal University of Rio Grande do Sul, Brazil) and Vinicius Amaral and Daniel Viero (iProcess, Brazil) in
2006 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 at
http://websphere.sys-con.com/read/48879.htm.

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

May 22-24, 2007 27

Questions and Answers

May 22-24, 2007 28

Thank
You
Lloyd Dugan
Senior Project Director/CTO
Information Engineering Services, Inc. (IES)
Contact Information:
(O) 703-562-0040; (C) 703-864-9646
lloyd.dugan@ie-services.com

May 22-24, 2007 29

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (15)

Destaque

Destaque (8)

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

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

Mais de Nathaniel Palmer

Mais de Nathaniel Palmer (20)

Último

Último (20)

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