D3 Overview

If you already have developped an implementation of a MCDA method, whatever language is used, you may want to reuse it directly without having to rewrite it to fit D2 expectations. D3 aims to help to integrate such existing methods. It is a webapp that allows you to interact with remote services exposing MCDA methods. Data exchanged between D3 and your remote service is done trough XML files.

Only a few core concepts are used :

  • Method - a Method represents a formal MCDA Method definition
  • Service - a Service represents a remote concretization (web service, soap) of a MCDA Method
  • Job - a Job represents a suite of interaction steps between D3 and your service, it encapsulates a problem that is submitted to a remote service
  • UserFile - a UserFile is a file owned by a D3 user (a file that a D3 use has previously uploaded to D3)

Job can have four distinct state :

  • PENDING - just after the job has been created
  • WAITING - the problem has been submitted
  • SOLVED - the problem has been successfully solved
  • ERRORS - if an error occured while submitting the job

Below is a simple class diagram to help to vizualize those concepts.

D3 class diagram

The integration process is pretty straightforward :

When registering a Method, the user must provide the method input schema and the method output schema. Also XML stylesheets can be specified to allow to visualize both problem input and problem output.

The remote service must expose at least three ports whose name can configured when registering the service:

  • problem submission port (default=submitProblem)
  • solution request port (default=requestSolution)
  • hello port (not used yet ; default=hello)

Note that your SOAP service must use a rpc binding and literal encoding. You can find a WSDL sample here.

Finally D3 can be used to facilitate D2 development: D3 exposes a few interfaces that allows D2 (especially) to communicate with it. See D2 integration for a more thorough insight of that integration.