Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Content of the epSOS Automatic Data Collector

OpenNCP Integration

The purpose of this page is to clarify the integration of the eADC in the OpenNCP structure, by initially presenting some questions and considerations resulted from the current discussions on this matter. 

Integration points

The eADC works by providing an interface and a default implementation.

Open Questions

How is the eADC interface defined?

The eADC is called from the NCP by its implementation of the EADCReceiver interface method process( EADCEntry ). A default implementation is provided by the eADC component itself: com.spirit.epsos.cc.adc.EADCReceiverImpl#process

What is the meaning of a unique / centralized contact point (for eADC)?

I (Steen) am not sure that I understand this question correctly, but the main point of having a single (singleton) eADC instance is to control access to the database. It seems like a naive solution, and further analyses could show that this may pose a bottleneck. Especially if the NCP is calling the interface synchronously.

Does the eADC has to work exclusively with interceptors?
  • Or can we embed it usage in the code, just like the audit messages handling.

It is intended to be embedded, and would be so as well if using interceptors

Can we create Evaluation Manager (EM) to proxy eADC?

The question relates to:

"The creation of a new, “floating” component that can be freely integrated at any
interception point within the NCP or compatible environments." D3.10.1 Section: 2.1

Does the eADC has to intercept information on both sides of the NCP (A+B) ?
  • No labels