Accountability in Enterprise Mashup Services

As a result of the proliferation of Web 2.0 style web sites, the practice of mashup services has become increasingly popular in the web development community. While mashup services bring �exibility and speed in delivering new valuable services to consumers, the issue of accountability associated with the mashup practice remains largely ignored by the industry. Furthermore, realizing the great bene�ts ofmashup services, industry leaders are eagerly pushing these solutions into the enterprise arena. Although enterprise mashup services hold great promise in delivering a �exible SOA solution in a business context, the lack of accountability in current mashup solutions may render this ineffective in the enterprise environment.is paper de�nes accountability for mashup services, analyses the underlying issues in practice, and �nally proposes a framework and ontology to model accountability. is model may then be used to develop effective accountability solutions for mashup environments. Compared to the traditional method of using QoS or SLA monitoring to address accountability requirements, our approach addresses more fundamental aspects of accountability speci�cation to facilitate machine interpretability and therefore enabling automation in monitoring.


Introduction
e recent and rapid expansion of Web 2.0 has considerably placed pressure upon industry to institutionalize new technologies and conform to emerging standards.While agreement on the scope of the term Web 2.0 does vary, O�Reilly provides a commonly accepted de�nition, noting this to include a range of enhanced services including web services, wikis, blogging, BitTorrents, and syndication [1].
e rapid growth of Web 2.0 has also introduced a number of new design patterns and architectural styles in web development.One of the notable techniques involves mashing up information from existing services to deliver new value-added services.is process effectively involves the drawing of content from several sources to create a new content or service.e resulting web page is then referred to as a mashup of the existing content.
While mashup services bring �exibility and speed in delivering new valuable services to consumers, the legal implications of using this technology are signi�cant.Researchers in law conclude that the development of mashup services is fraught with potential legal liabilities that require careful consideration [2].
e issue of accountability associated with the mashup practice remains largely ignored by the industry.Current formal practices suggest that the mashup developer and original content source owner disclaim any warranties [2].is appears to be temporarily acceptable since most services from Web 2.0 sites are free to internet users.is means that as long as consumers accept the terms and conditions, the issue of accountability is largely avoided.Notwithstanding, as these services mature to involve some payment, such an approach may no longer be tenable to all parties.
Traditionally, accountability implies that an entity has an obligation for the execution of authority and/or the ful�lment of responsibility [3].Nonrepudiation of transaction is also a major requirement for a service requester and a service provider.However, in a mashup service scenario, the issue of accountability is more complicated.Firstly, there may be several implicit service providers involved due to the fact that the service is mashed up from a number of sources.Secondly, the content presented may not be delivered by the content (1) e underlying mashup accountability issues in practice are analysed with a formal de�nition for accountability in mashup solutions provided.
(2) A framework and ontology are proposed to model accountability in mashup environments.
(3) An implementation scenario is outlined that applies these methods in practice.
Using these methods, it is hoped that more effective accountability solutions can be prepared on the basis of our framework and model.e remainder of this paper is structured as follows.Section 2 provides background information on the mashup paradigm and related work in the current literature in accountability.In Section 3 we suggest a de�nition for accountability to address the additional requirements of mashup services.is is followed by a framework and ontology that may be used to model accountability.In Section 5, we illustrate how the framework and ontology can be applied in an implementation scenario.Finally, we summarize our results and observations, discussing areas of further work.

