In the following subsections we review the main standards for agents and services.
1.6.1 Foundation for Intelligent Physical Agents (FIPA)
Unlike the web services architecture, software agents only have a small number of standard specifications. The most widely accepted specifications e.g. agent manage-ment and the Agent Communication Language have been developed by FIPA, the Foundation for Intelligent Physical Agents (http://www.fipa.org/), which includes several academic institutions and industrial partners. The aim of the organisation is to develop and agree standards for heterogeneous interacting agents and agent-based systems by defining a full set of standards for both implementing systems within which agents could execute (agent platforms) and for how agents themselves should communicate and interact. FIPA was founded in 1996, but despite its popu-larity in the late 1990s and early 2000s, it never succeeded in gaining the commer-cial support which was originally envisaged. In 2005, an IEEE standards committee was set up to take over from FIPA. AUML, the Agent Unified Modelling Language (http://www.auml.org/) is a standardised modelling language proposed by FIPA and OMG to capture agent concepts and their interactions.
1.6.2 SOA and Web Service Architecture Standards
Four main standards organisations, W3C, OASIS, OMG, and Open Group, have had extensive involvement in specifying SOAs and web services. The working groups in W3C mainly focus on web service family standards, which have been impor-tant specifications in building enabling technologies for the realisation of SOAs.
Open Standards working groups, technical committees, and special interest groups in OASIS, OMG and Open Group also have significant interest in specifying SOA standards. The following is an illustrative list of the standards that have been pro-posed.
• The OASIS Reference Model for SOA [23].
• The Open Group SOA Ontology [26].
• The OMG SOA Modeling Language (OMG SoaML) [25].
• The OASIS Reference Architecture for SOA Foundation [24].
• The Open Group SOA Reference Architecture [29].
• The Open Group Service Integration Maturity Model (OSIMM) [28].
• The Open Group SOA Governance Framework [27].
The SOA reference model and ontology are specified to understand and cap-ture the core concepts within a domain and describe the relationships between these core concepts. OMG SoaML, which is based on UML with extended notations, is designed to have enabling capabilities in service modelling. The Open Group SOA Reference Architecture and the OASIS Reference Architecture for SOA Foundation both intend to provide guidelines to support other architectures in the standards, and assist architects in the modelling and decision making processes [19]. The Open Group Service Integration Maturity Model (OSIMM) is to assist organisations that
adopt SOA solutions in their businesses in assessing the maturity within a complete SOA migration path. The SOA Governance Framework assumes that an organisa-tion already has its own governance model in place. The framework provides mod-els to help organisations define and customise their own focused SOA Governance model.
The variety of standard specifications associated with web services, “WS-*”, re-flect services captured as different perspectives of the same subject for different pur-poses and applications. Various standards bodies and industry companies have par-ticipated in proposing and specifying standards to realise SOA applications. These provide SOA developers with various choices to facilitate service interoperability at various levels and aspects. These standards, however, with varying degrees of maturity may complement, contradict or compete with each other. For example, IBM and Microsoft adopt WS-* for transaction specification, but IBM proposes the WS-BPEL extension for people, which Microsoft did not contribute to or adopt.
In addition, most WS-* specifications are still evolving, and so a change of the specifications is likely take place in the future. Figure 1.1 shows an example of the WS-Policy and its relation to other specifications which utilise the specifications to define their own related policy [11].
WS-Metadata
Fig. 1.1 WS-policy with other WS specifications
SOA and WS-Architecture have gained great support from industry, standard or-ganisations, and academia, and a number of interest groups have been formed to propose and specify open standards. These standards offer guidelines in their re-spective areas to facilitate system interoperability for service-oriented applications built upon different development platforms to allow them to interact, if they com-ply with the standards. Some of these are designed to support each other to bring technological compatibility. In contrast, the agent community has a relatively small number of standardised specifications. Interoperability among heterogeneous agents using different technologies can be an issue. For example, two agents may try and
cooperate, but they may adopt different coordination approaches. These two agents fail to cooperate, due to the lack of a standardised coordination approach. The large number of evolving standards for SOA and WS-*, however, might also be problem-atic, since only large software vendors can afford to support all of these standards.
This could exclude small software vendors, as they may find it difficult to contribute and participate. In addition, some of the specifications might prove too complex and too detailed. The adoption of the full specifications becomes unnecessary for small applications, as some of the features may not be required. Standards help to bridge gaps between diverse technologies and help to advance the technology, but proof of concept for these standards can be very costly. From the above, one might even try to argue that standardisation can bring more harm than good. However, we do not believe that this is the case, since standards make interoperability among distributed systems possible. The benefits of the SOA and WS-family specifications have be-come evident as the number of applications adopting these standards have increased significantly. Some of the standards for SOAs might also be useful for agent-based service-oriented applications, for example, if developers adopted the Gaia service model to develop the agents functions.