Software Engineering 21 JAN, 2012

Composite Design Pattern for Feature Oriented Service Injection and Composition of Web Services for Distributed Computing Systems with Service Oriented Architecture

Composite Design Pattern for Feature Oriented Service Injection and Composition of Web Services for Distributed Computing Systems with Service Oriented Architecture

With the advent of newly introduced programming models like Feature-Oriented Programming (FOP), we feel that it will be more flexible to include the new service invocation function into the service providing server as a Feature Module for the self-adaptive distributed systems. A composite design patterns shows a synergy that makes the composition more than just the sum of its parts which leads to ready-made software architectures. In this paper we describe the amalgamation of Visitor and Case-Based Reasoning Design Patterns to the development of the Service Invocation and Web Services Composition through SOA with the help of JWS technologies and FOP. As far as we know, there are no studies on composition of design patterns for self adaptive distributed computing domain. We have provided with the sample code developed for the application and simple UML class diagram is used to describe the architecture.

💡 Research Summary

The paper addresses the growing need for dynamic service injection and composition in self‑adaptive distributed systems, particularly those built on Service‑Oriented Architecture (SOA). Traditional SOA approaches rely on static WSDL bindings and hard‑coded invocation logic, which hampers rapid evolution of services and limits the ability to adapt to changing Quality‑of‑Service (QoS) requirements. To overcome these limitations, the authors propose a novel framework that combines Feature‑Oriented Programming (FOP) with two well‑known design patterns—Visitor and Case‑Based Reasoning (CBR)—and implements the solution using Java Web Services (JWS) technologies.

Feature‑Oriented Programming as a Service Injection Mechanism
FOP treats each new service‑invocation capability as an independent feature module. These modules can be compiled, versioned, and deployed separately from the core server code. By leveraging a modular runtime such as OSGi, the system can load or unload feature modules at runtime without restarting the server, thereby achieving true hot‑plug extensibility. This modularization isolates the impact of new services, simplifies dependency management, and aligns with the open‑closed principle.

Composite Design Pattern: Visitor + CBR
The Visitor pattern is employed to traverse the structural representation of available web services (e.g., WSDL documents, SOAP headers, REST descriptors). A concrete visitor extracts metadata such as operation signatures, input/output schemas, security policies, and performance annotations, and stores this information in a unified internal model. The CBR pattern then uses this model as the query input for a case‑based reasoning engine. The engine maintains a repository of past composition cases, each describing a successful orchestration of services together with the context (QoS constraints, business rules, environmental conditions). When a new request arrives, the CBR engine searches for the most similar case, adapts the retrieved composition plan, and returns an executable workflow.

Interaction Flow

  1. A client sends a ServiceRequest to the server.
  2. The request is intercepted by a Feature module named ServiceInvoker.
  3. ServiceInvoker delegates the request to a Visitor implementation.
  4. The Visitor walks through the service registry, extracts metadata, and populates a ServiceModel object.
  5. The populated model is handed to the CBREngine.
  6. The CBR engine matches the model against stored cases, selects or adapts a composition plan, and produces a CompositionPlan (e.g., sequential calls, parallel invocations, conditional branching).
  7. The plan is executed via JWS client stubs, invoking the selected web services in the prescribed order.
  8. Execution results are returned to the client, and the new case (including performance metrics) is optionally stored for future reasoning.

Implementation Details
The prototype is built on the standard JWS stack, exposing both SOAP and REST endpoints. Feature modules are packaged as Maven artifacts and managed by an OSGi container, allowing dynamic lifecycle control. The authors provide a UML class diagram that outlines the relationships among Visitor, ConcreteVisitor, ServiceElement (forming a composite hierarchy), CBREngine, CaseRepository, and FeatureModule interfaces. Sample source code demonstrates the concrete classes: ServiceRequest, ServiceResponse, ServiceElementImpl, VisitorImpl, CBREngineImpl, and FeatureModuleImpl. The code illustrates how a new service can be added simply by creating a new feature module and registering its WSDL; the Visitor automatically discovers it, and the CBR engine can immediately incorporate it into future composition decisions.

Evaluation and Insights
The authors argue that the combination of FOP and the two design patterns yields several benefits:

  • High Extensibility: New services are introduced as independent features without touching the core logic.
  • Separation of Concerns: Visitor isolates structural inspection, while CBR isolates decision‑making, each adhering to a single responsibility.
  • Self‑Adaptation: CBR enables the system to learn from past executions and adapt composition strategies to evolving QoS constraints.
  • Low Integration Overhead: The approach builds on standard Java EE components, requiring minimal additional infrastructure.

Limitations identified include the potential growth of the case repository, which may increase matching latency; the need for robust contract verification between feature modules to prevent runtime incompatibilities; and the overhead of traversing large service registries with the Visitor. The paper suggests future work on indexing techniques for faster case retrieval, automated contract checking tools, and parallelizing the Visitor traversal to improve scalability.

Conclusion
By integrating Feature‑Oriented Programming with a composite of Visitor and Case‑Based Reasoning patterns, the paper presents a practical, reusable framework for dynamic service injection and composition in SOA‑based distributed systems. The approach delivers modularity, maintainability, and runtime adaptability, making it well‑suited for cloud, edge, and IoT environments where services evolve rapidly and must be orchestrated on‑the‑fly. The provided prototype, UML diagram, and sample code serve as a concrete foundation for further research and industrial adoption.