J. Altmann, R. Buyya, and O.F. Rana (Eds.): GECON 2009, LNCS 5745, pp. 171–181, 2009. © Springer-Verlag Berlin Heidelberg 2009

Business Collaborations in Grids: The BREIN Architectural Principals and VO Model

Steve Taylor1, Mike Surridge1, Giuseppe Laria2, Pierluigi Ritrovato2, and Lutz Schubert3

1 University of Southampton IT Innovation Centre, 2 Venture Road, Chilworth, Southampton SO16 7NP, UK

{sjt,ms}@it-innovation.soton.ac.uk 2 Centro di Ricerca in Matematica Pure e Applicata (CRMPA) c/o DIIMA,

Università degli Studi di Salerno, via Ponte Don Melillo, 84084 Fisciano (Italy) {laria,ritrovato}@crmpa.unisa.it

3 High Performance Computing Center Stuttgart (HLRS) Nobelstr. 19 D - 70569 Stuttgart, Germany schubert@hlrs.de

Abstract. We describe the business-oriented architectural principles of the EC FP7 project “BREIN” for service-based computing. The architecture is founded on principles of how real businesses interact to mutual benefit, and we show how these can be applied to SOA and Grid computing. We present building blocks that can be composed in many ways to produce different value systems and supply chains for the provision of computing services over the Internet. We also introduce the complementary BREIN VO concept, which is centric to, and managed by, a main contractor who bears the responsibility for the whole VO. The BREIN VO has an execution lifecycle for the creation and operation of the VO, and we have related this to an application-focused workflow involving steps that provide real end-user value. We show how this can be applied to an engineering simulation application and how the workflow can be adapted should the need arise.

Keywords: Service Oriented Architecture, Grid Computing, Supply Chain, Value Network, Virtual Organisation, SLA, Workflow.

1 Introduction

This paper discusses the business-focused architectural principles and VO model approach of the BREIN project. The architecture is founded on the principles of how real businesses interact to mutual benefit, and we show how these can be applied to SOA and Grid computing by way of examples driven by the project’s end-user scenarios.

BREIN has two real-world end-user scenarios that have determined requirements and validation for the project’s innovations. These are in the two areas of airport ground handling and virtual engineering design simulations (so-called because the simulations enable virtual engineering designs to be evaluated without the need for

172 S. Taylor et al.

real-world mock-ups). While these may seem very different, they pose very similar problems regarding business situations and resource and service management. In both cases the resources required can be treated as services, and therefore can be traded: in the airport scenario, a bus carrying passengers from an aircraft is treated as a service supplied by the bus company to the airport, and in the virtual engineering scenario computational fluid dynamics simulation software running on a cluster can be similarly offered as a service.

This paper is in two broad sections, each illustrated with examples from BREIN’s end-user real-world scenarios. Section 2 describes the BREIN architectural principles that support business interactions. Section 3 describes the BREIN VO concept and how it supports the BREIN architectural principles.

2 Architectural Principles

In a service-oriented Grid or Service-Oriented Architecture (SOA), users buy services from suppliers, but the suppliers may themselves use other services as raw materials, thus creating a supply chain: an organisation buys in component goods or services from its suppliers, adds value to them, and delivers the result to its customers. Bearing this in mind, we advocate a key principle: an organisation can act both as provider of services for their customers but at the same time be the customer of services from other providers.

The BREIN architecture is founded on this principle, which emerged from analysis of supply and value chains (see [1], [2]). This principle also reflects real business interactions more accurately than traditional “Grid” approaches, as in the traditional approaches, participants donated resources to a centrally managed pool in return for resources of another kind. To support service provision and consumption requires the adoption of an approach reflecting a generic customer-provider interaction pattern, and is based on three fundamental principles, discussed next.

2.1 Bipartite Relationships

A fundamental principle is an approach completely grounded in bipartite (1-1) business relationships with two parties, typically with the roles of customer and provider. These were introduced in the NextGRID project [4], [5], and are expanded upon here. The primary reason for bipartite relationships is that they represent how established business patterns operate; the customer buys goods and services from a provider. Relationships are formed, and trust is built up (or destroyed!) based on experience of past dealings.