Related Work
2.1.Overview of Mashup Services.e term mashup originates from the practice of mixing song samples from two or more sources to produce a new sound track.In the context of the Internet, mashups are websites or applications that combine content from more than one source into an integrated application.is is generally achieved by using third party content provider application programming interfaces (APIs) or open technologies, for instance, Ajax and PHP, and syndicated feeds such as RSS or ATOM.In addition, since the content may be obtained from several sources, intermediate businesses have emerged that act as content brokers.ese intermediaries provide access to several content sources from 3rd parties and also supply functions to support the mashup process.
Based on the concept of service composition in Service-Oriented Architecture (SOA), mashup provides �exible and dynamic services with rich experience.is technology also enables a dynamic form of service reusability in contrast to the traditional method of static "cut and paste" reusability.However, since mashup involves the aggregation of another party's content into some new service or application, a number of legal issues are introduced [2].When legal issues arise, accountability will become the critical concern for the parties involved.
Figure 1 illustrates the fundamental concepts in Web 2.0 mashups, where data and content are drawn from a range of sources to produce a new aggregated content or service.For example, the content may be drawn from local data repositories, from existing local and external web pages, accessed via SOA-based APIs, and from intermediate content brokers.
While mashup applications and services are growing at a rapid rate, currently they appear to be applied in nonmission critical services and are offered to the internet consumer largely as free services.In practice, legal responsibilities are generally avoided by the content provider disclaiming all warranties and liabilities [2].
More recently, industry leaders are accepting mashup as an enterprise tool to enable the creation of so-called situational applications.ese types of applications solve business problems such as inventory management, sales, and marketing information management [6].is emerging approach has been termed "enterprise mashup" and several enterprise tools have been released [7].Enterprise mashup may be viewed as a Web 2.0 technology that builds upon the �exibility offered by SOA, and having a requirement for increased security.
Although enterprise mashup services hold great promise in delivering a �exible SOA solution in a business context, the lack of accountability in current mashup solutions may render this ineffective in the business environment.As such, as more enterprises embrace this technology in building IT solutions, the issue of accountability will manifest as a key concern for the service stakeholders.

Related Work on
Accountability.e meaning of the term accountability appears to vary considerably and is dependant upon the context.Traditionally the topic of accountability has attracted much interest with focus on the eCommerce transaction.According to Kailar, accountability is "the property whereby the association of a unique originator with an object or action can be proved to a third party" [8].e de�nition implies nonrepudiation in an eCommerce transaction.Kailar also proposes a framework for the analysis of communication protocols that require accountability [8,9].
Bhattacharya and Paul assert that while a digital signature can provide help in enabling accountability in two direct communication nodes, it cannot fully address the accountability issues in multihop message due to the sender's ambiguity problem [10].
In [11], the scope of accountability is broadened to represent the ownership of the responsibility to meet requirements in an end-to-end business process.e authors propose "Accountability Centered Approach" (ACA) for business process engineering.e ACA approach suggests iterative decomposition of accountability to appropriate levels and mapping of subaccountabilities into activities.
A 3D approach in accountability modelling (detect, diagnose, and defuse) is proposed in [12] to discover and eliminate the root cause of problems when violations of service level agreement occur in business processes.e approach adopts Bayesian network reasoning for root cause analysis and service reputation model to address problematic web services.
While existing research on accountability helps traditional eCommerce application and SOA business applications, the issue of accountability in service mashup has not been treated in the literature.In addition, Gerber reviews the implications of using mashups and points out a number of legal issues [2].is includes copyright misuse, trademark violations, false advertising, contract law issues, patent infringement, warranty, and the rights and privacy of individuals.e author also observes that these legal issues require consideration prior to design or implementation of mashup applications.ese issues further motivate the need to address accountability for enterprise mashup services.
Eriksén comprehensively explores the notion of accountability for information and communication technologies [13].e author cites a general de�nition of the term accountability as follows: "responsible for giving an account (as of one's acts), answerable, " or "capable of being accounted for" [13,14].From the analysis of three key articles, the author observes that a common theme prevails in soware engineering, which is the characteristic of "making visible and accountable, " and also poses the question of "accountability for whom?" ese observations further support the notion that accountability for mashup service has a requirement to disclose roles, responsibilities, and current transaction state.Furthermore, Johnson and Mulvey analyze relationships and responsibilities outside the developed IT systems [15].ey focus upon the accountability of system designers with respect to clients, users, and those affected by decision systems, prompting the question "are system designers responsible for the outcomes that result from use of their systems?"Our work addresses visibility through disclosure and identi�es for whom the accountability is intended for, with de�ned roles.In addition, the responsibility aspect is also treated as a key element that requires consideration in accountability.
In [3], it is suggested that the term "accountability" is an oen used word with no common de�nition that can be found.e special interest group authors [3] also conduct extensive research of the literature and have provided a de�nition of accountability in the context of service performance, see Box 1.
We observe that this de�nition requires strengthening in the multiparty scenario such as mashup service environments.In addition to nonrepudiation, managing trust is also important for entities to collaborate [16].Moreover, we wish to strengthen this de�nition with nonrepudiation and trust with one or multiple entities.
In moving towards a de�nition, we �rst propose that the essence of accountability involves four elements from an IT perspective, refer to Figure 2. In the original de�nition of Box 1 a person, group, or organisation can be translated to the concept of identity, whereas execution of authority implies the concept of role.According to Certo, responsibility is an obligation that someone "accepts" and is not allowed to delegate or pass on to someone else [17].Accepting implies that there is some form of agreement in place."Answering" and "reporting" relate to disclosure.Assuming liability for results requires a way to clearly demonstrate who has done what.e term assuming liability may be viewed as ambiguous, and considering that trust may vary considerably in a multiparty environment, this needs to be strengthened in order to remove plausible deniability, (i.e., introducing nonrepudiation).e elements of Figure 2 involve the identity of the involved party, the role the party plays, and the agreed responsibilities in the form of contract, agreement, or signedoff requirements.e last element is the performance outcome, the evidence of who has done what.
We now use a mashup example to demonstrate these accountability elements, see Table 1.In the scenario, Entity B offers a security trading platform to allow their customers to trade various securities globally.It has contracts with different real-time �nancial data providers to provide price data, which is fed into a charting application provided by a service provider to produce price charts.For a particular trading transaction, customer Alice initiates the trade request with Entity B. is is based on the pricing chart provided by Entity C's charting service, with real-time price input from Entity D. Using this IT services example, properties of accountability also imply the following: Accountability refers to the obligation a person, group, or organization assumes for the execution of authority and�or the ful�llment of responsibility.is obligation includes the following: (i) answering�providing an explanation or justi�cation�for the execution of that authority and�or ful�llment of that responsibility, (ii) reporting on the results of that execution and�or ful�llment, and (iii) assuming liability for those results.
B 1: Accountability for performance.
T 1: Accountability roles in practice.(i) clear disclosure of the roles, responsibilities, and transaction status by all parties;

