Upload
nathaniel-palmer
View
5.225
Download
0
Embed Size (px)
DESCRIPTION
SOA and Web Services technologies can provide powerful tools and capabilities to effect migration towards an Enterprise Architecture (EA), but what are the challenges to such an exercise, and how can they be overcome? Based on a case study at the Department of Housing and Urban Development (HUD), the first effort in HUD to analyze and design the replacement of several legacy systems with an integrated and services-based system, this presentation will provide a technical overview of SOA and Web Services, and lessons learned from the project. These lessons will cover methodologies and modeling artifacts that were developed for the effort, the use of BPM based on the Business Process Execution Language (BPEL) and system adapters to provide an abstraction layer for system integration, an example of how Web Services can directly support EA migration, and final considerations to pass onto similar projects.
Citation preview
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
<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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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>john</firstName>Or
<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>
<firstName>john</firstName>Or
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=“false" minOccurs=“0“ maxOccurs=“1"/>
<xsd:element name=“firstName" type="xsd:string" nillable=“false" minOccurs=“1“ maxOccurs=“2"/>
<xsd:element name=“firstName" type="xsd:string" nillable=“true" minOccurs=“1“ maxOccurs=“1"/>
22May 22-24, 2007
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
= 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:
**
24May 22-24, 2007
Washington Dulles HiltonThe Business Transformation Conference
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
= 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:
***
*** 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
Washington Dulles HiltonThe Business Transformation Conference
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
= 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:
****
**** 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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
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
Washington Dulles HiltonThe Business Transformation Conference
Questions and Answers
29May 22-24, 2007
Washington Dulles HiltonThe Business Transformation Conference
ThankYouLloyd DuganSenior Project Director/CTOInformation Engineering Services, Inc. (IES)
Contact Information:
(O) 703-562-0040; (C) [email protected]