1 / 19

Analysis of Potential Role of ESB in caGrid Infrastructure

Analysis of Potential Role of ESB in caGrid Infrastructure. What Isn’t an ESB. Interoperability Silver Bullet Answer to Prayers Road to Enlightenment “Easy Button” SOA in a Box “42”. What is an ESB. Plumbing Harness Integration and Adapter Engine for heterogeneous services and systems

nevada-kirby
Download Presentation

Analysis of Potential Role of ESB in caGrid Infrastructure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Analysis of Potential Role of ESB in caGrid Infrastructure

  2. What Isn’t an ESB • Interoperability Silver Bullet • Answer to Prayers • Road to Enlightenment • “Easy Button” • SOA in a Box • “42”

  3. What is an ESB • Plumbing Harness • Integration and Adapter Engine for heterogeneous services and systems • Deterministic router/traffic-cop for multi-step processes.

  4. Capabilities Required by caGrid • The following capabilities are important for the caGrid to be able to continue to meet potential future needs of the caBIG program • Interface and Protocol Translation: provides adaptability to other systems • Orchestration/Routing: provides support for complex repeatable business process • Transaction Management: provides reliable process interoperability • Common Services: re-usable capabilities made available using standardized mechanisms • Grid Service Activity Monitoring: provides insight into service’s operational health and status in real-time • De-Coupled Service Implementation: provides for flexibility in deployment of services across the grid

  5. Interface and Protocol Translation • Vital to support interoperability between caGrid services and those not based on caGrid (ex EHRs). • FROM caGrid Service TO non-caGrid Service • FROM non-caGrid Service TO caGrid Service • Would include mitigation/translation between different schemes for • Message payload implementation • Security implementation and policies • Remotable mechanisms • Questions/issues • Can generic/reusable/config based components (or constrained set) be created for each from->to pair • Possible variations for different security mechanisms • Potential semantic and syntactic incompatibilities • Alternative to ESB is to create wrappers on an “as-needed” basis.

  6. Orchestration/Routing • Routing a message through N additional service invocations to create a multi-step process • Routing can be based on • Static rules defined during process design time • Run-time rule evaluation results based on message content • The capability is a foundation for other higher level capabilities (ex Transaction Management). • Questions/Issues • Do reusable multi-step biz processes exist outside of clinical trial’s world? • Executable orchestration definitions usually require developer-like skills (BPEL) and shims/adapters between services • Currently there are a 2 or orchestration/workflow capabilities in caBig (Taverna, ActiveBPEL) that don’t require an ESB. What does the ESB provide?

  7. Transaction Management • Transaction Management treats a process involving multiple service invocations as a single transaction • Capability is possible through use of orchestration/routing capabilities. The transaction rules are part of the defined orchestration rules. • Question/Issues • Requires participating services implement proper transaction logic including possibly compensating transactions for insert and update processes • Most caGrid services are read only and don’t require transaction support • Such capabilities already exist with ActiveBPEL and Taverna. What does the ESB add?

  8. Common Services • ESB nodes could host reusable services for standard run-time tasks • Message Transformation • Message syntactic and semantic validation • Auditing/logging of messages traffic • Pub/Sub “drop box” for distribution of scientific information • Could Move some caGrid infrastructure services inside of an ESB • Index, BPEL Engine/ActiveBPEL, Taverna, CDS, CSM, GTS, Grouper (for sub-grids) • Simplifies deployment and maintenance of caGrid infrastructure • Best suited for JBI Based solutions • Questions/Issues • Would require developing some new services that don’t already exist and/or converting others to live in and ESB container • Would be based ESB based distributed interoperability architecture approach that requires services to operate through an ESB • Would require routing/orchestration to take advantage of common services.

  9. Grid Service Activity Monitoring • Ability to monitor service endpoints • Abstracts health and status update mechanism from underlying service implementations. • Provide intra-grid activity metrics • Ability to add additional monitoring capabilities without changing the underlying services • “Big Picture” of current grid-network status beyond up or down services • Questions/Issues • Would be based ESB based distributed interoperability architecture approach that requires services to operate through an ESB • Too “big brother-ish” for participants?

  10. De-Coupled Service Implementation • Current implementation requires knowledge of the EPR where the service producer is physically running. If EPR is changed then any consumer will break • ESB can provide a proxy “always-there” EPR that consumers use. De-couples logical EPR from physical EPR. • Allow support multiple versions of a grid service to co-exist within a given organization. • Can include endpoint proxies for central caGrid infrastructure services (caDSR, Index, EVS, GME, …) that other caBIG systems rely on. • Questions/Issues • Installation and config will be specific for each ESB node. Who does what and who manages and maintains over time? • Would be based ESB based distributed interoperability architecture approach that requires services to operate through an ESB • Could be done using other proxy mechanism (context switches, web servers, …).

  11. Conclusions • Any one of the desired capabilities could be implemented by alternative mechanisms, however an ESB based solution offers a single integrated delivery solution • A hybrid infrastructure (some grid service behind an ESB, others not) is technically feasible, however some grid wide capabilities would be lost • A full ESB based distributed architecture for intra-grid interoperability presents a large change from the current caGrid infrastructure, however provides a well defined path for future caGrid extensibility

  12. ESB Based Distributed Interoperability Arch (caGrid X)

  13. caGrid X Basic Components

  14. caGrid X - Option 1

  15. caGrid X - Option 1 • caExchange becomes part of the caGrid infrastructure • Grid is based on WSRF/Globus tech stack. Proxy/Adapters required to put non-WSRF/Globus service on grid • Monitoring tools are TBD depending on CBIIT needs • Potential to move some caGrid infrastructure common services to be run inside the ESB as JBI components • Pros • Maximizes reuse of existing caGrid/caBig investment • Cons • Limits extensibility and adaptability to ability to “wrap” non WSRF/Globus based services. • caExchange is still rather “raw” from a extensibility and maintainability as it rides directly on top of Apache ServiceMix with little tooling support.

  16. caGrid X - Option 2

  17. caGrid X - Option 2 • Migrate inter-grid interoperability to standard WS-I Basic Profile 1.2 • Create Adapter/Proxy for WSRF/Globus based services. TBD if a single adapter/proxy is possible or one for each service • Requires new Service Registry/Repository based on UDDI but still supporting needed real-time service health and status use cases. • Suggest using an open source, but commercially supported ESB (ex GlassFish ESB, Fuse, ChainBuilder,…) because of generally better tooling and documentation support. • Possible re-use GAARDS for security mechanism • Monitoring tools are TBD depending on CBIIT needs • Pros • Assuming greater potential extensibility/expandability due to basing on WS-I BP 1.2, including bridging to other grids/networks • Lots of existing tooling for creating WS-I BP 1.2 web services • Cons • Substantial change in technical direction that will require re-engineering of many caGrid implementations

  18. caGrid X - Option 3

  19. caGrid X - Option 3 • Same basic technical pros and cons as Option 2 • Potentially provides a path from caBIG to BIG Health??? • Could provide standardized integration patterns between caBig scientific systems and patient care systems. • Pros • Could helps establish caGrid as the defacto research “network within a network” for HHS? • caGrid lessons learned could help shape NHIN technical direction/implementation (ex constrained semantics approach) • Greater sharing of common efforts (ex security policy and implementation) • Potentially help penetration of both NHIN and caBIG into different organizations. • Could leverage NHIN’s planned product support for the Fed Connect Gateway • Cons • Would tie some aspects of caBIG infrastructure to the programmatic needs and timings of NHIN/FHA • Some policy differences may be non-resolvable from a business needs aspect

More Related