business model engineeringwidth depth represent the physical dimensions of the cardboard box used to...

1

1

Application ServersG22.3033-003

Session 7 – Sub-Topic PresentationBusiness Model Engineering

Dr. Jean-Claude Franchitti

New York UniversityComputer Science Department

Courant Institute of Mathematical Sciences

2

Agenda

• Business Process Interoperability• EDOC and ebXML• Component Collaboration Architecture• ECA Entity Profile• ECA Business Events• EDOC Business Processes• Patterns

2

3

Part I

Business Process Interoperability

4

Semantic Web & Ontology

• Semantic Web– Machine-processible semantics of data

• Semantic annotation, XML, RDF– Explicit representation of the semantics of data

accompanied with domain theories (i.e. ontologies)– Lead to a highly knowledgeable world-wide system

• Ontology– “specifications of a shared conceptualization of a

particular domain”– Describe the semantics of information exchange– Ontology description tools : ontolingua, OIL, DAML

3

5

Generic Interoperability Methodology

Framework BFramework A ECIMF Interop. ModelBusiness Context MatchingBusiness Context Model

Semantic Model

Business Process Model

Syntax Model

Semantic Translation

Process Mediation

Syntax Mapping

Business Context Model

Semantic Model


Syntax Model

• Example: ECIMF methodology

6

Generic Interoperability Methodology

• Example: Relationship between the ECIML and other modeling standards.

4

7

Semantic Translation Layer

Box+height+width+depth+weight+stackingLevels+topSide+fragile+productID+shippingNo






Payload

Payloadontology

Hi-Fi equipment

TV-set+color+stereo+height+width+depth+unitPrice+productID+serialNo






Hi-Fiontology

TV-set in a cardboard

box

Properties’ space

Prop

ertie

s’ sp

ace

TV-set in a cardboard

boxTV-set in a cardboard

box

Real-world entities

• Mapping concepts from different ontologies

8

Semantic Translation Layer

• Semantic Translation meta-model

5

9

Business Process Mediation Layer

Enterprise A Process Mediator Enterprise BRequest

ResponseTransaction boundaries (also legal)

Transaction boundaries (also legal)Request

Response

Request

Response

Request

Response

Request

Response

Request

Response

Transaction boundaries (also legal)


• Example scenario that requires Process Mediator.

10

Business Context Matching

«Event» Shipment

«Resource» Car

2 - GIVE

«Agent» ShippingAgent

custody

stock-flow{use}

role

«Agent»Customer

1 - TAKE

«Event»CashRcpt

«Resource» Cash

«Agent» Cashier

collaboration

collaboration

role

«Commitment»Shipment

«Commitment»Payment

«Agreement»ShippingContract

labor cars

used carscash

collaborationexecutes

Uses {when, how long, etc …}Gives {when, where to, etc …}

• Business Context model as seen by the shipping agency

6

11

Business Context Matching

«Event» Shipment

«Resource» Truck

2 - TAKE


custody

stock-flow{use}

role

«Agent»Customer

1 - GIVE

«Event»CashRcpt

«Resource» Cash $1000


collaboration

collaboration

role

Uses {when, how long, etc …}Gives {when, where to, etc …}

«Commitment»Shipment

«Commitment»Payment

«Agreement»ShippingContract

cash

executes

payload

shipped payload

• Business Context model as seen by the customer

12

Process Mediation

7

13

Process Mediation

Customer(RNIF)

Process Mediator ShippingAgency (EDI)

SecureFlowRemAdv

SecureFlowQuoteReqSecureFlow

QuoteConfirm

SecureFlowPOReqSecureFlow

POConfirm

SecureFlowInvoice

REQUOTE

QUOTES

ORDERS

ORDRSP

INVOIC

APERAK

?

Payment







REMADV?

CONTRL

?

14

Semantic Translation• Semantics of the two corresponding concepts

Box → Tv_set: needs to be obtained from a product catalogue (external resource)

N/ATv_set → Box: not neededColor

Box → Tv_set: not needed

FragileMarks the payload as fragile (requiring special care

during transportation)

Tv_set → Box: always set to True.N/A


StackingLevelsRepresents the number of levels the boxes can be

stacked, one on top of the other.

Tv_set → Box: needs to be obtained from a product catalogue (external resource)

N/A


WeightRepresents the weight of the box with the contents.

Tv_set → Box: needs to be obtained from a product catalogue (external resource)

Not available (N/A)

Box → Tv_set: dimension values will always be lower. Need to be obtained from a TV products catalogue (external resource) using productID

HeightWidthDepthRepresent the physical dimensions of the cardboard

