© Copyright 2006

MDA for Business Processes with SOA A Tool Vendor’s Perspective

Karl Frank, Principal ArchitectBorland Software Corporation

Overview

PerspectivesTool Chains

Tool Vendor’s view of MDA?Interests of Tool Vendor’s primary customers

Challenge to successful MDA/SOASOA: 16 years of SOA experienceSemantic Gap: an issue in SOA

Analysis of the GapTools to bridge it

BusinessProcess

Runtime

Viewpoint is in evidence here: All diagrams in this presentation are donein a modeling tool, no Powerpoint™ or Visio™ pictures !

Perspectives*

What perspectives are there? Platform VendorMethodologistConsultantIndustry Standards and Interoperability OrganizationsSoftware Delivery Perspective

Management’s ViewImplementation Technologist’s View

Tool Vendors have their own different perspective

* We were invited to provide a tool-vendor’s perspective

Platform VendorMay give away tools to support platform: tool provider, not tool vendorBusiness model in conflict with PIM concept, MDA objectives

Standards/Interoperability Specification OrganizationMust achieve consensus among all viewpoints.Business model requires schedule flexibility to suit supporters

MethodologistAims at technology neutralityBusiness model requires changing how people work

Software Delivery Perspective:Consultant

Service Industry: may want 3rd party tools to increase productivityBusiness model requires platform-expert hours paid for by IT Mgt.

Software Development ManagerResponsible for projects meeting enterprise needs on budget

Development team memberResponsible for accomplishing hands-on work in development projects

Tool Vendor’s Perspective on Others

A Tool Vendor’s Take on Toolchains

SOA requires discovery of consistent collaborations among available services.Give Development Projects ability to search past and current projects for resources

Need to fit those collaborations into some hard-to-change business processesModel the critical semantic contracts that characterize services.Directory and location services at the technology level are no help if you don’t know how to harness consistent services to the real needs of the business.

Where there is a gap in the inventory of available services, making SOA successful requires the ability to specify new services that are guaranteed to work in contextIn the MDA approach to making SOA work, business process modeling defines the platform independent requirements for consistent services. Most of the modeling we have seen recommended as best practices are inadequate. They only work with huge investment in consulting manpower.QVT - Model-to-text transformation tools needed to connect service-oriented models with platform specific SOA implementations with consistent semantics.

Our responsibility: programmable time-saving tooling for successful MDA + SOA Development

Requires support for sufficient precision in models

What is MDA? (Our View, based on ORMSC)

Motivating Industry Problem for MDA is:Platform changes force re-implementing on new platformsHuge expenses in time, money, lost opportunity, retraining

Essential Goals of MDA are to solve the above by:High-level Problem-oriented Graphic LanguagesPlatform Independence for Software SpecificationGenerating more of the Platform Specific Implementation

Defining techniques of MDA are:Graphic, non-proprietary, modeling languages

These must be platform independent to meet essential goalsModel-to-Model and Model-to-Text (code) Transformation

MDA demands:Scarce expertise in Modeling and Tools

Tool Chain for MDA Lifecycle

Project Management ToolsProcess Definition ToolsRequirements Elicitation ToolsRequirements Management ToolsModeling Tools for Various Domains with Teamwork SupportModel Audit ToolsModel Transformation ToolsConfiguration Management ToolsCode Development ToolsContent Management ToolsTest Authorship ToolsTest ManagementDeployment Management

MDA involve all parts of the softwarelife-cycle, plus more because of addedfocus on modeling.

New element is need for tool support precise modeling and transformationof models and the generation of code!

What is SOA?

“A Service-Oriented Architecture (SOA) is a software architecture that is based on the key concepts of an application frontend, service, service repository, and service bus. A service consists of a contract, one or more interfaces, and an implementation.”

from Enterprise SOA [1]

SOA Lessons learned before there was SOA

Remote Procedure Calls(RPC) on DECnet languagesDistributed Investment Management, price event to phone callAutomate a business process, then done manuallyContext: advisor on NON DISCRETIONARY account

newspaper delivered !

read earnings reports

earnings surprise !

good or bad?

approval to trade!

call Investor

should Buy

should Sell

Must get customerapproval to tradenon-discretionary

Industry earns on trades

parse for public companyearnings report

extract company ID andearnings A M O U N T

get new s item

Earnings A nnounced

compute new stock rating

compare A nnounced w ithExpected Earnings

Earnings Surprise

XO R

XO R

search accounts for longpositions in that stock

search for customercontact info for the

