Synthesizing a Criterion for SOA Reference Architecture to Sustain eParticipation

Synthesizing a Criterion for SOA ReferenceArchitecture to Sustain eParticipation

Muntazir Mehdi1,2, Arkadiusz Stasiewicz2, Lukasz Porwol2, Deirdre Lee2, andAdegboyega Ojo2

1 Department of Computer Science,Technical University Kaiserslautern, Kaiserslautern, Germany

m [email protected] Digital Enterprise Research Institute, National University of Ireland, Galway

{firstname.lastname}@deri.org

Abstract. With inception of Service-Orientation in research and indus-try, the need to select a Reference Architecture (RA) that supports Ser-vice Orientation in some specific domain has developed into a challenge.Institutionalizing a criterion that helps software designers and develop-ers to properly extend or design an RA for a domain-specific, goal-awareand context-aware implementation of a Service-Oriented Architecture(SOA) system has evolved into a necessity. In this article, a criterionderived from understanding existing standard SOA reference architec-tures is presented. In following presented work, we focus specifically onthe eParticipation domain to validate the proposed criterion. The crite-rion will not only help improve the process of refining and specialisingstandard SOA-RA, but also provides a set of key ingredients to sustainSOA-RA definition in the eGovernment domain, specifically to sustaininformation integration in eParticipation.

Keywords: Software Architectures, eGovernment, eParticipation, Ser-vice Oriented Architecture, SOA Reference Architecture

1 Introduction

Service-Oriented Architectures (SOA) have existed in research and industry for25 years and have been providing an architectural approach to enterprises en-abling the reuse of business operations. SOA is an evolving architecture modelthat gains maturity from its predecessors, while drawing on the concepts ofservice-orientation [9]. With the widespread acquisition of Information and Com-munication Technologies (ICT) in multitude of enterprises, skilled software ar-chitectures are clearly in-demand to coordinate and manage systems and pro-cesses within and between enterprises. Today, the focus of both industry andresearch revolves round the development of distributed systems with effectiveand efficient design processes and work-flow integration. Business applicationsin the past were simple and thus there was no need to define complex archi-tectures. But with the advances of ICT, introduction of technologies involving

2 Mehdi et al.

big data and cloud computing, complex architectures introduced themselves al-beit with their respective challenges. In past, with the introduction of multi-tierapplications, the biggest challenge was to define a template or an abstract archi-tecture using which concrete architectures could be built or drawn. Even thoughthe template was abstract, its purpose was to define technologies, boundaries,rules, necessities, and design characteristics that apply to the desired solution.These templates or abstract architectures are known as Reference Architectures(RA) [9].

RAs have proved to be very effective for domains involving extensive useof Information and Communication Technologies (ICT). eGovernment domainbuilds itself based on the use of ICT. eGovernment refers to extensive use oftechnology in the public sector to support the provision of public services andmanagement of government and public affairs. David McClure, Associate Direc-tor of the U.S. General Accounting Office, views eGovernment as [14]:

“Electronic government refers to government’s use of technology, particularlyweb based Internet applications to enhance the access to and delivery of govern-ment information and service to citizens, business partners, employees, otheragencies, and government entities. It has the potential to help build better rela-tionships between government and the public by making interaction with citizenssmoother, easier, and more efficient. Indeed, government agencies report usingelectronic commerce to improve core business operations and deliver informationand services faster, cheaper, and to wider groups of customers.”

eParticipation is an increasingly important component of a complete eGov-ernment strategy, which involves the use of ICT to achieve certain commongoals [11]. Blogs, discussion forums, and the use of social media like facebookand twitter have proven to be the most effective eParticipation tools. With theongoing growth of Internet, there is a growing interest in using social media plat-forms (facebook, twitter, etc) for eParticipation [11]. However, with social mediabecoming mainstream in eParticipation, a new set of information integration andinformation sharing challenges have arisen.