Identity
(ii) each party dutifully carry out their obligations; (iii) there exists readily available evidence of the services rendered; (iv) the involved parties cannot repudiate services rendered.
ese properties reenforce the need for trust and nonrepudiation.However, in a legal sense, an automated IT system is not a legal entity that is accountable.Rather, it is the person, group of people, or company which is legally accountable.In the context of multiple entities involved in a mashup service, we now provide a more formal de�nition for accountability by extending the de�nition in [3].
In [3], responsibility is the obligation to perform, while accountability is the liability that one assumes for ensuring that an obligation to perform is ful�lled [3,18].In addition, the term authority is the right to act without prior approval from higher management and without challenge from managing peers [3,18].e authors point out that authority is assigned, while responsibility is delegated.is implies a top-down decomposition of authority.Given the bottomup method of building mashup services, this de�nition may not strictly apply.Rather, responsibility and authority must be sought and agreed upon between all peer content or service providers, rather than delegated.As pointed out in [17], responsibility is an obligation that is accepted; hence we observe that agreement should be sought.Finally, trust may be established among peers through evidence based on historical behavior and past interactions [16].Considering these points, we outline the extended de�nition, by strengthening the de�nition with multiparty trust and nonrepudiation, making this binding to several parties, see Box 2. is de�nition is applicable to both the multiparty service environment (such as mashup) as well as the single party service provider.�e also note that the last point of this de�nition uses the term trusted which also implies that all entities are authenticated.Hence, the accountable service provider would naturally maintain some form of a binding registrar that identi�es the subordinate accountabilities present.In order to satisfy this, the approach in [11] would seem to naturally satisfy this condition.In light of the example and the objective to strengthen the term accountability for the broader context of multiple parties, we observe these additional properties.
(i) Trust: authentication of identities and agreement of accountability between all entities with evidence of behavior.(ii) Nonrepudiation: undeniable liability with full disclosure (evidence).