We advocate that the approach to business relationships is to take the view that each organisation is the centre of their own world, as they see their suppliers and customers and utilise products and services from their suppliers to deliver value to their customers. Thus the same organisation can be a provider and a customer in different situations. There are special (more limited) cases of this, for example where there is an end-consumer who does not have any customers themselves, or a provider that runs all their own application services in-house, but the general and most common pattern is that an organisation buys in component goods or services, adds

Business Collaborations in Grids: The BREIN Architectural Principals and VO Model 173

value to them to produce their goods or services and sells these to their customers. This is the placement of the organisation into the supply chain, and the value chain inside the organisation determines how value is added. A single organisation is unlikely to be aware of the entire supply chain: in the real world there is also no omniscient viewpoint of organisations’ relationships and there is certainly no central control. Compared to a traditional VO, our approach is a value network, and the participation of the actors towards a goal of the VO is governed by the actors' individual economic aims, rather than an altruistic aim of true collaboration. If it is in the interest of an actor to participate, they will.

There is most likely to be a contract governing the relationship between a customer and provider. Once this is established, it provides a mutually-agreed set of points against which measurement of performance can take place. Often, this relationship will be in the form of a Service Level Agreement (SLA), which, in addition to that discussed above, describes the service on offer, and the obligations of the parties involved for delivery of that service. The provider is responsible to the customer for delivery of the work they are contracted for.

As long as the provider keeps to the terms of their agreement with the customer (which may indeed provide some restrictions on how the provider does the work), the provider can provision resources for the work any way they see fit. Unless the contract with their customer forbids it, a provider can outsource all or part of their service (e.g., the provider may subcontract out part of their service offering). Thus the bipartite relationship is a recursive pattern: a provider in one relationship may be a customer in another.

2.2 Virtualisation and Encapsulation

Over recent years, the concepts of “Virtualisation” and “Encapsulation” [4], [6], [7] [8], [9] have been increasingly adopted for simplifying infrastructure complexity that is exposed as simple services, which can be easily integrated. This hiding of resources is related to the concept of hiding details and separation of concerns in practice (at programmatic level), in use since the 1970s (for example see [3] and also [10]) and is completely consistent with our argument that the service provider should be free to provision a service any way they see fit, provided they comply with the terms of the agreement with their customer.

Outsourcing may also be encapsulated and virtualised using a principle derived from work in the NextGRID project [5], described in [4]. A customer may purchase a service from a provider, which itself may be made up from services themselves purchased by the provider. This is shown in Figure 1.

Fig. 1. Encapsulation of Outsourcing

174 S. Taylor et al.

It is said that the SP2 encapsulates its suppliers (here exemplified by SP3 but there may be many suppliers) in order to create Service X for its customer C1. Service Y is a component part of Service X and is part of the sub-contract arrangement between SP2 and SP3, with SP3 being the subcontracted party. SP2 must take responsibility for SP3's delivery of Service Y for the production of Service X. In other words, it is the SP2’s problem if one of their suppliers fails to deliver. The customer cannot be responsible for this! This is termed “aggregation of risk” as SP2 is managing their suppliers and the risks of them not delivering.

2.3 Orchestration

Orchestration is used where the Customer of more than one service provider wants the providers to interact. The customer manages this interaction, and thus orchestrates the providers (see [11]). An example is shown in Figure 2.

Communicationfor Customer C1:

Output of Service X isinput to Service Y

SP2 providing Service X

SP C

SP3 providing Service Y

SP C

SLA (C1, SP2Service X)

SLA (SP2, SP3Service Y)

Customer C1

C

Fig. 2. Orchestration

Here the customer C1 orchestrates SP2 and SP3. C1 tells SP2 to deliver the output of Service X to be the input of Service Y hosted at SP3, and SP3 is instructed to expect it and use as it as input for Service Y.

2.4 An Example Business Structure

The principles presented above are intended as building blocks from which complex business structures and workflows where one step may be decomposed into multiple steps or outsourced as a service may be built if required. Figure 3 shows an example.

Here the Customer has business relationships with SP1 and SP7, and instructs the output of SP1 to be sent to SP7, thus orchestrating SP1 and SP7. However, SP1 encapsulates a series of outsourced services to create its output. These are SP2, SP3 and SP4 - all orchestrated by SP1. Data is transmitted from SP1 to SP2 (transmission 2), processed by SP2, and sent onto SP3 (transmission 3) under the control of SP1. The bubbles in Figure 3 illustrate certain actors' fields of view and influence: a field of