Service Oriented Computing (SOC), a realisation of Service Oriented Ar-chitectures (SOA), has extensive potential of addressing both information inte-gration and information sharing challenges using the power of web-services indifferent heterogeneous platforms on the Web. But choreographing web-servicesto address information integration and information sharing challenges is a non-trivial task in social media platforms due to their distributed nature [7]. SOAReference Architectures (SOA-RAs) are an extension of RA that incorporateand support service orientation. Currently, there are some standard SOA-RAsthat support implementation of a SOA system in different domains. However,there is no existing approach on how to extend or customize standard SOA-RAsto any user-required, newly adopted domain-specific implementation.

In addition to this, the confidence of a SOA architect on standard SOA-RAis also a critical consideration while implementing SOA systems. The decisionto adapt to the idea of using services or service-orientation in business, theassessment of current situation of the business, and quantification of benefits

Title Suppressed Due to Excessive Length 3

achieved from implementing SOA, needs to be carried out beforehand. SoftwareArchitects thus are responsible for defining reference models at different level ofabstractions and derive an RA that extensively merges these reference models[12].

In this article, we propose criterion for SOA-RA for use in eParticipationsystems. The criterion enables architects to define an RA based on which SOAimplementations can be carried out. In Subsection 2.1, a brief motivation thatdrove our work towards determining criterion for SOA-RA is presented. In Sub-section 2.2, a systematic approach of deriving criterion for SOA Reference Ar-chitecture (SOA-RA) is described. Section 3, gives a brief insight into generalarchitectures and their importance, and discusses a criterion that is derived fromunderstanding the basic concepts of Reference Architectures (RA). In Section4, a discussion of RA in context of SOA is presented. Specifically, we discussSOA-RA proposed by The Open Group to develop our understanding of stan-dard SOA-RA [12]. And in section 5, detailed criterion for SOA-RA is presented.Finally in section 6, an eParticipation SOA-RA and detail of some of its com-ponents are presented.

2 Motivation and Approach

2.1 Motivation

“Puzzled by Policy” (PbP) 3 is a European Commission project, funded underthe Competitiveness and Innovation Framework Programme (CIP) ICT PolicySupport Programme (ICT PSP). This large eParticipation project has a con-sortium consisting of twelve partners from nine European Countries (Greece,Hungary, Ireland, Italy, the Netherlands, Portugal, Slovenia, Spain and UnitedKingdom) and is led by INSIGHT - Centre for Data Analytics (formerly DERI)at NUI Galway. The main objective of the project is to increase citizens aware-ness of the current EU and individual member countries immigration policiesand to engage citizens directly in policy-making process. Before joining the dis-cussion users are allowed to graphically compare their views on immigrationwith national and EU immigration policies. After that they are encouraged tojoin discussions on particular aspects of immigration policy they feel stronglyabout. The Puzzled by Policy platform is available in five languages, includingEnglish, Spanish, Greek, Hungarian and Italian. Additionally, online discussionscan be automatically translated into any language. Main topics are separatedinto threads, which contains posts related to a particular user. This eParticipa-tion tool is hosted at http://join.puzzledbypolicy.eu

As previously discussed, social media (SM) has a great potential to widenand boost eParticipation. Therefore inclusion of the information retrieved fromSM, such as Facebook and Twitter significantly increases the range of discus-sion on PbP platform. Nevertheless, the inclusion of SM information on PbPplatform leads to data retrieval, data sharing and data integration challenges,

3 http://www.puzzledbypolicy.eu/

4 Mehdi et al.

especially with respect to the volume and heterogeneity of the data. Moreoverthe integration of the data gathered on PbP platform with the soon new comingdeployments or other sister-systems (discussing related topics) demands extracapabilities in regard to data integration and data interchange. In this paperwe show an approach that derives specific criterion for defining a SOA-RA foreParticipation addressing the identified, data related challenges.

2.2 Approach