account

send trade order

A uto-dial inv estor'sphone number

pass call to nextav ailable call center

staff

ask for authorizationto trade

call answ ered XO R

else

rating = buy A nnounced > E xpected

else

SOA Evolved at Technology Level

Too hard with RPCs, so CORBA nextC++ technology, object encapsulation was better medicine

CORBA technology reserved for gurus, lead to next step:Proprietary Workflow Solutions and EAI SolutionsThese added a model-driven graphic front end dashboard

Web Services: finding and using a single service is easySOA momentum builds, suggested to be as easy as pieReal business process apps (competitive with EAI) a challenge

Same basic principles apply: find or build mutually composable services, control by orchestrating processNow we have modeling tools that generate WSDL for services and runtime control through BPEL4WS

Lessons learned in early SOA experiences

Web services tamed the difficulty of the technology, butWe solved all the technical difficulties in 1990 just fine

Want high-level model, accurate semantic information on “services”DEC’s technology converted data types just fine between languagesTouted as solving semantic issues between independently developed applications in different DEC languages, but not business semanticsWe needed (and got) access to the source of each program to get them alligned semantically:

Preconditions and Postconditions of the called functionsSupposedly standard identification schemes such as CUSIP and STOCK TICKER and Phone Number values were not standardArchitecturally well-designed service functionality may still be incompatible because of process inconsistency at a higher level

Exposing functionality like “get accounts that own IBM” and making it work with other apps that need account ID’s can expose problems.

Today’s SOA Architecture Elements

SOA

Middleware[*]

Wrapped Runtime[*]

ServiceFacade[*]

Service[*]

AutomatedBusinessProcess[*]

FrontingApplication[1]

As UML Collaborationinvolving 5 direct andone referenced part.

Today’s SOA Technologies

SOA

Middleware[*]

Wrapped Runtime[*]

ServiceFacade[*]

Service[*]

AutomatedBusinessProcess[*]

FrontingApplication[1] java or .net rich client

BPEL (but could be EAI or Workflow)

Web Services (could be CORBA or EJB)

Web Service (could expose most anything)

network protocol stack

Reused or purpose-built functionality

A Perfect Opportunity for MDA

Modeling Tools

For true MDA, i.e. achieving platform independence thru models, non-proprietary and interoperablility is required in modeling languages. This means the tools themselves should be available on multiple platforms and interoperable.Most modeling now is static structure modeling of the OO software.SOA needs appropriate dynamic process and information models

These are not Object OrientedAre BPMN, Statemachines, Activity Diagrams, adequate?

Need to manage and specify services and control their qualityNeed precise contractual specification of servicesNeed testing of services against documented contracts

Transformation Tools

Enable turn PIM models to PSMs, PSMs to text.transformation Uml_Class_To_Wsdl;

import library Strings;import library emf.tools;import library together.uml;

metamodel 'http://schemas.xmlsoap.org/wsdl/';metamodel 'http://www.eclipse.org/xsd/2002/XSD';metamodel 'http://www.borland.com/together/uml';metamodel 'http://www.borland.com/together/uml20';metamodel 'http://www.eclipse.org/emf/2002/Ecore';

mapping main(in service: uml20::components::Interface): wsdl::DocumentRoot {init {

var allClassesUsedByService : Set(uml20::classes::Class) := service.ownedOperations->collect(op | allClassesUsedInOperation(op))->asSet();

var allPackagesUsedByService : Set(uml::kernel::packages::Package) := allClassesUsedByService->collect(c | c.owner.oclAsType(uml::kernel::packages::Package))->asS

}object {

definitions := object wsdl::TDefinitions {targetNamespace := service.nameAsNamespace();portType += object wsdl::TPortType {

name := service.name;operation += service.ownedOperations->collect(p | operation2PortType(p));

}}

}}

Easy MDA to SOA Part

Program to Orchestrate Services

QVT BPMN to BPEL

Business Process Model

AutomatedBusinessProcess

Same issue first encountered in the DecWorld RPC demo!Not a show-stopper, but to solve it now takes lots of effort.

Challenging MDA to SOA Aspects

Runtime Contol

Independently implemented units of service

Composable Functionality

AutomatedBusinessProcess

Wrapped Runtime

Same issues first encountered in the DecWorld RPC demo!To succeed it still takes effort and info on details of the runtime.

Business Process Model Valid Model with Adequate Detail

Work to a solution using tool-based example

Business Process Model

Independently implemented units

Semantic Gap