Business Collaborations in Grids: The BREIN Architectural Principals and VO Model 175

Fig. 3. Example Business Structure

view is defined by the partners that the actor can see and interact with, and the field of influence is where the actor can have some degree of control1.

SP1’s field of view and influence for this example are shown. SP1’s field of view comprises the actors they are aware of, and the field of influence is where they are giving SP2, SP3 and SP4 economic vested interest to provide services to them, as SP1 is a customer (and therefore will pay) SP2, SP3 and SP4. SP1 has no knowledge of SP5 and SP6, as they are encapsulated by SP4. Similarly, C1 has no knowledge of any provider apart from SP1 and SP7. All the others are managed by the respective provider encapsulating and orchestrating them.

We assert that the fields of influence are actually business Virtual Organisations (VOs), as they represent collaboration from the point of view of one main actor. The other partners in the VO respond to SLA-based goals from the main actor. The BREIN VO concept is described next.

3 The BREIN VO Concept

Our real-world economic focus also influences our concept of the BREIN Virtual Organisation (VO). Classical grid-based VO approaches generally assume that

1 Not all possible fields of view and influence in the figure are shown for reasons of clarity. The

real situation is likely to contain more partners in the fields of view and influence, as each actor will have many interactions from multiple unrelated SLAs, and each actor will have to manage the demands of each of these SLAs.

176 S. Taylor et al.

providers expose their resources for sharing with others in the network. Whilst this is applicable in a shared-resources academic approach, it does not hold true in an economic world, where organisations sell services made from resources rather than the resources themselves.

Thus, the traditional Grid VO approach is not compatible with the supply and value chains of actual businesses, and hence there was a need to adopt an approach that reflects a generic customer-provider interaction pattern, as this is the fundamental pattern for interaction in real businesses. The next sections describe the BREIN VO related to examples from the BREIN airport scenario concerning ground handling services.

As with the field of influence, a BREIN VO is centric to a main contractor who defines a complex goal to be realised via a (virtual) collaboration and orchestrates subcontracted parties to achieve that goal via bipartite agreements. Such a goal definition contains all the collaboration details, i.e. goals, contractual scope, capabilities, requirements and limitations. With participants hiding their infrastructure and with VOs allowing for simple integration of outsourced resources into the local business processes, Service Providers may create their own VO within another VO, i.e. they may use an encapsulated subcontract to provide the capabilities they expose to external customers. Figure 4 shows an example of this using BREIN’s airport user-partner scenario as an example.

VO2

Airline Airport

contractual binding

• VO1.MC • VO1.C• VO2.MC

VO1

Legend:MC –Main Contractor

C – ContractorSC –Sub Contractor (invisible)

Ground Handling

contractual binding ✚

VO3

Buses

contractual binding

• VO1.SC• VO2.C• VO3.MC

• VO3.C

Gangway

• VO3.C

Passengers

Fig. 4. Three nested VOs in an Airport Context

This figure includes several parties involved in the supply chain related to airport management. These parties can form different VOs (e.g. VO1, VO2, and VO3) that meet specific goals, but there is an implicit relationship between the contracts of the linked VOs, and this is determined by the supply chain formed by the VOs that has the overall goal of servicing the airline. The subcontracted parties may not know the overall goal, but will know the goals of their SLA with their customer. This means e.g. that the airport will negotiate a contract with a ground handling service provider in order to fulfil the contract with the airline – whilst the airline is unconcerned with respect to how this requirement was fulfilled. Though the VO2 contract may actually base itself on the VO1 contract, it is more likely that a completely new contract is generated to ensure additional business aspects, but the critical point is that the VO2

Business Collaborations in Grids: The BREIN Architectural Principals and VO Model 177

contract must not prevent the Airport fulfilling its contract with the Airline in VO1, and the Airport must ensure this in its contract negotiations with the Ground Handling service.

3.1 Workflow and VO Lifecycle

A typical BREIN application from either end-user scenario can be seen as a sequence of steps to be executed: a workflow. We assert that within the application workflow, there is an orthogonal business workflow that is executed by the main contractor enacting the application workflow. For each application step (or group of steps), a business process that follows the VO lifecycle is required to execute the application step in a service-based environment. The BREIN VO lifecycle follows the typical VO lifecycle that is widely used (for example see [12]) and contains the phases: Identification (find providers), Formation (make agreements with providers), Operation (use the providers’ services) and Dissolution (dissolve the VO).