Service Accountability Framework
Building upon the de�nitions in this previous section, we now propose a framework, as a metamodel and ontology, for modeling solutions in accountability for the mashup domain.
Accountability in services refers to the obligation that several persons, groups, or organi�ations assume for the execution and ful�llment of a service.is obligation includes: (i) Answering, providing an explanation or �usti�cation, for the execution of that authority and�or ful�lment of that responsibility; (ii) Full disclosure on the results of that execution and�or ful�llment; (iii) Undeniable liability for those result (non-repudiation); and (iv) Obtaining trusted agreement of accountability from all entities involved in the service, who in turn are bound to the obligations set out above.
B 2: Accountability for multiple parties.
e metamodel focuses upon the roles and responsibilities from an information systems perspective and is intended for IT developers.e ontology focuses upon the liabilities and agreements aspect of the de�nition which is useful to establish the contractual terms and de�nition between the respective parties.e current literature in IT has placed much focus on the identity and performance outcome elements, which are the most difficult issues to address as that involves trust and nonrepudiation.Security frameworks such as PKI alone cannot address the issues of trust in this computing environment, rather a robust security process framework and security protocol are necessary [19,20].As pointed out in [10], digital signatures by themself do not solve the nonrepudiation issue in a multiple party environment due to the sender ambiguity problem (i.e., a party can deny receiving a message by accusing the nonperformance of the intermediary node).
While the identity and performance outcome are essential elements in the accountability framework, the role and responsibility elements are equally important.In fact, we argue that disclosure on the role and responsibility elements is the �rst step towards an accountability solution.is is because without a clear understanding of the roles and responsibilities by each involved party, the outcome and entity accountable can be disputed.
In a mashup service scenario, the service requester may send a request to a mashup service provider, who in turn forwards the request to the source service provider(s), before aggregating this into a new form for presentation.e issue to observe is that the original service requester may not know the identity of the original service providers.On the other hand, the original service provider is also not aware how their content may be used by the mashup service provider.is motivates the need to �nd an approach to enable disclosure of roles and responsibilities in mashup services, especially for the enterprise mashup services environment, that are mutually acceptable to all parties involved, whether directly or indirectly.For instance, source content providers may have restrictions on how their content may or may not be used.
We propose a framework for modeling the behavior of mashup services based on SOA and hence brie�y visit the fundamentals of this archetype.It is commonly agreed that SOA is an architectural style that involves a triangular relationship amongst three entities: service requester, service provider, and the service registry [21,22], see Figure 3.While the model captures the essence of the serviceoriented architectural model, it may fall short on enabling accountability in service-oriented architectures in the mashup service environment.For instance, this does not address the roles of multiple parties and the associated responsibility of disclosure and nonrepudiation.
In a mashup context, it is important to note that there are multiple service providers involved.ere is also the introduction of service source as a separate entity to the provider, although, in some cases the service provider is the same entity as the service source.In practice, the service provider may engage several external content source parties to participate in constructing the service.In this situation, the service provider relies upon the source for accuracies of supplied content.As suggested in [2], there are a number of legal issues that need to be considered prior to developing mashup applications.As such, both the service provider and source are required to assume responsibility to ensure that the mashup service complies with the intended application (and de�ned terms and conditions).
Disclosure of roles and responsibility, to a large extent, can be enabled by rich service metadata and facilitated by functions provided by the service broker; rich service metadata means adding semantics to allow machine interpretation and reasoning.Currently, the registry (UDDI) provides service metadata in terms of business entities, taxonomy, and reference to service information.e registry is a dynamic name binding service that is syntax based [23].�owever, in mashup several sources require identi�cation and these may need to be trusted sources in an accountability sense.We wish to enable semantic meaning, as in OWL-S [23], and suggest a more sophisticated role to facilitate trust by enabling richer metadata to capture aspects such as traceability of service composition and responsibilities for several parties.Using this extended metadata, the service request may be appropriately associated with source content that addresses both the requirement for content and the need for accountability.In some cases, untrusted content will suffice; in other situations such as enterprise mashup full accountability will be necessary.

