SIMULATOR FOR SERVICE-BASED SOFTWARE SYSTEMS: DESIG N AND IMPLEMENTATION WITH DEVS-SUITE

logic 〈X, S, Y, δext, δint, δconf, λ, ta〉 〈X, Y, D, {M d}, EIC, IC, EOC〉 reusable basic models stateless state-based loosely coupled dynamic structure discoverable dynamic structure • The concept of autonomous services corresponds to t he concept of modularity of atomic and coupled models. DEVS models are defined i terms of generic functions (δext, δint, δconf, λ) and time (ta). • The formal contract corresponds to the input/output por s and messages (X and Y), and their couplings (EIC, EOC, IC) subject to the s trict coupled model specification. The couplings in DEVS are fixed, alt hough the use of coupling in a 48 simulation can be decided during simulation. The co ncept of coupling components via ports is absent in SOA. • The concept of service composability is similar to coupled model hierarchy. SOA composability is not constrained to have strict hie rarchy. This is because DEVS hierarchy requires strict tree structure relationsh ip among (atomic and coupled) model components. In SOA, composability is based on the broker service which is not defined in DEVS. In DEVS, input and output m essages are sent and received via direct couplings – i.e., the coupled m odel contains the coupling relations between model components. • The concept of abstract logic in DEVS has a theoret ical basis (abstract structural and behavior syntax with operational semantics) whe reas SOA does not. For example, δext has template syntax that has to be completed given a component’s specific functions. In contrast, a service has an i nterface template, but without functionality. • The basic concept of reusability in SOA is more pow erful than that of DEVS. This is because the broker concept with support for publishing services and identifying services are not defined in DEVS. • The concept of stateless services promotes loose co upling of composite services. The functions of a service can be arbitrary defined . Atomic and coupled model components require state information which includes time t (t ∈ S) in order to allow synchronization of events produced and consum ed. The time-based dynamics of DEVS model components has a central rol e in simulation. 49 Based on the analysis in Table 3, we can notice tha t one fundamental difference between the DEVS and SOA is the use of the broker c oncept. In the SOA, all services must publish its service to the broker service in o rder to be discovered and composed with other services. Therefore, the connection betw e n service providers and service client is only established by the broker service on ly. In DEVS, however, the broker concept is not account ed for and thus the DEVS atomic and coupled models are not SOA compliant eve n thought these models have important similarities to those of primitive and co mposite services. In fact, we can model a SOA-like software system by using the DEVS atomic odel and coupled model and applying the concept of publish/subscribe ports and dynamic structure (Ramaswamy, 2008). However, this approach to modeling service-b ased software systems is not SOAcompliant since there is no model for the broker se rvic . 4.1.2. Mapping SOA Elements to the DEVS Elements As stated previously, the SOA elements have simila rities and differences with those of DEVS. We need to map these SOA elements in to the DEVS models in order to develop the SOAD simulator. Below, Table 4 shows th e correspondences between the SOA and DEVS elements. The SOA-compliant DEVS frame work is characterized in terms of primitive, composite, and broker services (H. Sarjoughian et al., 2008) which in this thesis are referred to as service provider, se rvice client, and service broker, respectively. 50 Table 4 Correspondences between the DEVS and SOA Elements (H. Sarjoughian et al., 2008) SOA Model Elements SOAD Model Elements services (service provider, service client, service broker) atomic models (service provider, service client, service broker ) service description entity (service-information) messages entity (service-lookup and service-call) messaging framework ports and couplings service registry and discovery executive model composition of services coupled models (service providers) In Table 4, the service provider, service client, a d service broker are mapped to DEVS atomic models. Similarly, composite service is mapped to a DEVS coupled model. In addition, the messages and their exchanges in th e DEVS can be extended to represent service description and messages. DEVS model commun ications via messages, ports, and coupling can be used to represent the SOA publish/s ubscribe concept. 4.2. Software Models To realize the SOA-compliant DEVS framework, we ne d to develop the SOAbased DEVS service provider, service client, and se rvic broker models. In addition to 51 the primitive SOA-based service models, it is also necessary to develop a composite service model. 4.2.1. SOA-Compliant DEVS Models Based on the relationship defined between SOA and DEVS frameworks (see Table 4) the service provider, service client, and service broker are primitive services in the SOAD framework. As shown in Figure 25, the serv ic provider and service client are defined to have specific ports for requesting and p ublishing services (H. Sarjoughian et al., 2008). Similarly, the service broker is define d to identify, publish, and found ports given its role with the service provider and client . The coupling relationships among the primitive service provider and service client with one broker are shown in Figure 25. Each of these SOA-based DEVS models are extended fr om the DEVS atomic model and are defined to have their unique structures and beh aviors as described in Section 4.3. For example, a service provider publishes its service t o the service broker and performs its own functionality as requested. A service client l ooks up the service information through the service broker and may subscribe to the publish ed ervice. The composition of services is represented by a coupled model. A part icular realization of the composite service is defined to be a composite service which contains at least two services. The composite service publishes its service as well as each of the services it contains to the service broker. The service broker stores the servi c definitions and sends them to the clients if the desired services are available. Three types of messages are defined for the SOAD si mulator. They are serviceinfo, service-lookup, and service-call message, as shown in Table 4. Service-info 52 message which contain the description of the servic is used between the service broker and the service provider and the service client. A service-lookup message is used by the service client in order to ascertain whether or not some desired services are available or not from the broker. The service-call message is us ed between the service client and the service provider. From the service client to the se rvic provider, the service-call message contains a data for the specific method (endpoint) in the service and it contains the serviced result from the service provider to the se rvic client. 4.2.2. A Simple Network Model We need to have a simple network model to represen t hardware aspects of the SOAD framework as shown in Figure 26 (H. Sarjoughia n et al., 2008). Basically the Publisher/Subscriber with Broker Coupled Model Idntifypulisher Broker idntifypulisher fondpulisher Publisher reuestsevices pulishsrvice pulishsrvice Subscriber F ondpulisher pulishsrvice idntifypulisher reuestsrvice pulishsrvice request and response messages input port output port data service messages publish messages msg msg Idntifypulisher idntifypulisher fondpulisher reuestsevices pulishsrvice pulishsrvice F ondpulisher pulishsrvice idntifypulisher reuestsrvice pulishsrvice Figure 25. SOA-compliant DEVS model 53 network model has capabilities of FIFO message queu e, transmission delay, and traffic bandwidth. Idntifypulisher Publisher reuestsevices pulishsrvice pulishsrvice Subscriber F ondpulisher pulishsrvice idntifypulisher reuestsrvice Network