Project Topics
Get Complete Project Material File(s) Now! »
SOSJ : The Integration of SOA Paradigm with SystemJ
As explained in Section 2.7, SystemJ possesses features which are able to satisfy most of the design and programming requirements of DISS. However, SystemJ is designed to target static distributed systems and doesn’t possess programming constructs and mechanisms to deal with dynamic behaviours. On the other hand, SOA promotes the concept of dynamic, loose coupling of software behaviours which facilitates dynamic orchestration between software behaviours. Based on this observation, a novel programming paradigm called Service Oriented SystemJ (SOSJ) is proposed. This programming paradigm is achieved through the synergy of SOA paradigm and the system-level language SystemJ. The original SystemJ Runtime Support is extended to achieve the SOA-based interaction of Publish, Find, and Bind services shown in Figure 2.1. The extension introduces SOA functionalities which allow CD to discover, advertise, and invoke services dynamically.
To realize the synergy of SOA paradigm with SystemJ, a number of new elements and features have to be introduced into SystemJ. First, the concept of service entity in SOA which use or provide services are adopted into SystemJ software behaviour. Second, similar to service entity in SOA, a CD needs to have service description which provides additional information regarding functionalities (services) offered by a CD. Third, the information exchange mechanism as one feature provided by the SOA paradigm needs to be integrated with SystemJ. Fourth, the feature of loose-coupling to enable dynamic orchestration of software behaviours in the SOA paradigm needs to be implemented. This chapter elaborates how the concepts and features in SOA are adopted by SystemJ to realize the above features. This chapter is organized as follows. Section 3.1 considers a new perspective on how to look at software behaviours from the context of both the SOA paradigm and SystemJ. Following this perspective, new provisions are proposed in the following sections. Section 3.2 introduces service description in SOSJ and how it is structured to define and provide information regarding services and their interfaces for service consumer to perform service
SOSJ : The Integration of SOA Paradigm with SystemJ
invocation. Section 3.2 also introduces service registry, which has a data structure that stores service description and its structure. Next, Section 3.3 explains the underlying SOA functionalities in SOSJ, which consist of Beacon, Advertisement, Request for Advertisement, Discovery, Discovery Reply, and Notify to realize the SOA-based Publish and Find interactions illustrated in Figure 2.1. Finally, Section 3.4 describes the necessary provisions to allow service invocation, therefore realizing the Bind interaction depicted in Figure 2.1.
As previously mentioned, the SOA paradigm uses the terminology of service entity to refer to software behaviours. On the other hand, in SystemJ, CD is a software behaviour which is composed from one or more synchronous reactions. The synergy of both SOA paradigm and SystemJ leads to adoption of the nature of service entity in SOA (i.e. to use or provide services) into SystemJ.
With this synergy, a reaction may possess service consumer role (which uses services), service provider role (which provides services), or both (due to the possibility of nested reactions). Since CD is composed from one or more synchronous reactions, CD will have the same roles as the synchronous reactions that compose it, and therefore, unlike SOA which sees service entity as software behaviour that either uses or provides services, SystemJ allows CD to have mixed service provider and consumer roles. However, since the synchronous reactive MoC is enforced within individual CDs in SystemJ to preserve determinism and guarantee functional correctness, individual reactions are constrained to the ‘tick boundary’ of CD and thus are considered as integral parts of CD. Therefore, reaction can’t be considered as an exact equivalent of service entity, since service entity in SOA is not considered to have such limitation. Based on the reactions that compose it, there are three different scenarios for a CD:
- CD is composed from one or more reactions which all have service consumer role only.
- CD is composed from one or more reactions which all have service provider role only.
- CD is composed from one or more reactions with a mix of service provider and service consumer role.
Also, it is possible that some or all synchronous reactions in the CD are connected with other reactions in the same CD (via signals) or other CDs (via channels) to produce new services created by composition of individual services offered by individual reactions. In scenario 3), since individual reactions in a CD can be composed from hierarchical child reactions, reactions in the same CD may also possess mixed service provider and consumer roles due to their child reactions which may consist of service provider role, service consumer role, or a mix of both. The examples of scenarios 1), 2) and 3), and creation of composite service are illustrated in Figure 3.1. Note that since SystemJ uses the abstracted communication mechanisms of signal and channel, the implementation of service interfaces in SOSJ will adopt the same abstraction.
As shown in Figure 3.1., the CDs illustrated by the examples on the top-left, top-right, and bottom part can be in the same subsystem or distributed in different subsystems. The top-left part can represent scenario 1) or 2). If scenario 1) applies, reactions R11 and R12 have service consumer role. In this case, R11 can invoke services offered by R21 via channel Ch1121 and receives results via channel Ch2111. Alternatively, if scenario 2) applies, R11 and R12 have service provider role, while R21 and R31 have service consumer role. In this case, R21 can invoke the services offered by R11 via channel Ch2111 and receives results via channel Ch1121. Meanwhile, the top-right part illustrates CD4 which forms an example of scenario 3). For instance, reaction R41 and R43 have service provider role, while R42 and R44 have service consumer role. Having service consumer role, R51 can invoke the services offered by R41 via Ch5141 and receive results via Ch4151. Finally, the bottom part illustrates an example of the creation of composite service. For example, reaction R73 acts as an orchestrator that forms a composite service through the composition of itself with R71 via signals. As a service consumer, R91 can invoke the composite service via Ch9173 and receives results via Ch7391.
With the adoption of SOA paradigm, the bindings of channels used by reactions in different CDs are made to be reconfigurable to allow dynamic interactions/aggregations of reactions in different CDs. This feature is also needed when any change of the presence of CD occurs. It is worth noting that despite the aforementioned changes in the nature of CDs due to the SOA paradigm, the nature of subsystem remains unchanged (i.e. subsystem encapsulates one or more CDs handled by the same RTS and JVM). The nature of signal is also unchanged since signal is a broadcast-like mechanism which, once emitted, will be visible by all reactions in the same CD (no need for reconfiguration of signals).
1 Introduction
1.1 Dynamic Intelligent Software Systems: Design Challenges
1.2 Motivating Example
1.3 Identified Design and Programming Requirements
1.4 Thesis Contributions
1.5 Thesis Outline
2 Background and Related Works
2.1 Multi Agent Systems
2.2 Service Oriented Architecture
2.3 Industrial Standard Approaches
2.4 Formal Model of Computation-based Approaches
2.5 Combination of Different Software Paradigms
2.6 Qualitative Comparisons of State of the Art
2.7 Summary and Conclusions
3 SOSJ : The Integration of SOA Paradigm with SystemJ
3.1 Software Behaviours from the perspective of SOA and SystemJ (SOSJ)
3.2 Service Description and Service Registry
3.3 SOA Functionalities
3.4 Service Invocation
3.5 Concluding Remarks
4 Extending SOSJ for Dynamic Behaviours
4.1 Introducing CD Macro-states to SOSJ
4.2 CD and Subsystem Configuration in SOSJ
4.3 CD Macro-state Transitions Due to Dynamic Behaviours
4.4 Concluding Remarks
5 SOA Implementation in SOSJ
5.1 SOSJ Global Service Registry
5.2 SOA RTS
5.3 Concluding Remarks
6 Dynamic Behaviour Handling in SOSJ
6.1 Dynamic RTS Design and Architecture
6.2 Dynamic RTS Implementation
6.3 Concluding Remarks
7 Results and Discussions
7.1 Comparison in Satisfying the Design and Programming Requirements of DISS
7.2 Experimental Results: SOA Handling of SOSJ
7.3 Experimental Results: Dynamic Behaviour Handling of SOSJ
7.4 Quantitative Comparisons
7.5 Concluding Remarks
8 Conclusions
8.1 Overview
8.2 Main Contributions
8.3 Future Works
GET THE COMPLETE PROJECT
Contributions Towards Dynamic Intelligent Software Systems
