Enterprise Service Bus Architecture
  as a Cloud Interoperability and
    Resource Sharing Platform
        Amirhossein Mohtasebi
Agenda
•   Cloud
•   Interoperability
•   Interoperability in the Cloud
•   Light-weight binding
•   Cloud Service Bus
Cloud
• Characteristics:
  – Unlimited pool of resources
  – Per use pricing model
  – Geographically distributed
  – Instant provisioning and configuration
  – Great extent of virtualization
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”
Cloud Interoperability
• Portability and Mobility
  – Virtual Machine (VM) format
  – Hardware requirements
  – Metadata
  – IP
  – Subnet
• Example: Azure Redundancy vs. AWS
Close vs. Open
– Business Acceptance
– Customer Lock-in
– Resource Sharing
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
Cloud Interoperability
Physical Layer

• Hardware, Software, Platform, VM

Data Layer

• Data Format, Data Type, Validations

Semantic Layer

• Data Context and Domain
Current Efforts
– Cloud Computing Interoperability Manifesto
– OpenStack, OpenNebula, etc
– OVF, CDMI
– Supporting Multiple Languages
– Supporting Standard API
– Open Platforms (Cloud Foundry)
Location Decoupling


 Application              Application

   Heavy
                    Light-Weight Binding
Dependencies
               Platform     Platform    Platform
  Platform         A            B           C
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)
Location Decoupling
   – Security
          •   oAuth
          •   Claim Based Authentication
          •   Kerberos
          •   Role/Right based Authorization
   – Monitoring and Management
      • Auditing
      • SLA
      • QoS
      • Billing


• Cost?
Location Decoupling
• Changing the application level to implement
  location decoupling?
  – Another level of customer lock-in


• Extracting light-weight binding + Composable
  Middleware + Standard API?
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
Cloud Orchestration Architecture
• The arrangement, coordination and
  management of cloud infrastructure to
  provide services to meet IT and business
  requirements.
• Functions:
  – Intermediate
  – Aggregate
  – Arbitrage
to unlimited Cloud environment.


Cloud Orchestration Architecture
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
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.
                     Cloud Service Bus




Fig. 4. Sample registration, discovery, and flow of information through ESB (Source:
Grammatikou et al., 2011)
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
Thank You.
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,
    California
    6. 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-4
    8. 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
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-247
18. 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

Cloud Interoperability

  • 1.
    Enterprise Service BusArchitecture as a Cloud Interoperability and Resource Sharing Platform Amirhossein Mohtasebi
  • 2.
    Agenda • Cloud • Interoperability • Interoperability in the Cloud • Light-weight binding • Cloud Service Bus
  • 3.
    Cloud • Characteristics: – Unlimited pool of resources – Per use pricing model – Geographically distributed – Instant provisioning and configuration – Great extent of virtualization
  • 4.
    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”
  • 5.
    Cloud Interoperability • Portabilityand Mobility – Virtual Machine (VM) format – Hardware requirements – Metadata – IP – Subnet • Example: Azure Redundancy vs. AWS
  • 6.
    Close vs. Open –Business Acceptance – Customer Lock-in – Resource Sharing
  • 7.
    Current Situation • Thereis 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
  • 8.
    Cloud Interoperability Physical Layer •Hardware, Software, Platform, VM Data Layer • Data Format, Data Type, Validations Semantic Layer • Data Context and Domain
  • 9.
    Current Efforts – CloudComputing Interoperability Manifesto – OpenStack, OpenNebula, etc – OVF, CDMI – Supporting Multiple Languages – Supporting Standard API – Open Platforms (Cloud Foundry)
  • 10.
    Location Decoupling Application Application Heavy Light-Weight Binding Dependencies Platform Platform Platform Platform A B C
  • 11.
    Location Decoupling • HeavyDependency 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)
  • 12.
    Location Decoupling – Security • oAuth • Claim Based Authentication • Kerberos • Role/Right based Authorization – Monitoring and Management • Auditing • SLA • QoS • Billing • Cost?
  • 13.
    Location Decoupling • Changingthe application level to implement location decoupling? – Another level of customer lock-in • Extracting light-weight binding + Composable Middleware + Standard API?
  • 14.
    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
  • 15.
    Cloud Orchestration Architecture •The arrangement, coordination and management of cloud infrastructure to provide services to meet IT and business requirements. • Functions: – Intermediate – Aggregate – Arbitrage
  • 16.
    to unlimited Cloudenvironment. Cloud Orchestration Architecture
  • 17.
    Virtualization Layer • Providesa federated interface • Level of standardization: level of complying with federated interface • Extending to the cloud: – Exchanging metadata – Exchanging configurations – Security requirements
  • 18.
    implementation of federationinterface [19]. Figure 4 illustrates the architecture of using service repository and registry in ESB model to bring more flexibility to the ESB model. Cloud Service Bus Fig. 4. Sample registration, discovery, and flow of information through ESB (Source: Grammatikou et al., 2011)
  • 19.
    Conclusion • In nearfuture, 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
  • 20.
  • 21.
    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, California 6. 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-4 8. 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
  • 22.
    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-247 18. 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