Roles and Responsibilities Metamodel.
Based upon the previous discussions, we argue that the two identi�ed roles, service requester and service provider, do not adequately represent all the roles involved in mashup service interactions.
We now propose a model to depict these relationships.e revised model is shown in Figure 4. is is composed of the additional roles: service source and service broker.e service registry is still implied in this model, residing with the service broker.Note that the service provider is a special type of role in the mashup environment which plays as both the requester and provider at the same time.e service provider will draw upon several internal and external sources and provide a resultant mashup page to the service requester.When sourcing content from a broker or service source, the provider acts as the requester.e service source publishes a single or discrete set of (common) content sources that may be accessed directly by the service requester or can be built upon and merged with other content source by a mashup service provider.
As pointed out in [2], new intermediary businesses have emerged that aggregate and broker content from several sources, in essence becoming a one stop shop of various content sources for mashup service providers.e broker supplies content to a service provider who is in turn able to mashup and repurpose the content for a service requester.is means that the service requester may discover services from the broker and invoke this from a service provider.Both the service source and broker publish their available services.
e service broker provides several additional bene�ts: as a trusted brokering agent (notary for unknown sources), monitoring (audit trail and evidence) to address the disclosure and nonrepudiation requirements, rating functions, and managing a combined registry and repository for multiple sources.�ence, the service broker role can be further re�ned into detailed roles based on these intermediary functions performed, see Figure 5. e service requester in SOA does not necessarily imply that the entity is a user.is actually refers to the client of the service, which may be another application service or soware agent.In an enterprise environment, the participant role in SOA normally represents an organization or party.
e enhanced role interaction model caters for both mashup and traditional service oriented architectures.is helps to understand and de�ne the roles and responsibilities in service metadata.us the involved parties and their roles and responsibilities can be discovered and interpreted at runtime and therefore achieve the purpose of disclosure.is model is useful to information systems developers, helping them to identify roles (entities) and responsibilities in an accountable mashup services solution.

Liabilities and Obligations
Ontology.e previous section focused on the roles and responsibilities in a mashup environment, outlining a model from an information systems perspective.is section models the liabilities and obligations from a legal and contractual perspective.is will assist in preparing the engagement basis and contract documents, by identifying the legal entities and artifacts that require consideration when preparing agreements to ensure accountability.
e proposed high-level accountability ontology is illustrated in Figure 6.In this ontology framework, a person or organization is a legal entity that has an identity.A legal entity enters into agreement with other legal entities.e agreement embodies rights and obligations.Rights entail considerations and also imply entitlement for damage if considerations are not met.e obligation sets out the requirements that need to be delivered and penalties if the requirements are not met.
Assigned with the required authority, the legal entity (Figure 6) takes some role, which executes tasks to deliver the requirements.In the context of accountability, the task class has two subclasses, one is service task which provides the intended service; the other is the accountability task which includes disclosure of authority, outcome, and evidence.
OWL-S is the commonly accepted web services ontology language that provides a core set of markup language constructs to describe web service in an unambiguous, machine interpretable form [24]. us it will be a natural approach to use those constructs to de�ne the accountability elements in the service metadata.Using the general accountability model in Figure 6, we combine the high level service property constructs from OWL-S [4,23] (service class and then its property classes: service pro�le, service model, and service grounding) to address the mashup environment.e extended accountability ontology framework is thus illustrated in Figure 7.
In the context of enterprise mashup environment, a legal entity enters into an agreement with other legal entities in order to participate in a service arrangement through web service interactions.e agreement enables the legal entity to assume a speci�c web service role to ful�ll the obligations while receiving the considerations.As illustrated in Figure 4, the speci�c web service role can be service requester, service source, service provider, and service broker.is role will carry out tasks to deliver the requirements setout within the obligations.e role performs a task which has two aspects: one is the normal web service and the other is the accountability task.e accountability task includes disclosure and reporting.Disclosure in this context means disclosure of service metadata, providing evidence of the service outcome.Service metadata may include identities of the involved legal entities, roles that they play, reference to the service agreement, and reference to the original content in the case of mashup service.Service agreement includes terms and conditions of the service.

