MDA for Business Processes with SOA · “A Service-Oriented Architecture (SOA) is a software...
Transcript of MDA for Business Processes with SOA · “A Service-Oriented Architecture (SOA) is a software...
© 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