The relationship between an end-user's application focus and the VO lifecycle is given next by way of an example from the BREIN Virtual Engineering scenarios. One case study is that the effects of locating an electricity-generating wind-turbine in a particular location are required. The simulation tools in the VE scenario are able to provide insights into the wind effects on the turbine and wake interactions between it and neighbouring turbines at that location, A terrain model of where the turbines are to be located is supplied by the user, and the simulation is required to analyse the effects of the wind from multiple different compass-point directions and at different speeds. For example, if there are 12 compass-point directions and five chosen wind speeds per compass-point, the actual task comprises 60 separate simulations: one per compass-point and wind speed combination. These simulations are independent, and therefore they can be run in parallel to provide a fast answer to the user. The workflow corresponding to this simulation comprises three major steps: creation of an input "mesh" that represents the wind turbines located in the terrain in a format the simulation software can understand, the 60 independent simulations themselves, and the aggregation and post-processing of the numerical simulation outcomes into a visual form easily understandable by humans. The workflow for this application and its relationship to the business process required to make each step executable is shown in Figure 5.

The figure shows the application focused workflow (the vertical path) is the solution to the customer goal and enacted by the main contractor, but the main contractor will not execute it completely in house – instead, they will sub-contract all the processing (forming VOs) and manage the interactions with the subcontracted-service providers (according with the encapsulation principle).

Each application step to be performed by the main contractor the application thus requires the creation of a VO that can perform that application step and follows the VO lifecycle (i.e. find, agree, execute). This is represented by the horizontal paths in Figure 5.

The identification phase corresponds to the task of locating and selecting external suppliers that can perform the application step. In a marketplace of services, there may be many providers that are able to provide the functionality for one step, and therefore selection is required.

178 S. Taylor et al.

ApplicationSteps

Business Process (VO Workflow) for

Each Application Step

FormationOperation

& EvolutionIdentification

ABSTRACT (APPLICATION-FOCUSED)

WORKFLOW

VO-Workflow

VO-Workflow

Find:Discover

Provider to run

simulation

VO-Workflow

Agree SLA with

provider 1

Execute:Create mesh at

provider 1

Agree SLA with provider

2

Execute:Run simulation at provider 2

Agree SLA with provider

3

Execute:Run simulation at provider 3

Agree SLA with provider

4

Execute:Run simulation at provider 4

Find:Discover

Provider to create mesh

Application Step 1E.g. create

simulation mesh

Application Step 2E.g.run simulation

Application Step 3E.g.post-process

output for visualistion

Find:Discover

Provider to post

process

Agree SLA with

provider 5

Execute:Generate display at provider 5

Fig. 5. Application-Focused Workflow and VO-Workflow

The formation phase comprises the signing of bipartite SLAs resulting from the identification phase, meaning that after the signatures, the partners are committed to the VO for the purposes of providing the service quoted in the SLA.

The operation and evolution phase of the VO lifecycle involves actually invoking the services and orchestrating them together. The main contractor must orchestrate the providers and their services together to provide the overall application workflow. For this example, orchestration requires uploading input data to the service providers executing the processing at each provider, monitoring the executing processes at each of the providers to determine if they have finished, or if there is a problem for which action needs to be taken, collating and transferring any output data to another provider that requires it as input, and downloading the final output.

The evolution phase of the VO lifecycle may involve more complex handling. Evolution means that the VO is changed somehow during its life. An example of this is shown in Figure 6 and is related to monitoring the execution: if the main contractor detects a problem with one of the service providers running the simulation, then adaptation will need to occur. The strategy for adaptation will depend on the circumstances of the problem or the strategy of the main contractor. For example, if a provider is running too slowly, a different SLA promising higher performance may be selected, or if there is a total failure, a replacement service provider may be sought.

Business Collaborations in Grids: The BREIN Architectural Principals and VO Model 179

Fig. 6. VO Adaptation - Find New Provider

This second example requires a new VO lifecycle for the replacement simulation task, and this is illustrated in Figure 6.