Implementation Scenario
In this section, we demonstrate how to apply the accountability framework and ontology during the development lifecycle of a mashup solution.e example scenario involves a travel agent intending to develop a website that provides travel booking services to online customers.e site will mash up mapping data from a 3rd party together with travel location information in order to present tour routes and destinations on a consolidated map.e metamodel will assist during the soware development lifecycle in identifying the roles and responsibilities.e ontology will assist in the preparation of contracts and agreements between the various entities.

Roles and Responsibilities in Solution Development.
A customer accessing the website is able to select a desired travel plan and con�rm a booking.e site will automatically book the air tickets and hotels through the mashed-up APIs provided by independent external airline and hotel businesses.Finally, the solution will also include an electronic commerce transaction to accept payments.Figure 8 illustrates the source and method by which these individual services are pulled together to produce an enterprise mashup service.e �rst step in the analysis is to identify the roles and responsibilities associated with each participating entity in the mashup service.During architecture and design, these roles and responsibilities are expanded and mapped to design components, which are subsequently implemented in soware.ese lifecycle phases are now described.

Requirement Gathering: Allocating Roles and Responsibilities.
Using the roles and responsibilities metamodels from Figures 4 and 5, the mashup service environment is systematically analy�ed to identify the speci�c roles, responsibilities, and expected outcomes for each entity participating in the solution.We conduct an analysis on the service requester, in this case a customer as an example (in other scenarios this may be another external entity).
e service requester has a service invocation relationship with the service provider and indirectly with the service source (3rd party provider).In this example, there is no need for additional discovery interaction with the service broker as this is managed by the service provider on behalf of the service requester.Based on these interactions, it is necessary for the service requester to supply correct personal information to reserve a booking and ensure that sufficient funds are available to complete the initial transaction booking.Using the metamodel, a similar analysis is conducted for the remaining entities in this scenario.is process will yield an initial high-level accountability model.e completed analysis is shown in Table 2.  (ii) Ensure integrity of the service source.is implies ful�llment of the requirements in the terms and conditions of the service source, ensuring the service providers' copyright and trademarks are not breached.

Solution
(iii) Service source's reputation is tracked and measured against the agreed quality of the services.
(iv) Provide tamper proof evidences on service transactions upon request.
designers will make during architecture and design revolve around what to leverage from in-house capability, versus what is provided by external service brokers.We analyze this perspective.
Considering the expanded roles and responsibilities the metamodel (Figure 5) highlights the various service broker roles that provide a different accountability capability.For instance, the travel agent is able to use a rating agent to evaluate and track the reputation of the service source.Alternatively, it may engage an external service dynamically to perform this task, reducing the technical complexity of the solution for the travel.is also implies that it will be necessary for service brokers to provide certain accountability capabilities.
Using the initial high-level roles and responsibility iden-ti�ed in Table 2, we now illustrate the expanded accountability requirements for each interaction scenario (Table 3) to address the issues of trust, integrity, disclosure, and nonrepudiation.

Solution Implementation.
In the following, we assume the use of a modeling tool such as the control case [25] to capture and expand the accountability requirements listed in Tables 2 and 3. is may then be machine interpreted during solution implementation.
Broadly speaking, there are two categories of requirements identi�ed in Table 3. e �rst consists of the obligations that form part of the agreement between the different parties.e second category consists of policies that one entity must comply with in order to consume the service provided by the other party.Examples of the �rst category of requirements are the terms and conditions of the mapping service source, quality of service (QoS) in service level agreements (SLA), and the travel agent's obligation to provide a booking receipt to the customer upon booking con�rming.Together with the ontology, these are used to prepare agreements (see Section 5.2).Conversely, ePayment requirements for an authentication scheme, encryption technologies, and digital signature protocols are examples of the second category of requirements.[26] may be used to specify the �rst category of requirements while WS-Policy framework may be used to specify the second category of requirements.ese speci�cations are designed to enable a service provider to advertise the capabilities that form the basis of an agreement.WS-Agreement also enables a requester to negotiate an agreement with the service for a speci�ed duration� furthermore the agreement can be monitored for compliance in runtime [27].An example of XML source output of the WS-Agreement for the travel agent's obligation of providing booking receipt is shown in Algorithm 1.

