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. The implementation is designed to be embedded into the NCP, and has the method com.spirit.epsos.cc.adc.EADCReceiver#process defined as integration point from the calling application.

NCP transactions covered by eADC

Internal dependencies

The eADC is designed to store the recieved data in a RDBMS backend. The implementation uses mySQL as RDBMS. It assumes the existence of a database named tmed.

Suggestions for integrating the eADC into the OpenNCP

As the application is designed to be embedded within the same application container as the NCP, we have several possible scenarios for integration.

Integration solution 1: direct calls

It seems that this approach is what is used in the Tiani NCP today. It is trivial to implement, as the only things needed are an import and a call to the process methods.

Integration solution 2: using javaee 6 interceptor patterns

For a general introduction to Interceptors, please refer to http://en.wikipedia.org/wiki/Interceptor_pattern

 The general idea is to introduce the calls to the eADC component through annotations to the classes and methods.

The blog post at https://blogs.oracle.com/arungupta/entry/totd_134_interceptors_1_1 describes the basic setup and use of interceptors.

Possible problems with the eADC implementation

• Effectively single-threaded
• Does not make use of webapplication servers connection pooling
• http://docs.oracle.com/javase/6/docs/api/javax/xml/transform/TransformerFactory.html#newTransformer%28javax.xml.transform.Source%29 cannot be used in threaded environments

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) ?