Here provider 4 has failed, and the main contractor has decided to locate a new provider to perform the simulation tasks in place of provider 4. There is a new VO workflow dedicated to the task of locating a provider, signing an SLA and running the simulation in place of provider 4. The main contractor must orchestrate this new provider and VO workflow into the existing workflow to ensure continuous operation.

As with the nested VOs described previously, the overall responsibility for the whole workflow belongs to the main contractor: they have to manage the subcontracted providers to achieve the customer’s request. In this way, the entire application workflow may be encapsulated for its user – the user need never be aware of the complexity behind what appears to be an atomic service. The user benefits in that a complex-to-manage service is simple to use and can be offered with SLA-guaranteed terms, and this is the reason for the main contractor’s business offering – they hide the complexity and take responsibility for management of the complicated, composite service.

180 S. Taylor et al.

4 Conclusions

In this paper, we have presented the BREIN project architectural approach to business interactions via its architectural principles and VO concept. We have related these elements to an application-focused workflow, which provides actual benefit for real-world users.

We have advocated the principle of a 1-1 business relationship, with typically a customer and provider, as it is a fundamental building block used throughout the real business world. We have also discussed the encapsulation of resources into services, together with encapsulation of outsourcing where subcontracted service providers are liable to their main contractor. This is the essence of the BREIN VO concept, which is centric to, and managed by, the main contractor who bears the responsibility for the VO to deliver value to its customers.

The BREIN VO has an execution lifecycle for the creation and operation of the VO, and we have related this to an application-focused workflow involving steps that provide real value to end-users. We have shown how this can be applied to an engineering simulation application, and show that the workflow can be adapted should the need arise.

Acknowledgments. This work has been supported by the BREIN project (http://www.gridsforbusiness.eu) and has been partly funded by the European Commission’s IST activity of the 6th Framework Programme under contract number 034556. This paper expresses the opinions of the authors and not necessarily those of the European Commission. The European Commission is not liable for any use that may be made of the information contained in this paper.

References

1. Porter, M.: Competitive Advantage. Free Press, New York (2004) ISBN-10: 0743260872, ISBN-13: 978-0743260879

2. Supply-Chain Council (eds.): Supply Chain Operations Reference Model (SCOR®) Overview (2007), http://www.supply-chain.org

3. Parnas, D.: On the Criteria to Be Used in Decomposing Systems Into Modules published in the Communications of the ACM (December 1972)

4. Herenger, H., Heek, R., Kubert, R., Surridge, M.: Operating Virtual Organizations Using Bipartite Service Level Agreements, Grid Middleware and Services: Challenges and Solutions. In: Talia, D., Yahyapour, R., Ziegler, W. (eds.) Association with the 8th IEEE International Conference on Grid Computing (Grid 2007). Springer, Heidelberg (2008)

5. NextGrid – Architecture for Next Generation Grids, http://www.nextgrid.org/ 6. Dimitrakos, T., Gaeta, M., Serhan, B., et al.: An emerging architecture enabling Grid based

application service provision. In: Proceedings of the 7th International Conference on Enterprise Distributed Object Computing,

7. Foster, I., Kesselman, C., Nick, J.M., Tuecke, S.: The Physiology of the Grid 8. The IBM Group (2007) Why Virtualization Matters to the Enterprise Today,

ftp://ftp.software.ibm.com/common/ssi/rep_wh/n/OIW03008USEN/OIW03008USEN.PDF

Business Collaborations in Grids: The BREIN Architectural Principals and VO Model 181

9. Nash, A.: Service Virtualization – Key to Managing Change in SOA (2006), http://www.bitpipe.com/detail/RES/1130171201_512.html

10. Haller, J., Schubert, L., Wesner, S.: Private Business Infrastructures in a VO Environment, in Paul Cunningham. In: Cunningham, P., Cunningham, M. (eds.) Exploiting the Knowledge Economy - Issues, Applications, Case Studies, pp. 1064–1071 (2006)

11. Terracina, A., Kirkham, T., et al.: Orchestration and Workflow in a mobile Grid environment. In: Proceeding of the Fifth International Conference on Grid and Co-operative Computting Workshops, GCCW 2006 (2006)

12. Saabeel, W., Verduijn, T., Hagdorn, L., Kumar, K.: A Model for Virtual Organisation: A structure and Process Perspective. Electronic Journal of Organizational Virtualness (2002)