In order to derive a criterion for SOA-RA, we first looked into the definition,importance and criterion for a general RA given in Section 3. This providedus with a basic understanding of software architectures, their abstract repre-sentations and a criterion based on which they are best judged. Secondly, weinvestigated RAs in context of SOA. While understanding SOA, its componentsand one specific standard SOA-RA given in Section 4, we formed an observationthat lead to the grounds for creating a criterion for SOA-RA. The whole processof deriving the criterion for SOA-RA is shown in figure 1. In addition to thegrounds or observations extracted from general RA and SOA-RA, we also inves-tigated some industry implementations of SOA-RA to enlist a set of componentsthat are general and serve as basis while defining SOA-RA from scratch. Thefinal outcome of our work is a criterion derived from grounds and observationsthat we developed while discussing RA, SOA-RA and SOA-RA in industry. Thecriterion is given in section 5.

Reference Architecture

SOAReference Architecture

SOA in Industry

Ground for Criteria

Criteria for SOA RA

Criteria for RA

RA in context of SOA

Ground for SOA RA Criteria

Ground for SOARA Criteria

Fig. 1. Process of deriving criterion for SOA RA

Title Suppressed Due to Excessive Length 5

3 Reference Architecture

There is no universal, standard or well-accepted definition of RA [6] but to geta basic understanding of it, we found few definitions of RA in literature:

– According to Rational Unified Process (RUP), an RA is, in essence, a prede-fined architectural pattern, or set of patterns, possibly partially or completelyinstantiated, designed, and proven for use in particular business and techni-cal contexts, together with supporting artifacts to enable their use. Often,these artifacts are harvested from previous projects. [6]

– An RA is the generalized architecture of several end systems that share oneor more common domains. The RA defines the infrastructure common to theend systems and the interfaces of components that will be included in theend systems. The RA is then instantiated to create the software architectureof a specific system [10]

– According to IBM, an RA provides a blueprint of a to-be-model with awell-defined scope, requirements it satisfies, and architectural decisions itrealizes. By delivering best practices in a standardized, methodical way, anRA ensures consistency and quality across development and delivery projects[16]

Thus in simple words it can be concluded that an RA is a diagram/pattern/spec-ification or set of diagrams/patterns/specifications that; 1) depicts the admin-istration of system functions among components in the infrastructure and 2)provides a map for how those functions relate to each other.

After looking at these definitions and drawing our own conclusion about RA,we can say that RA are becoming an integral part of software design and plan-ning, but where did these RA come from and how did they evolve to becomea necessity? The answer to these questions is simply the increase in complexityof applications that cater with the current business needs in organizations andenterprises. For Instance in classic development approaches where the main fo-cus is to address the functionality on the whole for an individual component.Instead of considering components behavior with respect to entire execution en-vironment, inclusion of entire functionality within a single component resulted incomponent dependency within an environment. Based on the needs and neces-sities of businesses to incorporate information technology (IT) as an improvingfactor, the requirement of making components more independent emerged, soas to achieve high interoperability by creating loosely-coupled components. Thedevelopment of loosely-coupled components itself has the challenge of design-ing components which encompass the required functionality, support for othercomponents to communicate with it via the same channel, thus making thecomponents reusable, standalone and composite. The increased complexity indevelopment and implementation of distributed systems to achieve high level ofinteroperability, by creating robust components within the systems is the basisof high involvement of RAs in the software design process. Hence these softwareRAs can be used as a mechanism for: 1) the development of concrete archi-tectures, 2) standardizing tool that guarantees the interoperability of a system

6 Mehdi et al.

with other systems, 3) standardizing tool that guarantees the interoperabilitybetween system components by validating the original purposes and 4) makingsure that the basic requirements which were specified during the problem defi-nition phase were addressed [15]. The above scenario fits perfect when we talkabout the role of RA in SOA. However, the scope of RA is not limited to thisand has a wider audience of architectures to serve. In a nutshell, an RA containsnecessary information for project team members; this information provides a setof architectural best practices.

3.1 Importance of Reference Architecture

A Reference Architecture is a combination of Business Architecture, TechnicalArchitecture and Customer context [15]. Therefore, we can infer that an RAensures that the end users and the participants have the confidence to deploythe technology. Some of the major benefits of RAs are [3]:

