15
SERVICE DISCOVERY AND CONTROL DICOM SUPPLEMENT PROPOSAL FROM WORKING GROUP 23

Service Discovery and Control

  • Upload
    others

  • View
    5

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Service Discovery and Control

SERVICE DISCOVERY AND CONTROL

DICOM SUPPLEMENT PROPOSAL FROM WORKING GROUP 23

Page 2: Service Discovery and Control

USE CASE

• Provide a mechanism for discovering and managing processing services

• Introduce the capabilities of launch and control for:

• Containerized processing

• Service-Oriented Architectures

• Microservices

• Generalize describing an application by:

• Purpose (Scope)

• Runtime Mechanism (Component Workload)

• Data Ingest and Egress (Entrypoint Traits)

Page 3: Service Discovery and Control

IN RELATION TO PART 19

• Part 19 becomes more generalized to be a collection of services and

interfaces

• The proposed content is additive, the current API described is one ‘Entrypoint

Trait’ that can be described

• Current API becomes Section 9 and sections 6-10 would be nested there.

• Add Section 6 Conformance

• Add Section 7 Overview of Application APIs and Mechanisms

• Add Section 8 Common Aspects of Application APIs

Page 4: Service Discovery and Control

PRINCIPLE

APPLICATION

“I do this

type of

work!”

Data to

work onRequestor

P

l

a

t

f

o

r

mJob

request

Supplement Space

Output

Page 5: Service Discovery and Control

OAM ROOTED

• OAM (Open Application Model) https://oam.dev

• The goal of Open Application Model is to define a standard, runtime-agnostic

way to describe application deployment across hybrid environments, clouds or

even edge devices

• Focused on application rather than container or orchestrator brings modular,

extensible, and portable design for modeling application deployment with

higher level yet consistent API

• Enables simple yet robust application delivery across hybrid environments

including Kubernetes, cloud, or even IoT devices

Page 6: Service Discovery and Control

OAM OVERVIEWGovernance: (see also next slide)

https://github.com/oam-

dev/spec/blob/master/CONTRIBUTING.md

Open Web Foundation License Agreement:

http://www.openwebfoundation.org/legal/

the-owf-1-0-agreements/owfa-1-0

Published on GitHub:

GitHub - oam-dev/spec: The Open

Application Model (OAM) Specification

Non-goals include:• Defining or prescribing specific orchestrating

workflow.

• Defining the schemas of operational

resources, for example (but not limited to):• Secrets (secure, encrypted values)

• Networks

• Volumes

• Describing or defining the runtimes themselves.

Page 7: Service Discovery and Control

OAM COMMUNITY

• Currently in Beta release – Collaboration efforts began in 2019

• Open to community involvement and modifications

• Change request submitted via GitHub Issues

• Bi-weekly community meetings

• Active Google forum and Gitter IM Channel

• Current known production deployments

• 4 Paradigm

• AlibabaCloud EDAS

• Crossplane (Upbound)

• Microsoft

• Napptive

• Oracle

• Other community members include Huawei, ACR, Chef, Fiercely, Layer5, & Red Hat

Page 8: Service Discovery and Control

SCOPE

• How an Application tells the Platform its capabilities

• Workitems – Defined by a shared code system between the Application and Platform

• Route – Data sent to the Application and once successful Platform considers job complete

• Invoked – An Application is invoked by some explicit user action

• Scopes are registered by the Platform for Applications and mapped to job

codes the Platform accepts from its Requestors

Page 9: Service Discovery and Control

APPLICATIONS:CONTROLLED AND COORDINATED BY A PLATFORM

• Container (Containerized Workload Type)

• Describes an Application running in a container. Will be instantiated by the Platform and

scaling is the responsibility of the Platform.

• Service (DICOM Server Workload Type)

• Describes an Application that provides a service. Scaling is the responsibility of the

Service and when Entrypoints change, updating the Application Manifest is the

responsibility of the Application. For example, a VNA providing storage service with a

DIMSE or DICOMweb API.

• Executable (DICOM Task Workload Type)

• Describes an Application run as an executable. Will be initiated by the Platform and

scaling is the responsibility of the Platform.

Page 10: Service Discovery and Control

ENTRYPOINT

• Described how data is accepted and results are emitted

• Can be thought of as SCU-SCP interface methods

• When describing an Application in a Manifest, these are type of Trait

• Application Components first describe the types of Entrypoint Traits they

support, then the Application Configuration applies the Entrypoint Trait values

Page 11: Service Discovery and Control

COMPONENTS

• These are the main entity of an Application

• An Application can be made up of one or more Components

• Components have one (1) Workload type, describe applicable Traits and

which of its Workload’s attributes are parameterized or mutable

Page 12: Service Discovery and Control

MANIFESTS :DESCRIBE APPLICATIONS

Page 13: Service Discovery and Control

MANIFEST EXAMPLE:TUMOR SEGMENTATION AND TRACKING SERVER

P

l

a

t

f

o

r

m

App

Component

1st instance

App

Component

2nd instance

Instantiate

Instantiate

DB ServerReadiness

Tracking

Info

Page 14: Service Discovery and Control

PRINCIPLE +CONCEPT

APPLICATION

“I do this

type of

work!”

Data to

work onRequestor

P

l

a

t

f

o

r

mJob

request

Supplement Space

Output

DICOM Operation

Scope

Entrypoint

TraitEntrypoint

Trait

Component

Workload

Page 15: Service Discovery and Control

OUTREACH TO DO’S

• OAM workgroup review final document to ensure capabilities are inline with

release version listed in document

• Security (WG-14) review

• Conformance (WG -31) review

• Web Services for DICOM (WG-27) review

• How this relates to Capabilities Service

• Possible Proof Of Concept Implementation