A software modelling methodology provides a systematic approach with relevant guidelines, principles, and models to help the developer analyse an application do-main and requirements, and to lead to system design and development. A develop-ment life cycle is associated with the methodology consisting of the various stages, activities and processes for system modelling. It also specifies the deliverables or models that should be produced at each specific stage of the development life cy-cle. This provides a matrix against which to measure deliverables to ensure that the project is on track and that software quality can be met. The process of modelling normally starts with an abstract or logical view of the system in order to capture its essence. The content of the model can be enriched by adding more detailed and con-crete elements and processes. As the development process continues, along with the progressing of life cycle, more detailed specifications for implementation should be revealed and designed. At the end, the conceptual system can be realised by using suitable technologies and can be deployed.
Unlike OO which has a mature standard modelling language and related meth-ods, UML, to support system analysis and design, there are currently no well recognised systematic methodologies for the analysis and design of agent-oriented and service-oriented software systems. However, a handful of agent modelling ap-proaches have been proposed and adopted by researchers to develop agent-based applications.
1.4.1 Agent Modelling Methodologies
Existing methodologies for modelling agent-oriented systems originate from either knowledge engineering techniques or object-oriented modelling methods [3]. The Belief-Desire-Intention (BDI) architecture is an approach to modelling the inter-nal states of an agent in terms of three main elements—beliefs, desires and inten-tions [30]. Beliefs represent an agent’s beliefs about the world (including the agent itself and others). Desires are a set of possible goals the agent wishes to achieve.
Intentions are commitments to goals, typically in the form of intermediate goals associated with plans that the agent has selected to perform. The benefit of this method is that it provides a systematic coherent approach from modelling logical mental states to realising BDI agents. JACK agents, a commercial tool to support intelligent agent development, is based on this approach. The authors also proposed the AAII methodology to model an agent’s interaction rules with other external agents [31].
Gaia [38] is an agent-oriented analysis and design methodology for modelling both the macro-level (societal) and the micro-level (agent) aspects of agent based systems. The approach supports a number of models for each stage (analysis and design) to capture concepts from abstract to concrete levels. The whole development is an iterative process to ensure that the system has been modelled appropriately. At the analysis stage, a prototypical role and interaction model which includes key roles and the interactions between the roles in the system is identified. The outcome of the analysis is a comprehensive roles model which details the information about the key roles, interaction protocols and activities. The design stage in Gaia is to create an agent model by grouping the roles identified in the previous step into agent types and to define their relationships. The next step is to develop a service model to include essential functions to support agent’s roles and activities. The final step is to develop an acquaintance model from the interaction model and agent model. After the completion of these stages, the specifications for an agent system are ready for implementation.
In Gaia, the purpose of an agent possessing a service model is to describe and support its capabilities. An agent has a collection of services that correspond to the functions required by the agent to play its role in a given environment or organi-sation. The activities identified at the analysis stage relate to the roles through the corresponding services. Each role will be supported by at least one service. The services that are allocated to one agent are not directly accessible to other agents.
In other words, one agent cannot directly invoke the other agent’s operations (re-gardless of implementation platform, for example even if web services were used).
The Gaia service model focuses on modelling concrete concepts, and so the issue of service implementation is not addressed [16]. For each service it is necessary to document its properties such as its required input and output as well as constraints such as pre-conditions, and post-conditions.
1.4.2 SOA Modelling Methodologies
Arsanjani proposed a service-oriented modelling approach with seven layers for the development of services [1]. The approach consists of modelling, analysis, de-sign techniques, and activities to define the foundations of a SOA. The main task of service identification is to use top-down, bottom-up, and middle-out techniques to analyse the application domain and to decompose the domain into manageable subsystems for service identification. After the required services have been identi-fied, the relationships between these services need to be recognised and drawn up as a hierarchical structure, so that the composite and atomic services can be deter-mined. The activity in the subsystem analysis specifies the interdependencies and flow between the subsystems. Once the subsystems have been specified, services can be assigned to these subsystems. Prior to doing this, the component that imple-ments the services must be documented. The final step is to realise the services by selection or custom building. Other options that are available include integration, transformation, subscription and the outsourcing of parts of the functionality using web services.
The SOA foundation life cycle is another means to guide service develop-ment [17]. The SOA life cycle consists of four main phases: modelling, assembly, deployment, and management. Another important process is governance to manage the whole process for quality of service. During the modelling phase of the service life cycle the main task is to identify candidate services and their possible interac-tions based on the result of a requirements analysis and an analysis of the business process. Modelling functions that meet the required business objectives in the form of services is another important task. The resulting model is designed and simulated in order to test whether the system has met the requirements or not. In the assem-bly phase the developers locate the available services which can be composed to produce the designated functions. If the required functions cannot be satisfied with the services in the repository, then constructing new services is necessary. Service testing before the composition takes place is an essential task to ensure system de-pendability. In this phase, the policies for governing the service interactions need to be determined. When the system is ready for deployment, the deployers need to configure the system for the real runtime environment. Other related roles such as IT system managers and end users etc. have to be involved to integrate business processes and information to eliminate any possible barriers. The deployed services
must be managed and monitored to ensure that there are no abnormal behaviours and that they comply with non-functional QoS requirements.
1.4.3 Agents and Services
W3C states that “A web service is an abstract notion that must be implemented by a concrete agent. The agent is the concrete piece of software or hardware that sends and receives messages, while the service is the resource characterised by the abstract set of functionality that is provided” [5]. This means that a web service can be implemented by one agent and that this agent can be replaced with another, provided that the service still provides the same functionality. For example, suppose that a Google agent, that includes a Google search engine and related index database, can retrieve the required information for requests and that a Yahoo agent has a similar search capability, but it is associated with the Yahoo search engine and database.
An Internet search service can be implemented using the Google agent to search over the Internet, but the service can change its underlying agent from the Google agent to the Yahoo agent. The service still has the same functionality for internet search, but the results searched by these two agents may be different and the QoS offered by these two agents could vary. Therefore, the Service Level Agreement (SLA) between service consumers and providers becomes an important instrument for SOAs [32]. The service can select appropriate agents to honour its described functions and promised QoS based on a SLA.
Agents might also be autonomous and able to deliberate to plan and fulfil the goal (tasks) a service assigns to it. A composite service is a collection of services that contain a group of agents. The agents will not communicate with each other directly, but through the associated service interfaces. If an Agent Communication Language (ACL) is the only communication mechanism for agents, then the com-munication between service and agent and between services will be messages that contain the ACL. A workflow will prescribe the relationships at runtime not only between services, but also between agents. A discovery and selection service could include a service discovery and selection agent to automate the service discovery and selection process. In this approach, an agent is wrapped by a service. The is-sue of coordinating heterogeneous agents could be alleviated, as services will be the only interface for service consumers to interact with, and so the standard web services architecture is applicable.
The Gaia methodology takes a very different approach from the W3C web ser-vice architecture to define the relationship between agents and serser-vices. The serser-vices in the Gaia service model are designed to realise the agents role. Services are one of the main building blocks to equip an agent with functions. In other words, a service is part of an agent and it can be one of the activities that an agent is able to carry out.
An agent has control over the services and their interactions. In this model, an agent can adopt SOA standards to tackle issues such as non-functional QoS requirements, governance, and dependability etc., to which the community pays little attention but
are important factors for business and engineering applications. We further discuss the standards issue later in this chapter. The agent can also select relevant services to not only produce the required functions, but also meet QoS requirements.