1. Reference architecture ensures addressing the core problems and challengeswhen deploying a technology.

2. Reduces risk of deployment by relying on known and tested solutions.3. Simplifies decision making.4. Provides consistent models, capabilities and equipment.5. Relies on most pragmatic and proven solutions, rather than being adhoc.6. Helps in bridging cultural gaps between the organizations bringing the ex-

pertise and knowledge of each together in a way both can agree upon andprovide a common model and set of requirements for everyone by workingon design recommendations.

3.2 Criterion for Reference Architecture

After looking at the definitions presented above and noticing the importance, wecan say that applications today rely heavily on RAs. However, enough has notbeen done to support decision making when it comes to selection of RA. Duringour literature study on RA, we found minimalist criterion for a good RA. Thecriterion presented in [15] is as follows:

1. Should be understandable for all stakeholders (customers, product managers,project managers, engineers etc.)

2. Should be accessible and actually read/seen by majority of the organization.3. Addresses the key issues of the specific domain.4. Provides consistent models, capabilities and equipment.5. Should be of satisfactory quality and acceptable.6. Should be up-to-date and maintainable.7. Should add value to the business.

In addition to this, based on the observations made from the definition andimportance, we also define the criterion for RA. As we already know that anRA provides a template for architecture of a particular domain i.e. it provides a

Title Suppressed Due to Excessive Length 7

set of functions with their respective interfaces and interfaces for other domainsto communicate with it. Therefore, the level of abstraction at which an RAis selected for a particular domain plays a vital role. While considering thelevel of abstraction as a pivotal point for RA, the generalization of a systemwith respect to 1) itself, 2) the subsystems and 3) other domains should alsobe considered [6]. Context is another consideration that has proved to be vitalfor an RA [5]. While dealing with Context for RA, the aspects of design andapplication context which might affect the business goals and design of RA areinvestigated. The investigation is a result of answers obtained by answering somebasic questions like 1) Where will it be used? 2) Who defines it? and 3) When is itdefined? Since Context might affect the main goals of RA, therefore Goal shouldalso be selected as a consideration for RA criterion. The Goal consideration isinvestigated by addressing the main intentions of use for a particular RA i.e. whya particular RA has been defined and does it addresses its major purpose? TheDesign consideration is the most important consideration for a particular RAin order to encompass the major responsibilities and purposes of its usage. Inthis particular consideration a specification is formed which contains informationregarding the main RA itself, level of concreteness and the way it is represented.

4 SOA Reference Architecture

4.1 Service Oriented Architecture (SOA)

Before we start with SOA-RA we have to completely understand the meaning ofService Oriented Architecture (SOA). There is a wide confusion in understand-ing a SOA due to the myths and rumors that have come into existence due to itsambiguous definition in different literature. Let us understand it by starting fromscratch to get a main viewpoint of SOA itself. The traditional architecture hasevolved from mainframe implementation to client-server architecture and thento multi-tier architecture implementations. The application still has remainedup to a large extent tightly coupled i.e. the subsystems that executes the majorpart of application is semantically unaware of its surroundings subsystems butis physically related to them. With SOA, the application’s main functionalitydistribution unit is a service, which is independent and implements the mainbusiness logic and contains the associated data. These services interact witheach other via message passing for which a specific scheme is already defined, acontract which defines the interface for inter-connectivity and a policy describingthe way messages are exchanged [9]. So now, let us conclude the understandingby providing a very basic version of definition: “SOA is a loosely-coupled archi-tecture for addressing all the major business goals of an organization” [13]. Forthis definition to be correct, it is already known that SOA does not necessarilyneed Web-Services. Therefore, we come to draw a fine set of facts about SOAthat are:

1. Since SOA varies with respect to organizational needs, SOA is independentof vendors, product, technology or industry [13].

8 Mehdi et al.

2. SOA may be realized using web-services but web-services are not the mainneed to implement SOA [9,13].

3. SOA should be incremental and should be evolved [9, 13].

4. SOA is not a methodology [13].

5. A SOA-RA may not be the best solution for a particular organization [1,13].

