cloud interoperability

22
Enterprise Service Bus Architecture as a Cloud Interoperability and Resource Sharing Platform Amirhossein Mohtasebi

Upload: amirhossein-mohtasebi

Post on 01-Jul-2015

1.211 views

Category:

Technology


0 download

DESCRIPTION

My talk about Cloud Interoperability

TRANSCRIPT

Page 1: Cloud Interoperability

Enterprise Service Bus Architecture as a Cloud Interoperability and

Resource Sharing Platform

Amirhossein Mohtasebi

Page 2: Cloud Interoperability

Agenda

• Cloud

• Interoperability

• Interoperability in the Cloud

• Light-weight binding

• Cloud Service Bus

Page 3: Cloud Interoperability

Cloud

• Characteristics:

– Unlimited pool of resources

– Per use pricing model

– Geographically distributed

– Instant provisioning and configuration

– Great extent of virtualization

Page 4: Cloud Interoperability

Interoperability

• Definition

– “Interlinking a system, information, or workflows across multiple domains such as enterprise sectors, geographic locations, administrations, etc.”

– “The capability of two or more networks, systems, devices, applications, or components to externally exchange and readily use information securely and effectively”

Page 5: Cloud Interoperability

Cloud Interoperability

• Portability and Mobility

– Virtual Machine (VM) format

– Hardware requirements

– Metadata

– IP

– Subnet

• Example: Azure Redundancy vs. AWS

Page 6: Cloud Interoperability

Close vs. Open

– Business Acceptance

– Customer Lock-in

– Resource Sharing

Page 7: Cloud Interoperability

Current Situation

• There is no single –standard- vocabulary for inter-cloud communications:

– How data can go back and forth between Clouds?

– How the access regime can be defined for distributed access control?

– How meta data can be interpreted in different Clouds (semantic and syntactic)?

• Reflects the era before invention of TCP/IP

Page 8: Cloud Interoperability

Cloud Interoperability

• Hardware, Software, Platform, VM

Physical Layer

• Data Format, Data Type, Validations

Data Layer

• Data Context and Domain

Semantic Layer

Page 9: Cloud Interoperability

Current Efforts

– Cloud Computing Interoperability Manifesto

– OpenStack, OpenNebula, etc

– OVF, CDMI

– Supporting Multiple Languages

– Supporting Standard API

– Open Platforms (Cloud Foundry)

Page 10: Cloud Interoperability

Location Decoupling

Application

Heavy Dependencies

Platform

Application

Light-Weight Binding

Platform A

Platform C

Platform B

Page 11: Cloud Interoperability

Location Decoupling

• Heavy Dependency vs. Light-weight Binding– Transport

• Managing different protocols

• Handling different application design principals (REST), Protocols (SOAP)

– Route• Component to direct requests to correct endpoints and vice

versa

– Message• Transformation of the message (mainly using XSLT, or any

transformation mechanism)

Page 12: Cloud Interoperability

Location Decoupling

– Security• oAuth• Claim Based Authentication• Kerberos• Role/Right based Authorization

– Monitoring and Management• Auditing• SLA• QoS• Billing

• Cost?

Page 13: Cloud Interoperability

Location Decoupling

• Changing the application level to implement location decoupling?

– Another level of customer lock-in

• Extracting light-weight binding + Composable Middleware + Standard API?

Page 14: Cloud Interoperability

Enterprise Service Bus

• Terminal for integration of different services

• Create a mesh of Loosely coupled services

• 1:* vs. 1:1 (Federated Interface)

• Traditionally: SOAP+WS-Addressing

Page 15: Cloud Interoperability

Cloud Orchestration Architecture

• The arrangement, coordination and management of cloud infrastructure to provide services to meet IT and business requirements.

• Functions:

– Intermediate

– Aggregate

– Arbitrage

Page 16: Cloud Interoperability

Cloud Orchestration Architecture

18

Using composite service architecture allows ESB to span from specific number

of services to unlimited number of services by implementing federated interfaces.

Any application and third party that comply with this interface or at least build a

plug-in component that can be applied to this abstract layer can communicate

through ESB. Because of vast diversity of services in Cloud environment, applying

the concept of CSA to ESB can extend them from a limited enterprise environment

to unlimited Cloud environment.

Figure  2-5 CSA Layered Architecture (Source: Open Grid Forum, 2011)

As an example, Figure 2-6 illustrates a resource discovery and sharing

mechanism between two cloud environments, namely Amazon and Azure, that both

have compute and storage components.

Page 17: Cloud Interoperability

Virtualization Layer

