1 maerz practical applications of micro services in mitk...

5/30/2016

Practical Applications of

Micro Services in MITK

Keno März

5/30/2016 |

Why do we need classes?

5/30/2016 |

Rene Aigner - Monolith

A

B

C

D

E

F

G

Core

1) No separation of concerns

2) Seperation into modules

3) Seperation into micro services

5/30/2016 | Author

The ideal Micro Service

• One process

• One concern

• One interface

• „Shared Nothing“

5/30/2016 |

Monolithic Software

A

B

C

D

E

F

G

Core

A

B

C

D 2.0

E

F

G

Core

A

B

C

D 2.0

E

F

G

Core

A

B

C

D 2.0

E

F

G

Core

A

B

C

D 2.0

E

F

G

Core

5/30/2016 |

Maintenance

A

BC

D

D 2.0

Registry

Core

5/30/2016 |

Scalability

A

BC

D 2.0

Registry

Core

D 2.0

5/30/2016 |

Flexibility

A

BC

D 2.0

Registry

Core

D 2.0

More on on

that later!

5/30/2016 |

Not a silver bullet

http://www.kassenzone.de/2016/04/21/microservices-einradfahren/

5/30/2016 |

Topics

1. Intro

2. Implementation in MITK

3. Use-Case 1: Reader and Writer

4. Use-Case 2: IGT Devices

5. Conclusion

5/30/2016 |

C++ Micro Services

• http://cppmicroservices.org/

• Coder: Sascha Zelzer*

• Pure C++ implementation

* Google this name for more info

5/30/2016 |

Three steps to your Micro Service

1. Implement it

2. Register it

3. Discover it

5/30/2016 |

Create a Microservice: Implement it

5/30/2016 |

Create a Microservice: Register it

• Example Implementation: mitk::USDevice

5/30/2016 |

Service properties

• Map<string, us::Any>

• Can be used for filtering! (LDAP-Format)

5/30/2016 |

Create a Microservice: Discover it

Two options available:

a) Search via ModuleContext

• Example: mitk::FileWriterRegistry

5/30/2016 |

Create a Microservice: Discover it

Two options available:

a) Listen via EventListeners

• Example: QmitkServiceListWidget

5/30/2016 |

Listening to changes

5/30/2016 |

Topics

1. Intro

2. Implementation in MITK

3. Use-Case 1: Reader and Writer

4. Use-Case 2: IGT Devices

5. Conclusion

5/30/2016 |

The Situation

• I/O managed centrally from core

• I/O Implemented in modules

• Painful for 3rd-party devs

5/30/2016 |

Design idea

• Microservice with properties:

• Supported MimeType

• Priority value (int)

• Additional registry classes for easy access

5/30/2016 |

The new IO Architecture

5/30/2016 |

3rd party creates reader

mitk::MyFileReader mitk::MyFileWriter

mitk::MyFileReaderAndWriter

5/30/2016 |

Mime Types

5/30/2016 |

Core

Implement new Reader

Registry

IOUtil

My Module

ASD Reader

ASD Mime

TypeFileReader

ServiceRegistry

5/30/2016 |

Core

Supercede a Reader

Registry

IOUtil PicReader

Priority:100

FileReader

ServiceRegistry

My Module

BetterPicReader

Priority:101

5/30/2016 |

Summary

• Micro ServicesG

• G give more control to 3rd party devs

• G make I/O process more dynamic

• G decouple decouple core I/O from modules

5/30/2016 |

Topics

1. Intro

2. Implementation in MITK

3. Use-Case 1: Reader and Writer

4. Use-Case 2: IGT Devices

5. Conclusion

5/30/2016 |

Situation

• IGT Tracking Toolbox:

• Great for tracking!

• Ultrasound Support:

• Great for ultrasound imaging!

• My Ultrasound Navigation Plugin

• I have to replicate it all again!

5/30/2016 |

MyDeviceConfigurator

Device design

1. Can be activated/deactivated

2. Has configuration plugin

3. Publishes pipeline endpoint

4. Registered as Micro Service

Device

5/30/2016 |

Combining Devices

IGT Tracking Toolbox

Tracking

Device

Ultrasound Support

Ultrasound

Device

Ultrasound NavigationOpen IGT Link

Tracking

Device

Ultrasound

Device

Tracking Device

US Device

5/30/2016 |

Summary

• MicroservicesG

• G facilitate reuse of workflows

• G enable sharing of instances across plugins

5/30/2016 |

Topics

1. Intro

2. Implementation in MITK

3. Use-Case 1: Reader and Writer

4. Use-Case 2: IGT Devices

5. Conclusion

5/30/2016 |

Where to start

• mitk::USDevice

• Basic Implementation

• Properties

• QmitkServiceListWidget

• Event Listening

• Filtering Micro Services

• mitk::FileReaderRegistry

• Active Micro Service search

5/30/2016 |

Conclusion

Micro ServicesG

• G help achieve decoupling

• G promote reusability

• G require careful interface design

• G should be used with common sense

5/30/2016 |

Future work

• Mappers as Micro Services:

• Smiliar to I/O scenario

• Micro Services for properties

• Distribute property resolution

5/30/2016 |

Next up 3.

Thank you for

your attention!

Further

information

on www.dkfz.de