The facts stated above give a deep understanding of SOA and their character-istics, and provide solid grounds when describing criterion for SOA-RA. Whileit can be noted that well implemented SOA can provide organizations withvery loosely-coupled distributed application systems, SOA also enables organi-zation to cope with the faster growing market competition by providing effectiveresponsiveness. But not necessarily all implemented SOA provide the desiredresults and experiences show that most of the implementations have failed [9].The success of a SOA implementation project is totally dependent upon theorganizational needs, business goals and the context. The unawareness of thedevelopers and designers to these factors result into a chaotic implementation ofSOA with no business relevance. The main and fundamental objective of SOAis to align IT capabilities with business goals. Since, SOA is not just IT infras-tructure nor a business strategy, SOA has to be a perfect combination of both.Therefore, while implementing or planning a SOA, a perfect road-map to SOAand blueprint for its verification is required. The SOA-RA serves as the blueprintof SOA which enables architects to verify that the SOA addresses all the busi-ness goals and adheres to the business relevance or it can be said that the RAis a way of making sure that the SOA sticks with the plan of its origin or maincause of its existence [8].

4.2 SOA Reference Architecture (SOA-RA)

As we already discussed in section 4.1 that RA is like a drawing/blueprint and aset of specification for an organization’s business model which is used to verify theconcrete version of the architecture, SOA-RA serves as an enterprise businesssystem’s reference model which should be defined carefully while defining theSOA road-map phase. For better understanding purposes, let us consider thestandard for defining the SOA-RA proposed by The Open Group [12]. Let us firstdiscuss the high-level perspective of the SOA-RA which is shown in figure 2. Thefirst five layers depicted in figure 2 do not strictly follow the ordering in whichthey are shown. The main purpose of these layers is to represent the businessfunctionality. The layers and their respective main building blocks are [12]:

– Operational Systems Layer: Programs and Data of the operational sys-tems of the enterprise are the main building blocks in this layer.

– Service Component Layer: Programs or group of programs that are writ-ten to perform service and deliver the service functionality and wrap theprograms in the operational systems layer to create services, these wrappersare the main building blocks of this layer.

Title Suppressed Due to Excessive Length 9

– Services Layer: The central layer of the model containing the portfolioservices, conform to a specification defined in the model for the consumersto invoke exposed functions.

– Business Process Layer: This layer consists of business processes whichmay be composition of other business processes or portfolio services.

– Consumer Layer: The layer contains users of the system and the programsby which they interface to the portfolio services.

Fig. 2. Layered OASIS SOA-RA [12]

The other four layers depicted in figure 2 provide the necessary assistanceto the layers supporting the business functionality but does not support eachother [12]. They contain building blocks whose purposes relate to :

1. Integration of other building blocks2. Quality aspects of system operation3. Information4. Governance

Following are the main building blocks which serve as the main constituents forconstructing the layers mentioned above of SOA-RA [12]:

1. Composition2. Messaging3. Service Discovery4. Asset wrapping

10 Mehdi et al.

5. Virtualization6. Event Processing

These building blocks along with the layers mentioned in OASIS SOA-RAproposed by the Open Group give a solid ground and a set of observations toderive a criterion for defining a SOA-RA.

5 Criterion for SOA Reference Architecture

Observing the understandings we got from the explanations of general RA, im-portance of RA, criterion for RA, and SOA-RA provided in the above sections,we can now jot down a criterion for a SOA-RA and a list of components whichwill serve as part of architecture. Following is the derived criterion that we pro-pose for SOA-RA:

