Die Anbindung an ENGCON gestaltet sich derart, dass ein Wrapper erstellt werden muss, der eine Umsetzung der von ENGCON geforderten Methoden auf die Schnittstelle von YACS übernimmt. Eine solche Wrapper-Klasse existiert bereits in ENGCON für den derzeit angebundenen, externen Constraint-Solver. Die Schnittstelle zum Constraint-System von ENGCON sieht vor, dass das Interface ConstraintSolverRmiInterface im Package engcon.control.constraintControl implementiert werden muss, um die Anbindung eines Constraint-Solvers zu gewährleisten. In der derzeitigen Anbindung wird dies mit der Implementierung in der Klasse ConstraintSolverRmiInterfaceImpl, welche sich im selben Package wie das obige Interface befindet, durch Anbindung einer externen C++-Bibliothek per Java Native Interface (JNI)7.16 erreicht (vgl. Stearns, 1997,1998).
Die obige Klasse wurde für die Integration von YACS in ENGCON durch eine eigene Implementierung ausgetauscht: Die Klasse YacsEngConInterface implementiert ebenfalls das Interface ConstraintSolverRmiInterface, nutzt dabei allerdings die Constraint-Lösungsmöglichkeiten des YACS-Frameworks. Die Implementierung dieser Schnittstelle ist prototypisch. Es wurden die essentiellen Methoden implementiert, die übrigen Methoden sind z.T. ,,Dummys``. Diese Anbindung von YACS an ENGCON dient damit ausschließlich Demonstrationszwecken und müsste für einen tatsächlichen Einsatz vervollständigt werden.
Die Implementierung in YacsEngConInterface sieht vor, dass die vorhandenen Wissensbasen von ENGCON für eine Zusammenarbeit mit YACS geringfügig modifiziert werden müssen: Jeder Constraint-Ausdruck eines Funktions-Constraints muss, separiert durch ein Trennzeichen (,,#``), um den Namen der jeweils anzuwendenden Constraint-Lösungsstrategie erweitert werden. Auf diese Weise lassen sich flexibel für unterschiedliche Constraints einer Wissensbasis unterschiedliche Lösungsverfahren einsetzen. Eine Alternative bestünde darin, eine global einzusetzende Lösungsstrategie statisch innerhalb der Wrapper-Klasse zu implementieren. Bei einer derartigen, statischen Lösung könnte auf die Modifikation der Wissensbasen verzichtet werden. Zugunsten der Flexibilität, und insbesondere um Lösungsverfahren sowohl für finite als auch infinite Wertedomänen anwenden zu können, wurde der ersteren Lösung der Vorzug gegeben.
Als problematisch erwies sich, dass ENGCON Funktions-Constraints für finite und infinite Domänen bisher nicht unterscheidet. So existiert innerhalb von ENGCON lediglich eine einzige Container-Klasse zur Kapselung und Übertragung der Wertebereiche von Constraint-Variablen an den Constraint-Solver. Auch diskrete Werte werden innerhalb dieser Klasse als Intervalle repräsentiert, nämlich als diskontinuierliche Punktintervalle.7.17 Dies war in der Vergangenheit unproblematisch, da der bisher in ENGCON integrierte Constraint-Solver ausschließlich reellwertige Intervalle verarbeitet. Innerhalb von YACS existieren allerdings unterschiedliche Kapselungen für unterschiedliche Wertedomänen. Zum einen ist eine Vermischung in der derzeitigen Implementierung von YACS nicht vorgesehen, zum anderen sollten die jeweiligen Domänen schon aus Effizienzgründen in ihrer entsprechenden Repräsentationsform genutzt werden.
Vor jeder Propagation der Constraint-Netze werden die Wertebereiche der Constraint-Variablen an YACS übergeben. Zur Vermeidung von Ausnahmen in Form von ClassCastExceptions in YACS, wurde die Unterscheidung von Domänen in der prototypischen Anbindung an ENGCON innerhalb von YacsEngConInterface pragmatisch umgesetzt: Wenn das übergebene Container-Objekt eines Wertebereichs mehrere Elemente enthält oder bereits eine FD-Variable mit gleichem Namen existiert, wird eine numerische FD-Domäne erzeugt. Ist im Container-Objekt lediglich ein Element enthalten, wird davon ausgegangen, dass es sich um ein konvexes Intervall handelt und entsprechend eine Intervalldomäne erstellt.7.18
Diese einfache Implementierung einer Integration von YACS in ENGCON ist ausreichend, um die im folgenden Kapitel 8 vorgestellten Constraint-Probleme zu verarbeiten. Ein stabiler Betrieb im produktiven Einsatz kann mit dieser Integration allerdings nicht sichergestellt werden. Für eine weitergehende Unterscheidung der Wertebereiche müsste die interne Repräsentation von ENGCON entsprechend erweitert werden. Da dies über die Implementierung einer Schnittstelle hinausgeht und es sich zudem um den Forschungsprototyp ENGCON V0 handelt, wurde von einer entsprechenden Erweiterung an dieser Stelle abgesehen.