Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Flying to Jupiter with OSGi - Tony Walsh (ESA) & Hristo Indzhov (Telespazio Vega)

109 views

Published on

OSGi Community Event 2018 Presentation by Tony Walsh (ESA) & Hristo Indzhov (Telespazio Vega)

Abstract: The European Space Operations Centre (ESOC) is the main operations center for the European Space Agency (ESA), operating a number of earth observation and scientific missions. Monitoring and control functions needed by spacecraft operators are provided by software systems which are reused across missions, but tailored and extended for mission specific needs. The current generation of monitoring and control systems are becoming obsolete and a European wide initiative called the European Ground Systems Common Core (EGS-CC) (http://www.egscc.esa.int) has been started to develop the next generation.

This talk will explain why OSGi was chosen and how it is used in the development of next generation of monitoring and control software. It will describe how OSGi provides the necessary framework that enables the software to be extended for the different space systems it is expected to support. The overall software architecture will be discussed, some of the challenges faced and the benefits gained by using OSGi. The first target mission for the system is JUICE (http://sci.esa.int/juice) which will explore the moons of Jupiter and which is scheduled for launch in 2022.

Published in: Technology
  • Be the first to comment

Flying to Jupiter with OSGi - Tony Walsh (ESA) & Hristo Indzhov (Telespazio Vega)

  1. 1. ESA UNCLASSIFIED - For Official Use Flying to Jupiter with OSGi Anthony Walsh, ESA Hristo Indzhov, Telespazio Vega
  2. 2. ESA UNCLASSIFIED - For Official Use !2 What has OSGi to do with Juipter? OSGi + =
  3. 3. ESA UNCLASSIFIED - For Official Use !3 Spacecraft Mission Control ESOC Operations Centres Mission Control System (MCS) Telecommands Telemetry ESTRACK Control Centre (ECC)
  4. 4. ESA UNCLASSIFIED - For Official Use !4 JUICE - JUpiter ICy moons Explorer • Mission to visit the Jovian system focused on studying three of Jupiter's Galilean moons: Ganymede, Callisto, and Europa • Prime Contractor is Airbus Defence and Space • Launch in 2022 with arrival in 2029 after a sequence of five gravity assist manoeuvres with Earth, Venus, Earth, Mars, and again Earth • In 2033, after completing various manoeuvres around Jupiter and the other moons will enter orbit around Ganymede • Instruments include cameras, spectrometers, magnetometers, and an ice-penetrating radar
  5. 5. ESA UNCLASSIFIED - For Official Use !5 JUICE - Scientific Objectives • Mission will perform detailed investigations of Jupiter and its system of moons • Give better insight into how gas giant planets and their satellites form and evolve • Three of the moon are believed to harbour internal oceans; Ganymede, Europa & Callisto • Emphasis on Ganymede as a planetary body as a potential habitat of life • Characterisation of the ocean layers • Topographical, geological and compositional mapping of the surface • Characterisation of icy crusts and internal mass distribution, dynamics and evolution of the interiors • Study Ganymede's intrinsic magnetic field
  6. 6. ESA UNCLASSIFIED - For Official Use !6 JUICE - Making it happen • Returns are great, but space is expensive! – cost of the JUICE mission is approx. 850 million Euros • The costs of scientific missions like JUICE are very great for any one nation – can be difficult to justify • Sharing costs and expertise amount nations therefore makes a lot of sense • Much better return for each member state per Euro spent • The European Space Agency was created to coordinate space activities between European nations
  7. 7. ESA UNCLASSIFIED - For Official Use !7 European Space Agency (ESA) Over 50 years of experience 22 Member States Eight sites/facilities in Europe, about 2300 staff 5.75 billion Euro budget (2017) Over 80 satellites designed, tested and operated in flight
  8. 8. ESA UNCLASSIFIED - For Official Use !8 ESA Activities space science telecommunications human spaceflight earth observation space transportation navigation operations technology exploration * Space science is a Mandatory programme, all Member States contribute to it according to GNP. All other programmes are Optional, funded ‘a la carte’ by Participating States. ESA combines responsibility in nearly all areas of space activity. Operations - ESOC
  9. 9. ESA UNCLASSIFIED - For Official Use !9 European Space Operations Centre (ESOC) • Mission Control Centre of ESA • Operating since 1967 • Mission and Launch Operations • Operation of ESA’s world wide network of Ground Stations (ESTRACK) • Centre for space debris studies and services, space security, ground system engineering, the design and development of tracking stations and satellite navigation • Focus on Earth Observation, Astronomy and Solar System Exploration Missions
  10. 10. ESA UNCLASSIFIED - For Official Use !10 ESOC – Selection of Missions (81 and counting) Herschel GaiaPlanck Mars Express LISA PathfinderExoMarsMars Express Rosetta BepiColombo Cheops Solar Orbiter James Webb Space Telescope BepiColombo Goce Swarm Sentinels Galileo
  11. 11. ESA UNCLASSIFIED - For Official Use !11 Earth Observation Missions - Cyrosat • Monitors variations in the extent and thickness of polar ice • Monitors the changes in thickness of marine ice, and variations in the thickness of the ice sheets that overlie Greenland and Antarctica • Tracks changes in the thickness of the ice with a resolution of about 1.3 centimetres • Important in monitoring impact of climate change, expected to be amplified at the poles • Main payload is a radar altimeter called SIRAL • Launched 2010 - initial programmatic lifetime was 3.5 years, but still going strong
  12. 12. ESA UNCLASSIFIED - For Official Use !12 Astronomy Missions - Planck • Mapping of the cosmic wave background • Afterglow from the big bang – @ 380,000 years universe cooled enough (3000K) for protons and electrons to combine to form neutral hydrogen atoms and allow photons to travel freely • Fundamental to Cosmology • Liquid Helium used to maintained an instrument temperature of −273.05 °C (0.1 °C above absolute zero) - coldest known object in space • Operated 2009-2012 when helium exhausted
  13. 13. ESA UNCLASSIFIED - For Official Use !13 Solar System Exploration Missions - Rosetta • Performed detailed study of comet 67P/Churyumov–Gerasimenko • Rosetta spacecraft placed in orbit during active phase around the sin • Released Lander module Philae for first successful landing on a comet until battery power ran after 2 days • Showed that water from comet 67P is substantially different from that found on Earth • Launched in 2004, arrived 2014 and mission ended in 2016
  14. 14. ESA UNCLASSIFIED - For Official Use !14 Renewal of Monitoring Control Systems – ESC-CC • Many different systems for monitoring and control used for space system operations and Assembly Integration and Testing (AIT) • Many are reaching the end of life • Agreement within Europe to develop common infrastructure to support space systems monitoring and control • Share and reduce system development costs and maximise synergy and interoperability • Modernization of AIT and MCS systems • Ambitious collaboration between ESA, national agencies, prime industry and SMEs
  15. 15. ESA UNCLASSIFIED - For Official Use !15 EGS-CC technology requirements and OSGi Selection • Development of EGS-CC started with requirements specification and technology evaluation and selection activities • A number of criteria were taken into consideration, including; o Modular and extensible for different mission needs; o Performance, reliability, scalability, etc o Compatibility with EGS-CC licensing needs; o Longevity of technology and future outlook; o Knowledge within and outside of Space domain (community strength). • A number of technologies were considered for the EGS-CC component framework (EJB, SCA, CCM, OSGi, etc) – OSGi was selected as most appropriate • Selected technologies was input into the contract with the Industry Consortium for the implementation phase of EGS-CC
  16. 16. ESA UNCLASSIFIED - For Official Use !16 EGS-CC Development Consortium
  17. 17. ESA UNCLASSIFIED - For Official Use !17 Project Organisation •The project spans − 8 Countries, − 17 Companies, − 23 Teams and − 43 Components • 11 System Architects • 12 Integration and Validation Engineers
  18. 18. ESA UNCLASSIFIED - For Official Use !18 Software Development Environment •Technology Baseline − Java 1.8.0.x (openJDK - openSUSE, Oracle JDK - SLES) − Apache Maven 3.2.3 − Apache ServiceMix 5.4.0 (Karaf 2.4.1) − Eclipse SDK 4.4.1 (Luna SR1) − Linux openSUSE 13.2, SLES 12 •SDE Continuous SDE Development Linux OpenSUSE 13.2 or SLES 12 Open JDK or Oracle JDK Eclipse IDE Maven Git Groovy •SDE Continuous SDE Continuous Integration SonarQube Nexus Jenkins Open JDK or Oracle JDK Maven Git Groovy Postgre SQL Linux OpenSUSE 13.2 or SLES 12
  19. 19. ESA UNCLASSIFIED - For Official Use !19
  20. 20. ESA UNCLASSIFIED - For Official Use !20 What is EGS-CC? •EGS-CC is a software infrastructure designed to support distributed space M&C systems •It is layered (kernel, reference implementations, reference test facilities) and each layer contains EGS-CC components •EGS-CC components can be combined in various ways to form EGS-CC applications •The applications are used as building blocks for EGS-CC systems EGS-CC Kernel (Core M&C Functionality, Data Handling, Application Support Reference Implementations (Mission Adaptation, UI, Preparations, Evaluation Rereference Test Facilities
  21. 21. ESA UNCLASSIFIED - For Official Use !21 Conceptual Overview Component A Impl. Component Impl. Component Component B Impl. Component Impl. Component Impl. Component Deployable Unit A Deployable Unit D Deployable Unit C Deployable Unit B Deployable Unit E Application A Application B Application C Application D System A System B Session C Application C Application D Session D Application D Session A Application A Application B Session B Application A Application C
  22. 22. ESA UNCLASSIFIED - For Official Use !22 EGS-CC Components •The EGS-CC System is composed of layers. Each layer is decomposed into so called “Level 0” (L0) Components and their provided and consumed services •L0 components are EGS-CC software packages that cover a functional scope specified by software requirements and interact with other L0 components only via well-defined services and interfaces •L0 components are composites that are further decomposed into lower level components called Ln Components (n=1,2,…)
  23. 23. ESA UNCLASSIFIED - For Official Use !23 Component Decomposition • The definition of separate Ln components can be governed by deployment considerations, separation of concerns, etc •The result of the decomposition process is a set of implementation components (Ln), which may or may not be deployed together •A “deployable unit” is defined as a composite that includes implementation components from a single L0 component that need to be deployed together Component A Impl. Component Impl. Component Deployable Unit Impl. Component Deployable Unit Impl. Component
  24. 24. ESA UNCLASSIFIED - For Official Use !24 Component Decomposition
  25. 25. ESA UNCLASSIFIED - For Official Use !25 Implementation Components •Implementation components are assembled from units implemented in a specific programming language (Java) •The development of implementation components is supported by the EGS-CC Component framework •The EGS-CC Component framework is based on OSGi and defines the programming entry point and controls the life cycle of an EGS-CC component
  26. 26. ESA UNCLASSIFIED - For Official Use !26 Impl. Component Wiring & Deployable Units • Grouping of impl. components into functional units (Deployable Units) is done in the model • It is a process opposite of component decomposition • A deployable unit (DU) is a collection of impl. components of a given EGS-CC component and their internal wiring
  27. 27. ESA UNCLASSIFIED - For Official Use !27 Deployable Units Composition • Every deployable unit has a boundary with ports (consumed and provided services); this is the “face” of the deployable unit that the application “sees” • Deployable units are wired automatically; the model supports properties and filters if the user needs to modify the default wiring • A deployable unit is realized as a maven project with custom packaging “deployable-unit” and is generated from the model − a karaf feature file that lists all needed bundles (implementation components and apis) − an optional wiring xml that represents internal service wirings and external ports expressed in the model
  28. 28. ESA UNCLASSIFIED - For Official Use !28 Deployable Units Composition
  29. 29. ESA UNCLASSIFIED - For Official Use !29 EGS-CC Component Deployable Units Composition OSGi Bundle Blueprint OSGi Bundle Base Class OSGi Bundle Base Class OSGi Bundle Base Class OSGi Bundle Blueprint OSGi EGS-CC
  30. 30. ESA UNCLASSIFIED - For Official Use !30 EGS-CC Application •An EGS-CC application is a collection of deployable units (maven project with dependencies of type deployable-unit) •For every deployable unit referenced in the application a blueprint wiring is generated from the model wiring or directly from the base classes contained in that DU •An application feature repository is generated to group all required bundles
  31. 31. ESA UNCLASSIFIED - For Official Use !31 Wiring -> Blueprint Deployable Unit Wiring Boundary Ports Consumer Ports Provider Ports Composition Internal Ports Consumed Services Provided Services Base Classes Custom Wiring Deployable Unit Blueprint Component References Services Base Class Bean Component References Services Base Class Bean …
  32. 32. ESA UNCLASSIFIED - For Official Use !32 EGS-CC Application Generation Deployable Unit Impl. Component Impl. Component Wiring Karaf Feature Application DU DU DU Blueprint Blueprint Blueprint Karaf Feature Karaf Feature Application Karaf Feature Deployable Unit Impl. Component Impl. Component Wiring Karaf Feature
  33. 33. ESA UNCLASSIFIED - For Official Use !33 EGS-CC System •An EGS-CC System is a set of system sessions (or sessions) composed of applications. The application run on physical or virtual nodes •A session can span multiple nodes •The relationship between applications, sessions and systems is captured in a deployment plan •The deployment plan specifies a schema for each session. The session schema specifies the relationship between applications and nodes •EGS-CC deployments are defined by the user at deployment time and cannot be changed at runtime.
  34. 34. ESA UNCLASSIFIED - For Official Use !34 EGS-CC Deployment Plan Application A Session A Node A Node B Session B Application B Application C Deployment Plan
  35. 35. ESA UNCLASSIFIED - For Official Use !35 Zookeeper Node Master Node EGS-CC System Deployment OSGi Framework/JVM EGS-CC Application EGS-CC Component Framework EGS-CC Application Control EGS-CC Distributed Services OSGi Framework/JVM EGS-CC Master Application EGS-CC Component Framework EGS-CC Application Control EGS-CC Distributed Services EGS-CC Runtime Management OSGi Framework/JVM EGS-CC Application OSGi Framework/JVM EGS-CC Leader Application EGS-CC Component Framework EGS-CC Application Control EGS-CC Distributed Services OSGi Framework/JVM EGS-CC Application OSGi Framework/JVM EGS-CC Application Node OSGi Framework/JVM EGS-CC Leader Application OSGi Framework/JVM EGS-CC Application OSGi Framework/JVM EGS-CC Application Service Registry System State Active MQ
  36. 36. ESA UNCLASSIFIED - For Official Use !36 EGS-CC Infrastructure EGS-CC Component Framework (CF) EGS-CC Application Control (AC) EGS-CC Distributed Services (DS)
  37. 37. ESA UNCLASSIFIED - For Official Use !37 EGS-CC Component Framework •EGS-CC CF provides the “low level” facilities to implement EGS-CC Components and also to control their life cycle •It defines an EgsccActivator interface which is used as an entry point to an EGS-CC implementation components − Every EGS-CC implementation component has an EGS-CC base class (implements EgsccActivator) which defines the consumed and provided services. The stubs of the base classes are generated from the model − Specific hooks in the base class control the life cycle of the component. The hooks are implemented to suit component needs
  38. 38. ESA UNCLASSIFIED - For Official Use !38 EGS-CC Base Class
  39. 39. ESA UNCLASSIFIED - For Official Use !39 Impl. Component Life Cycle •The life cycle of an EGS-CC component (e.g. its impl. components) starts with the Init() phase which corresponds with the activation of an OSGi bundle. This is a single phase where services are provided and consumed •It is assumed that after the Init() the component is ready to do work and startProcessing() is called •To initiate shutdown stopProcessing() is called. The impl. component can subscribe to different shutdown levels Init() startProcessing() stopProcessing()
  40. 40. ESA UNCLASSIFIED - For Official Use !40 Service Life Cycle •For EGS-CC CF a service is any service marked with the EGS-CC annotations @Service (a stateless service) or @ConversationalFactoryInterface (a statefull service with or without callback) •EGS-CF listens for EGS-CC service registrations and unregistrations, using a standard OSGi ServiceListener •Every time a new EGS-CC service is registered in the container, CF inspects it and adds EGS-CC specific properties to it (registers it again with new properties) − At any given moment two registrations of the same service exist in the container − CF hides the original service registration by utilizing an EventListenerHook and a FindHook − CF makes sure that all other components see only the modified service registration
  41. 41. ESA UNCLASSIFIED - For Official Use !41 Service Life Cycle
  42. 42. ESA UNCLASSIFIED - For Official Use !42 EGS-CC Service Properties • egscc-service-status=READY – marker for processed services • service.pid – sets this standard OSGi property to a random UUID • system-session-id – sets this property to the current system session ID provided by the system resources • service.exported.interfaces=* - only if the service is not marked with @LocalInterface • esa.egscc.service.nature – sets this property to the value esa.egscc.service.nature.local only if the service is marked with @LocalInterface and the property is not already set. This property can take one of two values: − esa.egscc.service.nature.local – this means that the service should not be exported, but can be in certain circumstances; − esa.egscc.service.nature.internal – this means that the service must never be exported
  43. 43. ESA UNCLASSIFIED - For Official Use !43 EGS-CC Application Control •EGS-CC Application Control (EGS-CC AC) is the component responsible for starting and stopping nodes in an EGS-CC system, as well as creating, starting, stopping, and removing application instances on those nodes •It also monitors the state and health of every node and every application instance, and notifies subscribers for all changes
  44. 44. ESA UNCLASSIFIED - For Official Use !44 EGS-CC Application Control •An EGS-CC node is a single Karaf distribution with a root instance and zero or more child instances •All root Karaf instances are called Leaders. A Leader is a special application which can create, start, stop, and remove other application instances on the same node •There is a special Leader, called the Master, which operates on the Master node. There is a single Master per EGS-CC system instance. The Master can start and stop other EGS-CC nodes
  45. 45. ESA UNCLASSIFIED - For Official Use !45 Provided Services •SystemControlService – A stateless service which provides capabilities to start and stop nodes, and also create, start, stop, and remove application instances •SystemStatusService – A stateless service which provides capabilities to inspect the running system instance •SystemMonitoringService – A conversational service which is responsible for subscribing to any state or health changes in the system instance
  46. 46. ESA UNCLASSIFIED - For Official Use !46 EGS-CC AC & OSGi Cluster Information Q: Is EGS-AC an implementation of the OSGi Cluster Information specification? A: It does not implement NodeStatusService, but provides the SystemStatusService, which can: - return a collection of all nodes in the system (cluster) and - provide status and health information for each node where every node is responsible to publish its own status.
  47. 47. ESA UNCLASSIFIED - For Official Use !47 EGS-CC Distributed Services •EGS-CC Distributed services (EGS-CC DS) handles remote service discovery and remote procedure call (RPC) •It hides the fact that an application instance may be using services which actually reside in another application instance (on the same or on another EGSCC node)
  48. 48. ESA UNCLASSIFIED - For Official Use !48 Service Discovery •Publishes started applications in the service registry (For every service in the local OSGi container that can be exported, EGS-CC DS publishes the service’s type and properties in the registry, under the record of the application instance) •Actively watches the registry for any changes. If it finds exported services from other application instances, it will import those services (Registers proxies for remote services, in the OSGi container, with the same type and properties) •Watches the registry for removed services and application instances (unregisters proxies from the OSGi Container)
  49. 49. ESA UNCLASSIFIED - For Official Use !49 RPC •Acts as both client and server because it has to be able to call methods on remote services and also translate remote calls to local service invocations •An object can be passed as argument by value or by reference − Any object can be used as a remote reference if it its class is not marked final (or has an interface) − If a class of an object is not known in the receiving container it will be resolved by a network class loader •Monitors the life cycle of remote instances and ensures that they are properly garbage collected in the containers •It is completely transparent for impl. components
  50. 50. ESA UNCLASSIFIED - For Official Use !50 RPC
  51. 51. ESA UNCLASSIFIED - For Official Use !51 EGS-CC DS & OSGi Remote Services Q: Is EGS-CC DS an implementation of the OSGi Remote Services specification? A: It supports directly the concepts of the Distribution Provider and End Point. It also makes use of the service properties as defined in the OSGi Remote Services specification. It does not have a direct counterpart for Topology Manager, Remote Service Admin and Discovery. For EGS-CC DS the remote service registry: − notifies other frameworks that a local service has been exported − keeps track of the remote frameworks and exported services, − receives events about exported services (registration/unregistration) triggering import or unregistration of a remote service, − exposes remote services selectively based on Sessions
  52. 52. ESA UNCLASSIFIED - For Official Use !52 EGS-CC Infrastructure & OSGi Specification •Application Control and Distributed Services are standalone projects and EGS-CC specific requirements were layered on top of them. •Application Control and Distributed Services already implement a significant portion of functionality defined by OSGi Specification •A layer complient with OSGi Specification can be realized on top of Application Control and Distributed Services •The result could be made available to the community (if ESA decides to do so)
  53. 53. ESA UNCLASSIFIED - For Official Use !53 The good, the bad and the ugly “Our prime job is to fly spacecraft not develop software” •Big projects and consortium syndrome •Learning OSGi a we go (difficult to backtrack) •Best practices for service dependency management not applied •Endless levels of decomposition = bad code •Technical discussions steered by stakeholders can result in poor design decisions (as the saying goes: too many cooks spoil the broth)
  54. 54. ESA UNCLASSIFIED - For Official Use !54 THANK YOU Contact: Anthony.Walsh@esa.int Hristo.Indzhov@telespazio-vega.de
  55. 55. ESA UNCLASSIFIED - For Official Use !55 BONUS SLIDES
  56. 56. ESA UNCLASSIFIED - For Official Use !56 Deployable Unit Wiring
  57. 57. ESA UNCLASSIFIED - For Official Use !57
  58. 58. ESA UNCLASSIFIED - For Official Use !58
  59. 59. ESA UNCLASSIFIED - For Official Use !59 Deployable Units Composition
  60. 60. ESA UNCLASSIFIED - For Official Use !60 EGS-CC Service Patterns •Stateless Service Pattern •One-Way Stereotype •Conversational Service Pattern (± Callbacks)
  61. 61. ESA UNCLASSIFIED - For Official Use !61 Stateless Service Pattern Code usage – Server Side – Service Provider The server implements the interfaces of the services, according the needed functionalities. In our example ConfigurationTrackingServiceImpl class The server registers the services into the OSGi registry, by using the Component Framework Details about the CF are explained later // Get the EGS-CC Bundle context, provided by the Kernel Infrastructure (CF) EgsccBundleContext egsccBc = EgsccFrameworkUtil.getEgsccBundleContext(); // The stateless service implementation ConfigurationTrackingService myService = new ConfigurationTrackingServiceImpl(); // Register the service to the OSGi context egsccBc.registerService(ConfigurationTrackingService.class, myService);
  62. 62. ESA UNCLASSIFIED - For Official Use !62 Stateless Service Pattern Code usage – Client Side – Service Consumer The client resolves the service via the OSGi bundle context Service resolution done by using the Infrastructure utilities, or by Blueprint, OSGi Service Trackers, etc… OSGi services are unique in the OSGi Context Stack Multiple instances are supported by specifying properties // Get the EGS-CC Bundle context, provided by the Infrastructure EgsccBundleContext egsccBc = EgsccFrameworkUtil.getEgsccBundleContext(); // Retrieve the service from OSGi ConfigurationTrackingService myService = egsccBc.getService(ConfigurationTrackingService.class); // Consume the service via the service object, by calling its methods ConfigurationItemContainer confItemContainer = myService.getConfigurationItems();
  63. 63. ESA UNCLASSIFIED - For Official Use !63 OneWay Stereotype In EGS-CC the presence of the stereotype <<OneWay>> in methods, can be placed in both Stateless and Conversational interface methods. The method must return void and must not declare any exception
  64. 64. ESA UNCLASSIFIED - For Official Use !64 OneWay Stereotype The interface IMcmDefinitionListener in this case will have Java annotations to identify the One-Way methods The @OneWay annotation is read by the Component Framework at runtime, and it will choose the right way to handle it, during the remoting of the service Details about remoting are explained later public interface IMcmDefinitionListener { @OneWay void onSubscriptionClosed(); @OneWay void onUpdate(McmDefinitionSnapshot mcmDefinitionUpdate); }
  65. 65. ESA UNCLASSIFIED - For Official Use !65 Conversational Service Pattern The Conversational Service pattern in EGS-CC can be defined using the <<Conversation>> stereotype Stateful service where the service provider maintains the conversation state A dedicated instance of the service provider serves one and only one conversation
  66. 66. ESA UNCLASSIFIED - For Official Use !66 Conversational Service Pattern The code generation in this case requires a factory interface (Abstract Factory design pattern), which can be used by the service consumer to initialize the conversation
 The Java annotation @ConversationalInterface accepts a parameter which identifies the type of Conversation
  67. 67. ESA UNCLASSIFIED - For Official Use !67 Conversational Service Pattern The generated code @ConversationalInterface(type = ConversationType.BASIC) public interface IMcmDefinitionSupplier { @StartConversation void subscribe(McmDefinitionFilter filter); @EndConversation void unsubscribe(); void updateSubscription(McmDefinitionFilter filter); } @Service public interface McmDefinitionMonitoringService extends IMcmDefinitionSupplier { }

×