While defining SOA-RA, first step is to collect requirements and all the re-quirements should be clearly understood and an easily understandable require-ment specifications has to be made. The requirements should target the specificdomain for which the RA is intended. Since we have already highlighted in theexplanation of software RA in subsection 3.2, even for a SOA-RA, the teams in-volved in defining the RA should be made very clear about the implementationcontext, business goals and design strategy for the architecture. All ambigui-ties in understanding the requirements should be addressed beforehand and thehealthy communication between team members for transfer of knowledge shouldbe made. This first step is common and usually followed in almost every softwareplanning phase. Now let us focus on the main goal of this article. After complet-ing the previous step, the second step is to draw a set of principles based on thespecified requirements. It is important that the set of principles extracted in thisstep should be in alignment to the common SOA principles [9]. As it is alreadyvery well known that the basic need behind implementing a SOA systems is de-coupling the components as much as possible, therefore a set of concepts shouldbe drawn from the requirements collected in first step. These concepts representthe components that will become part of reference model. This reference modelwill thus serve as a basis for creating an RA. A list of general components thatwill become part of the reference model and are widely used in standard andindustry based implementations of SOA-RA is given below:

1. Business rules and Business process services [1, 2, 4, 8]2. Data sharing and transformation services [2, 4, 8]3. Infrastructure and component services [1, 2, 4, 8]4. Third party communication and data sharing services [4, 8]5. Identity and security services [4, 8]6. Integration and Event management Services [1, 2, 4, 8]7. Packaged application access services [1, 2, 4]8. Presentation services, Registry and Repository Services [4, 8]9. Messaging, Quality and Governance [1, 2, 4, 8]

Title Suppressed Due to Excessive Length 11

These components not necessarily define the concrete and complete criterion forany specific SOA-RA, this means that there might be more components whichare further specific to the business needs. However, in this paper we have triedto enlist as much as possible generalized components. The third step is to makesure that the criterion explained in section 3.2 has been satisfied completely.Fourth and final step is to group together the identified components into layers.

6 eParticipation SOA Reference Architecture

In order to sustain information sharing and integration between PbP and SM(Facebook and Twitter) and presenting the information in an effective manner,we defined a set of reference models to support public participation on PbP plat-form. Additionally, based on the criterion presented in section 5, we incorporateboth reference models to create a SOA-RA that specifically addresses the needsof Service Orientation within eParticipation domain. The SOA-RA is presentedin figure 3.

GO

VER

NA

NC

E

MA

NA

GEM

ENT

SECURITY

CONSUMER LAYER

REGISTRY AND REPOSITORY SERVICES

Enterprise Service Bus

DATA AND APPLICATIONS LAYER

Data Sharing Services

Data Integration

Services

Data Retrieval Services

Data Transformation

Services

Data Publishing Services

PACKAGED APPLICATION LAYER

Presentation Services Consumer Services

Wikis Blogs Discussion

Forums Social Media

Component Services for eParticipation Tools

3rd PARTY COMMUNICATION SERVICES

Fig. 3. SOA-RA

In SOA-RA depicted in figure 3, most of the services, layers and componentsare derived from the criterion presented in this paper. Apart from those genericcomponents and layers, we introduced a set of services that are specific to ePar-ticipation domain. Following are the newly introduced services along with theirrespective responsibilities:

12 Mehdi et al.

– Component Services for eParticipation Tools: These services are inte-gral part of Packaged Application Layer and are used to support 3rd Partycommunication. The major responsibility of these services is to integrateeParticipation tools like Blogs, Social Networking websites, Discussion Fo-rums and Wikis.

– Data Publishing Services: Data integration from different sources andrepresentation of data in homogeneous format is critical to eParticipation.In our scenario: data integration from PbP platform, facebook and twitterfacilitates reaching a common goal through active discussion and participa-tion of users. We use Linked Data for representing data extracted from PbP,facebook and twitter.

7 Conclusion