box used to ship the electronic equipment of any kind. The values are discrete, because only certain box sizes are available.

Tv_set → Box: dimension values will always be higher, but discrete. Need to be obtained from a cardboard box catalogue (external resource)

HeightWidthDepthRepresent the physical dimensions of the TV set

chassis.

PropertiesMapping RulesProperties

Shipping Agency: BoxSemantic TranslationCustomer: TV-set

8

15

Semantic Translation• Analyze the message delivery control mechanisms

SecureFlow

Signal

Document

Exception

RcptAckExc. GeneralExc.

RcptAck

APERAK

ORDERS

QUOTESREQUOTE

CONTRL ORDRSP

INVOICREMADV

CONTRLThis message is sent when parsing errors occur. Business data was not considered at all.

The semantics of both messages is identical, which means a 1:1 mapping can be applied, both ways.

ReceiptAckExceptionThis signal means the document was not well-formed (parsing errors). Business data was not considered at all.

EDI → RNIF: needs to be synthesized from the response document. Possible problems with timing constraints… (ack. too late)

N/A – implementation choice (positive acknowledgements are implicit).

RNIF → EDI: not needed – don’t forward.ReceiptAckThis signal means that the document business data has been accepted for further processing (which implies also well-formedness)

In this particular case, the EDI system uses APERAK and CONTRL messages only to signal exceptions. Acknowledgements are implicit, in the form of response business documents.

The RNIF business documents map 1:1 to EDI business messages, e.g.:QuoteRequest ↔ REQUOTEQuoteConfirm ↔ QUOTESPORequest ↔ ORDERSPOConfirm ↔ ORDRSPetc ...However, individual data elements can be missing, and will have to be collected from the previous messages, or supplied explicitly in the rules, or obtained from external resources.

SecureFlow consists of a business document (containing business data), and a responding business signal (acknowledgement).

Shipping Agency (EDI)Semantic TranslationCustomer (RNIF)

16

Syntax mapping

RNIFPurchaseOrderRequest

PurchaseOrder

fromRole (Supplier)

ProductLineItemProductIdentificationOrderQuantity

totalAmount

EDIORDERS

SG 28

NAD (SU)

PIA

NAD (BY)

QTYMEA

MOA

TAX-MOA-LOC

LIN

Item Catalog

Directory Economy data

X

X

fromRole (Buyer)

XrequestedUnitPrice

• Message syntax mapping

9

17

Shared ontology approach to semantic translation

local ontology

Multiple ontologies + labels

local ontology

local ontology

Shared ontology

local ontology

Multiple ontologies + labels

local ontology

local ontology

Shared ontology

18

Part II

EDOC and ebXML

10

19

Vision• EDOC

– Simplify the development of component based EDOC systems by means of a modeling framework, based on UML 1.4 and conforming to the OMG Model Driven Architecture.

– Provide a platform independent, recursive collaboration based modeling approach that can be used at different levels of granularity and different degrees of coupling, for both business and systems modeling.

– Embrace MDA – Provide design and infrastructure models and mapping

• ebXML– Creating a single global electronic market

20

The Internet Computing Model

• Collaboration of independent entities

• Document exchange over internet technologies

– Large grain interactions, not “method calls”

• No required infrastructure *• Long lived business processes• Business transactions

– Not technical transactions

BusinessParty

BusinessParty

Portals

11

21

Requirements for the “ICM”• Contract of Collaboration

– Meta-Model (EDOC-ECA) and representation (I.E. XMI, ebXML-BPSS)

– Shared Repository for Contracts (MOF, UDDI, ebXML)

– Tightly coupled systems may simulate the repository with file exchange (I.E. IDL)

• Connectivity which meets requirements of the contract

• Implementation of each contract role providing connectivity (application server)

BusinessPartner

BusinessPartner

Repository

Contracts(Metadata)

Contract of collaboration can be mapped to the format of various technologies. (ebXML, Soap, .NET)

Instance Data

22

Two levels of interoperability

Instance data and interoperability

Metadata (model) interoperability

BusinessPartner

BusinessPartner Bridge

Each can be transformed

EDOCECA

BiztalkebXML

ebXML Biztalk

Normal Form

Over Soap Over Soap

12

23

Drilling down – inside a role

• Inside one role you frequently find more

• Collaborating “parts”of the enterprise

• Until you get to a role within a domain– These can share resources!– E.G. Common access to a

DBMS or Service– Exist within a managed

domain– Can also be a legacy

application

Inner RoleLegacy

InnerRole

Inner RoleDomain