WS-Agreement
e second category of requirements can generally be expressed in a domain speci�c policy assertion language and may be attached to the service endpoint through the WS-Policy framework.Algorithm 2 is an example of the ePayment requirements for authentication, encryption and digital signature speci�ed using WS-Policy.

Preparing Agreements for Accountability.
We now describe how the ontology may be used to assist in the preparation and negotiation of contracts and agreements between the various entities involved in the travel agent mashup website project.Some key artifacts include the statement of work (SOW) signed between the travel agent and the IT project delivery team and several agreements between the travel agent and external parties acting as a service or content sources.Moreover, the SOW determines the functionality to be provided by the website, the roles, and responsibility for delivering those capabilities and thus sets the basis for all other contracts.

Traditional versus Mashup Agreements.
Differing from the traditional IT projects, the mashup project presents extra complexity in the area of accountability.e general accountability ontology de�ned in Figure 6 and the mashup accountability ontology de�ned in Figure 7 can assist the project team to prepare an SOW that suitably addresses the accountability issue by identifying accountability elements such as entities, roles, responsibilities, and expected outcome in the service arrangement.One important observation to make is that the ontology outlines the need for accountability tasks associated with each service task.e accountability tasks include disclosing authorities, keeping evidences of the service, and reporting service outcome.In this way, the accountability tasks can be categorized as a form of nonfunctional requirements in IT terms, which can then be re�ected in the work breakdown structure, service level agreements, pricing, and the service contract with service source or service broker.
A further observation is that the ontology highlights the multiple roles involved in delivering the web services.is means that an SOW for a mashup solution will differ from the traditional SOW.In general, the traditional SOW is only required to specify roles and responsibilities of two parties, the project owner and the client (contracts with subcontractors are addressed by additional SOWs).is tenet is supported by �artin, who de�nes an SOW as "a narrative description of the products and services to be supplied to the client and the needs and requirements of the contractor to deliver such products and services properly under the contract" [28].However, in a mashup case, the SOW de�nition needs to be broadened to include the roles and responsibilities of all the involved parties including the client, contractor who develops the website, and various service sources.is is because the product and services of the mashup site are not supplied by a single party, rather, by several entities in realtime.

Identifying and Enforcing
Accountability.Involved parties are able to apply the ontology to facilitate discovery of accountability statements and clauses.For example, when specifying the hotel booking service within an SOW, based on the ontology in Figure 7, the analyst knows that the hotel operator assumes the web service source role, who performs a service task through a hotel booking web service.A web service has service grounding (information for accessing the service), service process (service logic) and a service pro�le (service descriptions and service effect).As each service task has associated accountability task, example of accountability statements for the hotel operator could be de�ned as follows.
(i) Hotel operator is accountable for disclosing the booking service effect and service description metadata that is necessary to locate and access the web service.
(ii) Hotel operator is accountable for providing evidence of the service rendered upon request from the travel agent.
e supplied evidence may be tamper-proof audit trails, service level agreement (SLA) monitoring records, or digitally signed messages.e content and format of the evidence is to be clearly de�ned in the SOW or in the detailed technical design document referenced by the SOW.Using the ontology in this way prompts the analyst to consider these aspects and include the relevant statements.
Next, the analyst will review the accountability considerations for the travel agent.is is considered in the context of the service provider role, which supplies the travel booking service via the mashup web site.Referring to the ontology, the service provider role is a super type of service source role.In addition to the accountability tasks discussed above, these ontology elements imply that the travel agent is also accountable for disclosing the information in service composition, such as the service pro�le of all web services provided by the service source roles.e linkage is clearly seen in the ontology as service provider role → web service → service pro�le.In the example scenario, the roles include the hotel operator, airline, map service, and location information providers.e mashup service also requires a valid contract with the consumer.is can be normally achieved by notices and "click-through" agreements when a customer registers with the site.Notices and click-through agreements satisfy the basic requirements necessary to establish legally enforceable commercial transactions [29].e notices and click-through agreements need to be documented as part of the functionality provided by the website in the SOW.
Examining the consumer role in Figure 7, it is clear that a service requester initiates a service request.Based on the ontology, a service request is a special task.A task delivers certain requirements, which are set out in some form of obligations in a client-supplier agreement that stipulates clearly the terms and conditions of the service provided.To hold the consumer accountable in the travel booking service scenario, the agreement is provided online and must be agreed upon before using the service.Upon accepting the agreement, the consumer will be held accountable for the service request.is may be achieved through the consumer's obligation to provide correct payment details and evidence of payment, such as a valid account, payment card, or eCommerce transaction.
To ensure that accountability is upheld in the mashup services, it is necessary that the SOW stipulate several additional areas.is includes privacy, copyright or trademark laws, and the remaining accountability tasks performed by the relevant parties.Where there is no explicit regulation to be applied, but obligations from involved parties are expected, then a valid contract is required to ensure governance by common law.e ontology assists in this legal analysis by identifying the relevant roles, responsibilities, and service tasks.