AutomatedBusinessProcess

Wrapped Runtime

Analysis of the Gap, Tools to Bridge It

Business Process is not a single conceptual domainDifference between communication based and control flowIt matters for MDA – SOA

Question claim that “BPMN Diagrams”, per se, can drive SOATools transform BPMN to BPEL, but special constraints apply.Alternative: throw consulting expertise at it to apply secret sauce

Models of wrapped functionality are neededAdequate for specifying their semanticsEnabling determination of consistent fit with one another in processNo one standard modeling language is adequate

Tools combine and extend languages to provide automation support

A portion of the Financial Industry

Investor

Investment Firm

Pricing Data Vendor

What are their business processes?Could these be automated on an SOA, MDA style?

Pricing Service Provider

Update Latest Price

SecuritiesTradeOccurs

SendPrice

Create Price Info per Customer Service Agreement

Provides real-time and batched trade, corporate action, and analytic data to customers

Investor Services Firm

Apply New Price to Security Position

Apply New Trade to Security Position

ReceivePrice

sendStatement

Compute Buy/Sell/Hold Rating

sendRatingReceivePrice

Execute Trade

sendConfirm

ReceiveOrder

order type

get bids in derivatives mkt

choose best bid or offer

compare with last trade

ReceivePrice

not in-the-money

type = put or call

type = limit

type = at market

Beginning Production SOA

1994 working for “very large” money-center bankFound common need in many diverse applications for price info on securities. A no-brainer.Each of 947 apps maintained with their own price feed, and with separate apparently redundant contracts with Pricing Vendors. Reveals huge unnecessary expenses

Pricing Server.Still “pre-SOA” because CORBA was the enabling technologySame discovery made: semantic differences discovered late in the project made the problem very difficult. Effort was unanticipated. These differences were of two kinds:

Architectural and Business Level

Investor—Retail Customer

XOR

sendOrder

Hold All

NewInfo

Create Trade Order

Create Cash Funding orLiquidation Order

Investor Creates Trade Order

Set Investment Objectives

Set Asset Allocation

Set Risk Tolerance

And

periodic

newInfo

XOR

Determine Target Position

Compare Actual toTarget Position

Determine Actual Position

Compute Buy

Hold

Compute Sell

XOR

send Trade Order

Else

Target > Actual

Actual > Target

BPMN Views (Investment Industry Example)

Update Latest Price

SecuritiesTradeOccurs

SendPrice

Create Price Info per Customer Service Agreement

XOR

Join

Create Trade Order

Do Nothing

sendOrder

NewCommunication

ReceivePrice sendRating

Compute Buy/Sell/Hold Rating

ReceivePrice sendStatement

Apply New Price to Security Position

Apply New Trade to Security Position

ReceiveOrder

Execute Trade

sendConfirm

SecurityPriceReport

AccountStatement TradeOrderTradeRecommendation Investor

Investment Firm

Pricing Data Vendor

CheckAssessment FinishStart

ReplyassignYesReceive

invokeApprover

invokeAssessor

CheckAmount

bpws:getVariableData('request', 'amount')>=10000

bpws:getVariableData('riskAssessmentMessage', 'risk')!='low'bpws:getVariableData('request', 'amount')<10000

bpws:getVariableData('riskAssessmentMessage', 'risk')='high'

BPMN

Differentiates between Orchestration/ChoreographyYet mixes them in one diagram

Results in hard lines between independent firmsInternal “ProcessPool” has an orchestrated processNo messages allowed within one logical OrganizationNo control or data flows allowed between Organizations

SOA includes the realm of ChoreographyService: implements interface to encapsulated runtimeNo representation of how.Little representation of what

Semantic protocols and contract specifications wanted.

References

[1] Wiederhold, Wegner, and Ceri Toward Megaprogramming. Communications of the ACM, Vol. 35, November 1992.

[2] Krafzig, D., Banke, K., and Slama, D. Enterprise SOA: Service-Oriented Architecture Best Practices. Prentice Hall PTR, 2004, 57, 70-72.

[3] Stephen White, editor, for BPMI.org Business Process Modelling Notation, Version 1.0 – May 3, 2004. See http://www.omg.org where a revision of the BPMN specification is now underway

[4] Object Management Group Unified Modeling Language: Superstructure. formal/05-07-04. http://www.omg.org

[5] http://schemas.xmlsoap.org/ws/2003/03/business-process/[6] Loan Approval Example BPEL4WS 1.1 specification

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbizspec/html/bpel1-1.asp