ebXML does not go here, Only EDOC-ECA

Cust

24

Standards for collaboration

Internet document exchangeInternet document exchange, entities, business processes, objects and events

Computing Models Supported

Yes – As ebXML transport. BPSS includes timing and security parameters.

No – Requires technology mapping

Detail sufficient to drive communications

No – Only “B2B”Yes – Recursive Composition into Enterprise

Recursive Composition

Uses external forms, such as XML Schema

Yes – Document ModelContent Model

Yes – Binary Collaboration with Choreography and Business Transactions

Yes – Protocol with Choreography & Object Interface

Contract of Interaction

Yes – Multi Party CollaborationYes – Community ProcessBusiness Collaborations

ebXML-BPSSEDOC-ECA

13

25

Parts of EDOC• Enterprise Collaboration Architecture (PIM)

– Component Collaboration Architecture– Business Process Specification– Entities– Business Events– Patterns

• Technology Mapping (PSM)– Flow Composition Model (Messaging)– EJB & Corba Components– ebXML (In progress)– Others…

• MAPPING – Models are the standards and are source code

HTTP Web ServerApplications

Enterprise ArchitectureEnterprise Architecture

SQL DBMS,Client/Server

& Legacy Applications

ClientApplications

Business and datarules go here

User interface andapplication logic gohere

The data goes here

EAI Applications &B2B E-Commerce

WebBrowser

Standard Middlewareconnects applications to components & components to components

XMLCorbaEJB

DCOMMQ

Supply Chain

EnterpriseComponents

14

27

Parts of ebXML• Business Process Specification (Like CCA)

– XML Representation of business process

• Core Components – Business Data Types

• Collaboration Protocol Profile– What business partners implement what business processes using

what technologies– One-One agreement for doing business

• Transport Routing & Packaging – Messaging Built on Soap

• Registry & Repository– Finding business partners, document and process specifications

28

ebXML Architecture

BPSpecification

Business Process

Core Data Blocks

Business Messages

CPA

Context For Built With

Implement one Partner Role Implement other

Partner Roles

Register

Designtime Designtime

CPP CPP

Transport

Package

Business Service Interface

Internal Business App

Internal Business App

Business Service Interface

Runtime

15

29

Summary of points thus far

• We must enable the emerging Internet Computing Model– Loosely coupled roles exchanging documents based on a contract

of collaboration

• Web need interoperability at two levels– Messaging for the data– Metadata for the contract of collaboration, stored in repositories

• This model of collaborating roles is recursive, extending into the enterprise, into managed domains and into applications– Inside the enterprise we want to include resources entities, business

events and business processes

• Between EDOC & ebXML we are covering B2B and intra enterprise

30

Part III

Component Collaboration Architecture(the model of doing)

16

31

The Marketplace Example

Mechanics Are UsBuyer

Acme IndustriesSeller

GetItThere FreightShipper

Order

Conformation

Ship Req

Shipped

Shipped

PhysicalDelivery

Delivered

Status

ProcessComplete

32

The Seller’s Detail

Order

Conformation

Shipped

Ship Req

Shipped

Delivered

Order Processing

Shipping

Receivables

Event

17

33

Parts of a CCA Specification• Structure of process components and protocols

– Process components, ports, protocols and documents

• Class Diagram or CCA Notation

• Composition of process components– How components are used to specify

components• Collaboration diagram or CCA Notation

• Choreography – Ordering of flows and protocols in and between

process components• Activity Diagram

34

The Community Process

• Identify a “community process”, the roles and interactions

• Using CCA Notation

Buyer Seller

BuySell CommunityProcess

Buy Sell

Shipper

ShipDelivery

ShipDelivery

18

35

Seller

Sell

Buyer

Buy

Component structure

Buys(from Buyer)

<<ProtocolPort>>

Buyer<<ProcessComponent>> <<initiates>> Sells

(from Seller)

<<ProtocolPort>>

Seller<<ProcessComponent>><<responds>>

BuySellProtocol<<Protocol>>

Component structure Defines the “outside”Contract of a component

36

OrderData<<CompositeData>>

OrderConfirmationData<<CompositeData>>

Order(from OrderBT)

<<FlowPort>>OrderConfi rmat ion

(from OrderBT)

<<FlowPort>>

OrderBT<<Protocol>><<responds>>

<<initiates>>

OrderDeniedData<<CompositeData>>OrderDenied

(from OrderBT)

<<FlowPort>>

<<initiates>>

Protocol Example

• Specification of a protocol

Protocol OrderBT

OrderDenied

OrderConfirmationOrder

responderRoleSeller