Summary and Conclusions
As mashup technology enters into the mainstream enterprise business, accountability will emerge as a key requirement to be addressed.As pointed out in [2], a number of legal issues require consideration when using mashup solutions.We suggest that it will be increasingly important for mashup service oriented solutions to have an accountability mechanism builtin to facilitate trust and the resolution of the legal issues.
is paper builds upon existing theories by applying trust and nonrepudiation in a multiparty environment for de�ning accountability.Using this de�nition, we propose models that may be used by information systems developers to understand the roles and responsibilities that need to be accommodated in a mashup service solution.In addition, the liabilities and obligations are analyzed.e proposed ontology helps to de�ne the various entities and artefacts involved in a mashup service.is can be used to assist in the preparation of agreements that are required between the various entities involved in a mashup service environment.is will also help to de�ne the scope of accountability to be addressed and will further serve to de�ne requirements of the information systems supporting the mashup service solution in order to meet disclosure requirements.
6.1.Further Work.In addition to developing accountability assertion policies that may be included within the WS- * frameworks, there are further extensions that may be studied.For instance, accountability information such as roles and service composition are currently not available in registry services.In other words, there is no information that advises whether the service being discovered is a mashup service.Nor are there details regarding the various service sources involved.An extension may be developed to supply this additional information to the service requester.is may be useful to assist in deciding if the service being discovered is of sufficient integrity (accountable and accurate) to suite the needs of the requester.
One suggested approach to address this requirement is by including the accountability metadata within the OWL-S service property� speci�cally one may use the Service Parameter property as an extension to add the accountability relevant elements into the service pro�le.Extending the example from Section 5, the sample XML source shown in Algorithm 3 shows the mashup service utilizing a hotel booking service from "hotel.com." In addition to machine interpretation of the accountability roles and responsibilities, the proposed ontology may also be used to establish a common accountability vocabulary useful to developers and runtime interpretation.e ontology already contributes to the de�nition and preparation of agreements between the various parties, and extending the ontology for machine interpretation is an area of further work.
Furthermore, as the mashup services based on RESTful web services are becoming mainstream due to the simplicity and performance bene�ts that the lightweight architecture offers, inevitably we need to adopt RESTful web service semantic description standards to specify the accountability metadata.Another area of further work is using SAWSDL [30] to annotate accountability metadata for RESTful mashup services.

F 3 :
SOA Architectural Style and Actors.

T 3 :
ePayment providerService source (i) Provide payment service.(ii)Adhere to service level agreement.Travel agent and service sources receive payment.Accountability requirements.Interaction scenario Accountability requirementCustomer ↔ travel agent (i) Mutual authentication between customer and travel agent.(ii) Disclose traceability in service composition and the up-to-date booking status upon request.(iii) Provide tamper proof evidences on booking transactions upon request.Travel agent ↔ mapping service Travel agent ↔ location provider Travel agent ↔ �ght provider Travel agent ↔ hotel Travel agent ↔ eCommerce (i) Mutual authentication between travel agent and the external service sources.