![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Imagine you're the lead developer on a project to automate your bank's mortgage application procedures. Your team has interviewed the business users, you've identified the requirements and you've even determined which enterprise services you'll need when you build this new system. You've correctly realized that you need a business-process engine to manage the process from start to finish and, as the good service-oriented designer that you are, you will reuse as much functionality as possible from across the company and beyond.
You're good to go. The chief architect just wants a quick chat before he signs off the design. No problem!
Chief Architect: "What approach have you taken to automate the business process?"
You: "We'll model the process in a business modeling tool, export it as BPEL, and deploy to a BPEL-compliant runtime with human extensions."
Chief Architect: "Good. Standards-based where it makes sense... Extensions where necessary -- and well encapsulated in any case. And what about reuse? We can’t afford to reinvent the wheel on this project."
You: "Indeed! We've identified several services offered by other systems in the bank -- CRM, Product Information… And we will also capitalize on the bank's relationship with our third-party credit scoring provider."
Chief Architect: "Excellent. This all looks good. Of course, the rumor is that the financial services regulator will soon add some extra compliance requirements to mortgage application processing. When this is finalized, how easy will it be to modify the solution?"
You: "Hmmmm. Errrr... We chose to invest our limited resources on meeting the current, stated requirements."
Chief Architect: "Oh really? What about that third-party provider? What’s your contingency plan if our competitor buys them or if they go out of business? Their results were pretty poor last quarter..."
You: "Can we reconvene next week? I need to consider a few more things..."
Of course, the questions in the abstract above should be asked as part of any well-run project -- and developers have had to solve these problems for years. In many of these cases, the approach was simple: make the appropriate changes and deploy the new release at some convenient time. However, there are new classes of applications being built where the old approaches break down.
This article explores some simple scenarios that illustrate these issues and then shows how IBM® WebSphere® Process Server can be used to solve them. We will do this by introducing some of the key service-oriented concepts in the product and explain their purpose. This is an introductory article that assumes no knowledge about specific IBM products. However, some experience with application development projects or enterprise integration projects can be useful. It should be noted that this document does not attempt to provide a step-by-step guide to developing artifacts in WebSphere Process Server. Rather, it is intended to explain concepts and suggest areas for further study.
| Description | Name | Size | Download method |
|---|---|---|---|
| Article in PDF format | 0602_brown-wps_versioning_dynamicity.pdf | 676 KB | FTP |HTTP |
Information about download methods Get Adobe® Reader®
Learn
-
SCA programming model
-
WebSphere Business Integration zone.
-
WebSphere Process Server and WebSphere Integration Developer resources.
-
WebSphere Process Server Information Center
Get products and technologies
Discuss
Richard G Brown is a Senior IT Specialist in IBM’s Software Services for WebSphere organization. He is based in IBM’s Hursley development laboratory in the United Kingdom and helps clients across Europe with their integration and business process management problems. You can reach Richard at: brownr1@uk.ibm.com or by commenting on his blog at: Gendal World.