initiatorRoleBuyer

19

37

Protocol OrderBT

OrderDenied

OrderConfirmationOrder

responderRoleSeller

initiatorRoleBuyer

Choreography of Protocol

<<initiates>> Order

<<responds>> OrderDenied <<responds>> OrderConfirmation

Failure Success

38

Object Interfaces

• Use standard interface notation

• Are a subtype of “Protocol” in the MetaModel

• Allow modeling of and integration with classical and/or existing objects

CustS ervic e

+ checkCustomer()+ checkCredit()

<<Interface>>

EnqStatus(from CustomerComponent)

<<ProtocolPort>>

CustomerComponent<<Entity>>

<<responds>>Interface

Protocol

20

39

Composition

Seller : Sells

Validate : OrderValidation

: checkOrder

: reject

: acceptOrder

: CheckCustomer

Process : OrderProcessing

: doOrder

: ProcessedOrder

CustB ean : CustomerComponent

: SendOrder

: GetDenied

: GetConfirmation

: EnqStatus

Seller Composit ion

1: checkCustomer(order : Order)

Use of an interface

Composition definesthe “inside” of a component

40

Part IV

ECA Entity Profile(the model of things)

21

41

Sample Information Model

+Street : String+City : String+State : String+Zip : String

«EntityData»Addtress

+Cust

1

+Adr

1..*

+Name : String+Balance : Decimal = 0+AccountNo : long

«EntityData»Account

+InvNum : Integer+Total : Decimal

«EntityData»Invoice

-Act1-Invoices*

+Quantity : float-Price : Currency

«EntityData»LineItem +PartId : String

+Description : String+QtyInStock : float(idl)

«EntityData»Part

-Env

1

-Items

*

-Items

*

-Part

1+InvNum : Integer

«Key»InvoiceKey

-.

1

-.

1

+PartId : String

«Key»PartKey

-. 1

-. *

+AccountNo : String

«Key»AccountKey

-.

1

-.

1

+Name : String-CompanyId : String

«EntityData»Company

+CompanyId : String

«Key»CompanyKey

-.

1

-.

1

42

Adding Entities

• Entities are added to manage entity data

• Entity Roles are managers that provides a view of the same identity in another context

• The Entities have ports for managing and accessing the entities

• Non-entities which are owned by (aggregate into) an entity are managed by the entity

+Street : String+City : String+State : String+Zip : String

«EntityData»Addtress

+Cust

1

+Adr

1..*

+Name : String+Balance : Decimal = 0+AccountNo : long

«EntityData»Account

+AccountNo : String

«Key»AccountKey

-.

1

-.

1

+Name : String-CompanyId : String

«EntityData»Company

+CompanyId : String

«Key»CompanyKey

-.

1

-.

1

.Manages

<<Entity>>CompanyManager

Manage

<<EntityRole>>AccountManager

Manage

-Manages1-.1

22

43

Part V

ECA Business Events(the model of when …)

44

Business Process

Business Entity

BusinessRules

Business Events

Business Actions

Business Process

Business Entity

BusinessRules

Business Events

Business Actions

Event Based Business Processes

Event Notification

23

45

App

Business Process

Business Entity

BusinessRules

Business Events

Business Actions

App

Business Process

Business Entity

BusinessRules

Business Events

Business Actions

App

Business Process

Business Entity

BusinessRules

Business Events

Business Actions

App

Business Process

Business Entity

BusinessRules

Business Events

Business Actions

Point to point Event Notification

Event Notifications

46

App

Business Process

Business Entity

BusinessRules

Business Events

Business Actions

App

Business Process

Business Entity

BusinessRules

Business Events

Business Actions

App

Business Process

Business Entity

BusinessRules

Business Events

Business Actions

App

Business Process

Business Entity

BusinessRules

Business Events

Business Actions

Pub/Sub

Pub/Sub Event Notification

24

47

Event Example

48

Part VI

EDOC Business Processes(the model of how …)

25

49


• Specializes CCA• Activity-centric view of a Process• Expresses

– Complex temporal and data dependencies between business activities

– Iteration of activities– Alternative required Inputs and Outputs of activities– Roles related to performers, artifacts and responsible

parties for activities

50

Data Flows

• DataFlows are special CCA Connections– Uni-directional between ProcessFlowPorts– DataFlows indicate

• data dependency & transmit values at run-time, or• temporal dependency (aka control flow)

26

51

Part VII

Patterns

52

Patterns: Buyer/Seller

Inheritance

Composition

business model engineeringwidth depth represent the physical dimensions of the cardboard box used to...

Documents