a common basis for modelling service-oriented and event-driven architecture

Problem and HypothesisModelling: A Language Driven Approach

Case StudySimulationConclusion

A Common Basis for Modelling Service-Orientedand Event-Driven Architecture

Tony Clark and Balbir S. Barn

School of Engineering and Information Sciences, Middlesex University, London,UK

February 23, 2012

Tony Clark and Balbir S. Barn A Common Basis for Modelling Service-Oriented and Event-Driven Architecture



Contents

1 Problem and Hypothesis

2 Modelling: A Language Driven ApproachServicesEventsTooling

3 Case Study

4 Simulation

5 Conclusion




Enterprise Architecture

What does a business do?

Why does the business do it?

How does the business operate?

Use Cases: as-is and to-be; IT alignment; governance;resource planning; compliance; IT management; etc.




It’s a Puzzlement [King of Siam]




Architectural Styles: Inversion of Control

Service OrientedArchitecture

Messages drivecomputation.

Interfaces of operations.

Synchronous,Asynchronous,Broadcast, etc.

Business processesattached to services

Event DrivenArchitecture

Events drivecomputation.

Interfaces of events.

Always asynchronous.

Business processesattached to complexevents.




Architectural Styles: Architectural Styles




Architectural Styles: Messages




Architectural Styles: Inversion of Control




Architectural Styles: Events




Technologies for EA

ArchiMate

MODAF

TOGAF

UML and SysML

All fairly complex, imprecise, not domain specific, do not supportreasoning, no simulation.




A Language Driven Approach to EA

A Domain Specific Language for Modelling EA:

Component architecture.Information models.Invariants.Pre and post specification of Business Processes.Events.

A Domain Specific Language for EA Simulation:

As above...Commands for business process implementation.Message passing.Rules for complex event processing.




ServicesEventsTooling

Contents



3 Case Study

4 Simulation

5 Conclusion





EA Modelling Language





EA Simulation Language

component d {

port p[out]:interface {

v():void}

port q[out]:interface {

z():void}

operations {

y() {

p <- v();

q <- z()

}

}

}






component d {


v():void}


z():void}

operations {

y() {

p <- v();

q <- z()

}

}

}

component b {

port q[in]: interface {

z():void}

operations {

z() {

print(’called z()’)

}

}

}






component d {


v():void}


z():void}

operations {

y() {

p <- v();

q <- z()

}

}

}

component b {

port q[in]: interface {

z():void}

operations {

z() {

print(’called z()’)

}

}

}

component a {

port p[in]: interface {

v():void;}

operations {

v() { print(’called v()’) }

}

}






component c {

c = 10

port events[out]: interface {

x(data:int):void}

operations {

x() {

events <- x(c)

}

}

}

component d {

d = 10


y(data:int):void}

operations {

y() {

events <- y(d)

}

}

}

component a {

port p[in]: interface {

x(data:int):void;y(data:int):void

}

model {

class X { x:int }

class Y { y:int }

class Data { d:int }

}

rules {

x_and_y: X(x) Y(y) ?(p(x,y)) {

v(x,y)

}

}

operations {

x(data) { new X(data) }

y(data) { new Y(data) }

v(x,y) { new Data(x+y) }

}

}





Component Connections





Calling Sequence




Contents



3 Case Study

4 Simulation

5 Conclusion




UK Borders Agency




Component Dependencies




Registry




Student Office




Monitor




Contents



3 Case Study

4 Simulation

5 Conclusion




Case Study: Example Component

component registry {

port in[in]: interface {

register(name:str,course:str):void}


register(name:str,course:str):void}

model {

class Student {

name:str;course:str

}

}

operations {

register(name,course) {

new Student(name,course);

events <- register(name,course)

}

}

}




Dynamic, Parametric Componentsoperations {

make_department(name,courses,academic_names) {

component {

...

school_office = make_student_office(courses)

academics = [ make_academic(name) | name <- academic_names ]

}

}

make_academic(name) {

component { ... }

}

make_student_office(courses) {

component { ... }

}

}

computer_science = make_department(’Business’,[

Course(’Business and IT’,[

Module(’Marketing’,[CW(’BIT_MCW1’,4),CW(’BIT_MCW2’,6)])]),

Course(’Business Informatics’,[

Module(’Finance’,[CW(’BI_MCW1’,4),CW(’BI_MCW2’,6)])]),

],[’Dr Piercemuller’,’Prof. Plumb’])




Simulation Architecture




Screen Model




Simulation: GUI

component gui {

display = jcomponent(’frames.GUI’)

operations {

show() {

let time = find Time(t) in state { t } else 0

in display.in <- display(Table([

[Text(’contacts:’)],

[Table([[Text(r.name),Text(r.contacts)] | r <- monitor.in.contacts()])],[Text(’ ’)],

[Button(’Tick’+time,fun(e) clock_port <- tick())]

]))

}

tick(time) { delete Time(time-1); new Time(time); show() }

}

port in[in]: interface { show():void; tick(time:int):void }

port clock_port[out]:interface { tick():void }

}




Borders Agency Simulation




Other Examples

EA Alignment in order to comply with new UK HEregulation for Key Information Sets.

Architecture for Sense Making using data from socialnetwork sites.




Contents



3 Case Study

4 Simulation

5 Conclusion




Conclusion

EA use-cases require precision to analyse designs.Domain analysis leads to: components; information models;messages; events.Current technologies are very large, complex and imprecise.A Language Driven Approach leads to a design and simulationlanguages.Design language as UML profile.Simulation language implemented in Java.Tested on several case studies.Future Steps:

Support for Business Goals.Methods to support approach and integration with existing EAtechnologies.Develop techniques for various EA analysis use-cases.Integrate simulation language with real architectures.


a common basis for modelling service-oriented and event-driven architecture

Technology