Integration Architecture & (Hybrid) Cloud Scenarios on the Microsoft Business Platform. Gijs in t Veld CTO BizTalk Server MVP BTUG NL, June 7 th 2012

Size: px

Start display at page:

Download "Integration Architecture & (Hybrid) Cloud Scenarios on the Microsoft Business Platform. Gijs in t Veld CTO BizTalk Server MVP BTUG NL, June 7 th 2012"

Marvin Barton
8 years ago
Views:

1 Integration Architecture & (Hybrid) Cloud Scenarios on the Microsoft Business Platform Gijs in t Veld CTO BizTalk Server MVP BTUG NL, June 7 th 2012

2 Agenda Integration architecture; what & why? On-premise integration middleware Cloud integration middleware Hybrid integration solutions The future of integration with Microsoft Future proof integration architecture guidance Challenges & opportunities Questions

Enterprise Integration Landscape PARTNERS ENTERPRISE Manufacturer Cloud CRM Call Center Composite Apps Web Apps Human Workflow Cloud App SQL Azure INVENTORY ERP FINANCE Cloud App SQL

3 Enterprise Integration Landscape PARTNERS ENTERPRISE Manufacturer Cloud CRM Call Center Composite Apps Web Apps Human Workflow Cloud App SQL Azure INVENTORY ERP FINANCE Cloud App SQL Azure Retailer CRM SQL Server Windows INVENTORY Oracle Solaris OPERATIONS NETWORKING Cloud App (BI) Oracle DB Unix SQL Server Windows DB2 Z/OS SQL Azure SMART DEVICES OTHER EVT SRC RFID DEVICES

Enterprise Integration Landscape PARTNERS Manufacturer ENTERPRISE Cross Organization Messaging Cloud CRM Call Center Composite Apps Presentation Integration Web Apps Human Workflow Cloud App SQL

4 Enterprise Integration Landscape PARTNERS Manufacturer ENTERPRISE Cross Organization Messaging Cloud CRM Call Center Composite Apps Presentation Integration Web Apps Human Workflow Cloud App SQL Azure INVENTORY B2B Integration Retailer (BI) Process Automation CRM Data Integration (ETL) Oracle DB Unix ERP SQL Server Windows INVENTORY SQL Server Windows FINANCE App Integration Oracle Solaris OPERATIONS DB2 Z/OS Cloud App Integration Cloud App SQL Azure NETWORKING Cloud App SQL Azure SMART DEVICES Complex Event Processing OTHER EVT SRC RFID & Sensor Integration RFID DEVICES

5 Evolution of integration patterns

6 On premise integration middleware BizTalk Server Messaging middleware ESB A2A B2B SQL Server Integration Services (SSIS) Bulk data transfer ETL Windows Server AppFabric / WCF Simple, light-weight integration BizTalk LOB Adapter Pack Simple LOB integration

7 Cloud integration middleware Windows Azure Service Bus Part of the Azure platform (PaaS) Simple, message based integration Transformation capabilities Low latency (in memory pub/sub) B2B capabilities (labs only for now) With Service Bus, Microsoft has made significant strides towards delivering the ESB pattern at Internet scope. Source: Microsoft (2011) Rumors BizTalk in persistent VM (IaaS)

8 When to use what On-premise For integration of on-premise applications and services On-premise ESB A2A Cloud For integration of cloud applications and services PaaS: Use integration components to build custom made software hosted in Azure SaaS: Integrate your SaaS applications (CRM Online, SharePoint Online, SalesForce, etc.) B2B Use it as a huge DMZ

9 Hybrid scenarios SaaS or PaaS needs to connect to on-premise applications and services On-premise applications need to integrate SaaS or PaaS based applications and services B2B integration offloaded to PaaS The widely anticipated hybrid cloud pattern will likely be implemented using integration technology, rather than reliance on homogeneity across private and cloud data centers. Source: Gartner (2011)

10 Future of integration with MS One workflow engine (instead of two: X/LANG in BizTalk and WF in.net) One toolset for development, deployment and management of integration solutions One hosting container, available in public cloud, private cloud and on-premise Enabling low latency and high throughput / volume solutions Alignment of Service Bus and ESB across platforms Provide BAM and Business Rule Engine (BRE) across platforms Re-usable.Net components, attractive to both integration specialists and developers

11 Future proof integration Gartner says invest in SOA knowledge 8 Principles of Service Design (Thomas Erl) Reusability Services contain and express agnostic logic and can be positioned as reusable enterprise resources (think about the future uses and make them generic) Autonomy Services exercise a high level of control over their underlying runtime execution environment (there are no other services making use of the underlying components) Discoverability Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted (if nobody knows about the existence of services, they will never be re-used) Composability Services are effective composition participants regardless of the size and complexity of the composition (break-up larger components into smaller, more manageable and composed ones) Loose coupled Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment (contract-first development of services; don t generate contracts) Abstractness Service contracts only contain essential information and information about services is limited to what is published in service contracts (the contract does not contain system level information on underlying systems) Standardized Service Contract Services within the same service inventory are in compliance with the same contract design standards (by using a uniform language and applying standards notations for creating contracts, discoverability, reliability and application of governance of services will improve) Statelessness Services minimize resource consumption by deferring the management of state information when necessary (keeping excessive state can undermine the availability and scalability of services)

Other future proof integration tips Only write code when absolutely necessary Canonical Data Model Pros Domain separation Less maps BAM easier BRE easier Better exception

12 Other future proof integration tips Only write code when absolutely necessary Canonical Data Model Pros Domain separation Less maps BAM easier BRE easier Better exception handling Loose coupling Cons A bit more up-front work Indeed have an architecture and use known patterns and best practices (also check out Enterprise Integration Patterns book)

13 Federated ESB IBM: Service specification and implementation are governed at the domain level, with a degree of centralized governance to enable cross-domain service reuse and interoperability

14 Federated ESB models Brokered ESB One master ESB determines where to route requests Offers bridge services Connected ESB Each ESB has its own service registry Service registry visible to all ESBs Reflects the service s affinity for one of the ESBs Each ESB is responsible for connectivity in its own domain and routes service requests to other ESBs if these services are not available in its own domain

15 Hybrid challenges & opportunities Challenges: Deployment is not next-next-finish End-to-end monitoring Supportability Latency Opportunities: Integration won t go away, will even become more important Value add on top of standard, mass market SaaS and PaaS applications will come from smart integration Integration knowledge is going to be a key success factor

16 Full article available in April issue of ServiceTechMag.com and on motion10.com/bibliotheek

Client. Applications. Middle Tier. Database. Infrastructure. Leading Vendors

Client. Applications. Middle Tier. Database. Infrastructure. Leading Vendors Client Applications Development Management Middle Tier Database On Premises Infrastructure Cloud Leading Vendors PC, Phone, Browser Your business applications Running on the Microsoft Application Platform