The intention of the broker example is also to demonstrate the applicability of our method in a controlled and more realistic scenario that allows us to discuss the power of the specification using intersection types and the simultaneous fulfillment of multiple orthogonal requirements. Additionally, we want to synthesize and generate behavior of connector that are conform to specified (communication-)protocols.
8.2.1
Setup
In this synthetic example, we will focus on certain details of code genera- tion. This example corresponds to a classical example that is described and motivated by Buschmann et al. [1996]. The scenario is a software system consisting of 6 clients and 4 servers as depicted in Figure 8.3. Each server provides a separate service. The clients are using services provided by the servers. Every client needs for its tasks all services provided by the servers. This leads to a classical n × m problem for n clients and m servers and the architecture needs n × m connections between clients and servers. As discussed in [Buschmann et al., 1996, pages 237ff], such a software system has many disadvantages and problems as well as it hinders the evolution of the software system. Buschmann et al. [1996] proposes a solution to this problem that introduces a broker pattern into the software system. The broker decouples clients and servers by an indirection over itself. The broker in Figure 8.4 becomes a central relay for all communications between clients and servers. Such a software architecture design change does not completely solve the problem for a software architect. After introducing the central broker, one problem still remains, how do client and server interact with each other through software connectors? Even tough we reduced the amount of needed software connectors from n × m to n + m, but these n + m connectors still have to be implemented. Furthermore, in realistic scenarios, we cannot expect that we have to implement a homogeneous set of software connectors. Each software connectors might have to conform to individual requirements of each client and server. Even in this example, 10 software connectors have to be synthesized and generated.
8.2. DETAILED BROKER PATTERN EXAMPLE 171
Server 4
Server 3
Server 2
Server 1
Client 1
Client 2
Client 3
Client 4
Client 5
Client 6
Server 4
Server 3
Server 2
Server 1
Client 1
Client 2
Client 3
Client 4
Client 5
Client 6
Broker
Figure 8.4: Many-to-many client server application with broker pat-
tern [Buschmann et al., 1996, pages 237ff]
We use ArchiType with an appropriate C&C type environment and tem- plates to synthesize these software connectors automatically. We now describe the setup of the experimental system and additional requirements which are as follows.
For every server, we have a server application exposing service interfaces
IS1, . . . , IS4 with different semantic properties in P .
• Server 1 uses a SOAP web service (IS1) to provide its service.
• Server 2 also uses a SOAP web service (IS2) to provide its service and
in addition the web service requires authentication.
• Server 3 uses a REST web service (IS3) to provide its service.
• Server 4 uses a NetTCP web service (IS4) to provide its service. The
web service also provides a supplemental secure connection channel via asymmetric encryption using a certificate (implying an existing PKI-infrastructure).
8.2. DETAILED BROKER PATTERN EXAMPLE 173
8.2.2
Execution
In order to increase the experiment’s complexity, we introduce a further not unrealistic requirement for a single client. Client 1 needs a fa¸cade (pattern)
[Buschmann et al., 1996, pages 294ff] for interface IS1′ to connect to server 1’s
(or broker’s) service interface IS1. An additional adapter building block
is needed for synthesizing this fa¸cade. This adapter building block uses higher-order typed combinators that provide data-adaptation / -conversion functionality. Every client is a console application using all four services
interfaces IS1, . . . , IS4 provided by the servers.
The broker requires that all its messaging [Buschmann et al., 1996, pages 221ff] satisfies all the individual requirements demanded by the servers. We present the capability of our approach by transforming the initial synthesis question for n + m connectors to a synthesis question for synthesizing only a single connector encapsulating a broker pattern inside. The pattern also includes the behavior to relay messages to the correct receiver (client or server). Then, we have to generate program codes and configurations for n + m software connectors and the broker. This broker software connector is now a n-to-m software connector.
The original code for clients and servers is 116 LLOC resp. 169 LLOC of C# and 318 LLOC resp. 236 LLOC of WCF-configuration. The code contains many repetitions for the n × m connections.
Every software connector in the system was generated from its interface declaration used as a contract. All contracts have been compiled into appro- priate WCF-configurations. The broker’s container building block provided
interfaces IS1, . . . , IS4 and also its WCF-configuration was generated. The
services with interfaces IS1, . . . , IS4 of the broker relay the requests to the
correct server and also the responses to the correct client. The broker uses asynchronous completion token [Buschmann et al., 1996, pages 268ff] to correlate communication requests and responses.
8.2.3
Results, Analysis, and Discussion
An appropriate C&C type environment has been designed to capture and reflect the demanded (semantic) requirements of the Combinatory Logic Connector Synthesis method described in Chapter 6. An appropriate UML2- component diagram has been sketched and complementary stereotypes have been assigned scenario-adequate types. After choosing one particular solution out of 4096, ArchiType generated the necessary code consisting of 993 LLOC in
less than 7 seconds. The 4096 solutions resulted from the 46 variations based
The server addresses had to be manually modified. Then, the servers and the clients could be executed without errors according to the specified setting.
Even though the broker’s container building block must be specified for all variants of n and m connectors for clients and servers, the T4 template is made smart enough to allow different cardinalities n and m of connections. Therefore, all container building blocks of the container are linked to a single set of T4 template files. Here, a set is needed, because a server consists of multiple individual source code files, C# source code files, WCF- configurations, and a deployment description for easier testing.
The example and the related experiment demonstrate that ArchiType and our method is adaptable to such application scenarios as well as powerful
enough that software connectors with arbitrary complexity4can be synthesized
and generated. Furthermore it demonstrates that the behavior of a connector to execute protocols can be hidden by encapsulating the behavior in an abstract specification of a corresponding building block and in associated templates implementing the behavior.