As architectures have evolved, need to refine the business model and incorporatebusiness needs into the architecture as umbrella activity has gained popularity.There are a wide range of SOA-RA existing in market to address different do-mains, however there are still some unaddressed domains where such SOA-RAdoes not exist. In this paper we propose a generic criterion for selection, iden-tification and refinement of already existing standard SOA-RA. For instance,with changing nature of eGovernment and eParticipation, specifically the hugeinvolvement of ICT in these domains, there is a huge requirement of SOA-RAthat addresses them. So, in order to verify the criterion presented in this paper,we validate this approach by presenting a simplified SOA-RA based on standardSOA-RA which intentionally addresses the data integration and homogeneousdata representation problems within eParticipation domain. In this paper wefirst explained the general software RA along with its importance and crite-rion. However, the main intention of this article was to define criterion for anRA in the context of SOA. Thus, we defined a general criterion/set of rulesfor creating blueprints to verify SOA-based system by understanding RA, SOA,and SOA-RA. The criterion given in this paper addresses general SOA-RA, butwith the changing nature of business and enterprise applications, inclusion ofnew architectures into practice and refinement of these architectures to targetspecific domains, the need is to further extend and abstract this criterion. In fu-ture we are planning to investigate other different markets and domain specificimplementations for improving the criterion we derived and proposed in this pa-per. However, as of current situation of SOA-RA, the criterion we propose canserve as good starting point for defining SOA-RA and can also serve as a goodblueprint to verify and judge a SOA-RA.

Acknowledgment

This publication has emanated from research supported in part by a researchgrant from Science Foundation Ireland (SFI) under Grant Number SFI/12/RC/2289and in part by the European Union under Grant number 256261 (Puzzled byPolicy CIP-ICT-PSP-2009-3bis)

Title Suppressed Due to Excessive Length 13

References

1. Arsanjani, A., Zhang, L.J., Ellis, M., Allam, A., Channabasavaiah, K.: Designan soa solution using a reference architecture. IBM developerWorks, http://www.ibm. com/developerworks/library/ar-archtemp/[3] Ali Arsanjani, Liang-Jie Zhang,Abdul Allam, Michael ellis, et al. S 3, 10–17 (2007)

2. Arsanjani, A., Zhang, L.J., Ellis, M., Allam, A., Channabasavaiah, K.: S3: Aservice-oriented reference architecture. IT professional 9(3), 10–17 (2007)

3. Batke, B., Didier, P.: The importance of reference architectures in manufacturingnetworks. In: CIP Networks Conference (2007)

4. Behara, G.K., Mahajani, P., Palli, P.: Telecom reference architecture, part 2 (2010)5. Burkle, A., Muller, W., Pfirrmann, U.: Towards a reference architecture for context-

aware services. Advances in Human-Computer Interaction p. 316. Cloutier, R., Muller, G., Verma, D., Nilchiani, R., Hole, E., Bone, M.: The concept

of reference architectures. Systems Engineering 13(1), 14–27 (2010)7. Dillon, T.S., Wu, C., Chang, E.: Reference architectural styles for service-oriented

computing. In: Network and Parallel Computing, pp. 543–555. Springer (2007)8. Durvasula, S., Guttmann, M., Kumar, A., Lamb, J., Mitchell, T., Oral, B., Pai,

Y., Sedlack, T., Sharma, H., Sundaresan, S.: Soa practitioners guide, part 2, soareference architecture. Combined Effort pp. 1–52 (2006)

9. Erl, T.: Service-oriented Architecture: Concepts, Technology, and Desing. PearsonEducation India (2006)

10. Gallagher, B.P.: Using the architecture tradeoff analysis methodsm to evaluate areference architecture: A case study. Tech. rep., DTIC Document (2000)

11. Gerhardt, G.: e-participation (2009)12. Group, T.O.: Soa Source Book. Van Haren Publishing (2009)13. Linthicum, D.: Reader roi. Service Oriented Architecture (SOA) in the Real World

(2008)14. McClure, D.L.: statement of david l. mcclure, us general accounting office, before

the subcommittee on government management, information and technology, com-mittee on government reform, house of representatives. Committee on GovernmentReform (2000)

15. Muller, G.: A reference architecture primer. Eindhoven Univ. of Techn., Eindhoven,White paper (2008)

16. Schmidt-Wesche, B., Snitzer, B., Breiter, G., Widmayer, G., Whitmore, J., Vil-lareal, J., Behrendt, M., Caponigro, R., Chang, R., Pappe, S., et al.: Ibm cloudcomputing & common cloud management platform reference architecture (cc &ccmp ra) 1.0 (2010)