• Provides a federated interface

• Level of standardization: level of complying with federated interface

• Extending to the cloud:

– Exchanging metadata

– Exchanging configurations

– Security requirements

Page 18: Cloud Interoperability

Cloud Service Bus

8

middleware. Communication between each Cloud platform and ESB is through a

proxy called service component. Implementation of this proxy is the minimum

requirement to connect to ESB. In other words, service component is an

implementation of federation interface [19]. Figure 4 illustrates the architecture of

using service repository and registry in ESB model to bring more flexibility to the

ESB model.

Fig. 4. Sample registration, discovery, and flow of information through ESB (Source:

Grammatikou et al., 2011)

5. Conclusion and Future Works

The interoperability is not a new issue and it led to lots of problems and

overworks before. There are lots of solutions proposed for bringing

interoperability to different aspects of Cloud such as physical, data, and semantic

context. In the context of data interoperability, using the concept of Enterprise

Service Bus is one of the most viable solutions. ESBs can help well established

but not interoperable Cloud platforms connect to each other and share resources.

Moreover, using composite service architecture increases the ability to have

platform agnostic, configurable service bus.

ESBs can be placed as a middleware between different platforms and act as a

translator between them. They can implement transportation protocol conversion,

message routing, and data mapping, as well as providing message security and

monitoring mechanisms.

Page 19: Cloud Interoperability

Conclusion

• In near future, there won’t be any standard API from business vendors,

• Standardization will be community based,

• Too soon for semantic interoperability,

• Intermediary stack is a viable answers,

• The next step is to develop domain driven semantic schemas

Page 20: Cloud Interoperability

Thank You.

Page 21: Cloud Interoperability

References

• 1. Carraro G, Chong F (2006) Architecture Strategies for Catching the Long Tail. Microsoft Developer Networks.2. Mell P, Grace T (2009) NIST Definition of Cloud Computing. National Institute of Standards and Technology,

• 3. Corp. D (2011) Dell Unveils Industry’s First OpenStack Infrastructure-as-a- Service Cloud Solution. Dell.4. Hirschfeld R (2011) Unboxing OpenStack clouds with Crowbar and Chef [in just over 9,000 seconds! ]. Agile in the Cloud.

• 5. Armbrust M, Fox A, Joseph AD, Kats RH, Konwinski A, Lee G, Patterson DA, Rabkin A, Stoica I, Zaharia M (2009) Above the Clouds: A Berkeley View of Cloud Computing. University of Berkeley, California6. Directorate-General E (2003) Linking up Europe: the importance of interoperability for e-government services. The Commission of The European Communities,

• 7. Teixeira T, Malo P, Almeida B, Mateus M (2011) Towards an Interoperability Management System. Information Systems and Technologies (CISTI):1-48. IEEE (2011) IEEE Guide for Smart Grid Interoperability of Energy Technology and Information Technology Operation with the Electric Power System (EPS), End-Use Applications, and Loads. IEEE Std 2030-2011.

• 9. Robinson R (2004) Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture, Part 1. IBM Developerworks.10. Bean J (2009) Enterprise Service Bus. In: Service Interface Design. Morgan Kaufmann, p 10

Page 22: Cloud Interoperability

References

11. Lou M, Goldshlager B, Zhang L-J Designing and implementing Enterprise Service Bus (ESB) and SOA solutions. In: IEEE International Conference on Service Computing, 2005. IBM Global Services,12. Jizhe L, YongJun Y Research & Implementation of LightWeight ESB With Microsoft .NET. In: International Conference on Frontier of Computer Science and Technology, 2009. 13. Wu J, Tao X Research of Enterprise Application Integration Based-on ESB. In: 2nd International Conferance on Advanced Computer Control (ICACC), 2010. 14. Webber J (2005) ThoughtWorks. Guerrilla SOA.15. VMWare (2012) Multi-Language, Multi-Framework, what about Multi- Cloud? VMWare, 16. Fielding RT Architectural Styles and the Design of Network-based Software Architectures. In, 2000. UC Irvine, 17. Pouli V, Demchenko Y, MarinosC., Lopez DR, Grammatikou M Composable Services Architecture for Grids. In, 2011. Computer Communications and Networks, pp 223-24718. Demchenko Y (2011) Composable Services Architecture (CSA). OGF, 19. Grammatikou M, Marinos C, Demchenko Y, Lopez DR, Dombek K, Jofre J (2011) GEMBus as a Service Oriented Platform for Cloud-Based Composable Services. Third IEEE International Conference on Coud Computing Technology and Science