Das Ziel des Projekts CAWICOMSA.17 ist die Entwicklung eines B2B-Frameworks zur verteilten Produktkonfigurierung von Waren und Dienstleistungen. Der Prototyp, die CAWICOMS Workbench, bietet domänenabhängige Tools und Techniken, um eine einheitliche Basis zur Integration heterogener Konfigurierungssysteme zur Verfügung zu stellen. Mittels einfacher und offener Protokolle, zum verteilten Problemlösen und Austauschen komplexer Datenstrukturen, wird die Integration konfigurierbarer Unterprodukte von Lieferanten bzw. Zulieferern in einen Gesamtkontext ermöglicht. Der Benutzer bzw. der Kunde erhält den Eindruck, mit einem zentralen, homogenen System zu interagieren.
Die bisherigen Anwendungsszenarien von CAWICOMS stammen aus dem Bereich Telekommunikation (vgl. Ardissono et al., 2001, S. 2): Zum einen wurden die Funktionalitäten anhand der Konfigurierung, Orderung und Bereitstellung von Telefon-Vermittlungs-Systemen evaluiert. Dazu ist es erforderlich, entsprechende Module und Rechner physikalisch innerhalb einer Netzwerktopologie anzuordnen, zu verbinden und mit spezieller Software auszustatten. Zum anderen betrifft der zweite Anwendungsfall die Konfigurierung von Netzwerken und Services in der Domäne von IP-VPN (Internet Protocol - Virtual Private Networks). Auch dies umfasst sowohl technische Aspekte wie die Router-Konfigurierung und Bandbreiten-Reservierungen als auch Service-Dienstleistungen wie z.B. Installations-Support.
Zur Beschreibung einer allgemeinen Sprache, für die Repräsentation der Eigenschaften von konfigurierbaren Produkten und Dienstleistungen, setzt CAWICOMS auf eine ontologie-basierte Methode. In der Sprache DAML+OILA.18 wird innerhalb von CAWICOMS eine flexible Produkt-Ontologie für komplexe, anpassbare Produkte modelliert (vgl. Felfernig et al., 2002, S. 196 ff.). Der Ansatz ist eingebettet in das Semantic-Web-Konzept des World Wide Web Consortium (W3C)A.19, dass sich in dieser Initiative darum bemüht, ein ,,semantisches`` Verstehen von Inhalten im Internet voranzutreiben. Ziel ist es, Internet-basierte Technologien zu entwickeln, die es nicht nur Benutzern sondern auch autonomen Anwendungen ermöglichen, auf die Ressourcen des Internets zuzugreifen (vgl. Felfernig et al., 2002, S. 204).
Das konkrete Domänenwissen wird einheitlich auf auf XML-Basis (eXtended Markup Language) repräsentiert. Die Wissensakquisition der Produktmodelle wird UML-basiert (Unified Modeling Language) in grafischer Notation z.B. in kommerziellen Tools wie Rational RoseA.20 vorgenommen und kann mittels OCL (Object Constraint Language) erweitert werden. Die CAWICOMS Workbench sieht Übersetzer für die vom Problemlösungsmechanismus benötigte, Java-basierte Wissensrepräsentation vor. In CAWICOMS wird ILOGs domänenunabhängiger, Java-basierter JCONFIGURATOR eingesetzt. JCONFIGURATOR implementiert Generative Constraint Satisfaction zur Auflösung von komplexen Konfigurierungsproblemen (vgl. Abschnitt 4.4.2). Die eigentliche Problemlösung wird in einer verteilten Architektur durchgeführt, d.h. beteiligte Konfiguratoren haben nur jeweils eine Teilsicht auf das Produkt-Modell, wobei zwischen einem synchronen und einem asynchronen Konfigurierungsmodus unterschieden wird. Die Kommunikation zwischen den Konfiguratoren findet mittels XML-basiertem SOAP messaging (Simple Object Access Protocol) und Web Services statt. Die Komponenten der CAWICOMS Workbench selbst sind als Enterprise Java Beans (EJB) konform zu J2EE (Java 2 Enterprise Edition) implementiert (vgl. Ardissono et al., 2002, S. 620 f.).
Neben dem Aspekt der verteilten Konfigurierung wurde bei CAWICOMS besonderes Augenmerk auf die Benutzeroberfläche gelegt. Der Benutzer interagiert mit einer auf seine persönlichen Fähigkeiten bzgl. des Produktwissens angepassten Oberfläche. Aufgrund von unterschiedlichen Benutzerklassen generiert das System dynamische, web-basierte Benutzerinterfaces mittels JSP (Java Server Pages). Weiterhin fließen in die Generierung der Interfaces eine regelbasierte Personalisierung (ILOG JRules) und die Interpretation der Benutzerinteraktionen mittels Bayes'scher Netze ein (vgl. Ardissono et al., 2002, S. 621 f.).