1 / 28

Cyberinfrastructure Case Study: The New Bioworkbench

Adam Birnbaum. Cyberinfrastructure Case Study: The New Bioworkbench. 27 August, 2004. Intro: Bioworkbench Project. Pilot project to study Service Oriented Architecture & Web Services Modernize the Bioworkbench This is very much a work in progress!. The Bioworkbench.

nerea-atkins
Download Presentation

Cyberinfrastructure Case Study: The New Bioworkbench

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. Adam Birnbaum Cyberinfrastructure Case Study:The New Bioworkbench 27 August, 2004

  2. Intro: Bioworkbench Project • Pilot project to study Service Oriented Architecture & Web Services • Modernize the Bioworkbench This is very much a work in progress!

  3. The Bioworkbench • Free! for education and research users • Features • Search public databases for sequences (NDJINN) • Manage personal collections of sequences • Run popular analysis tools • Architecture • Main CGI program written in C • Bio codes wrapped with Perl • Everything runs on the web server http://workbench.sdsc.edu

  4. Bioworkbench • The good: • Many mirrored databases • Personalized collection of sequences • Large set of available tools • The bad: • Hard to search through lists of apps & databases • Expansion requires coding Perl wrappers • All built to run on a single machine • The ugly: • Is a 1995 CGI application (and looks like it!)

  5. Bioworkbench: Demo http://workbench.sdsc.edu

  6. New Bioworkbench: Key Requirements • Modern, flexible, intuitive web user interface • User unaware of computational resources • Add analysis tools & databases without modifying the web application • Technical requirement: explore Service Oriented Architecture.

  7. User Interface • Created storyboards • Focus groups with users at SIO • Input and feedback from Cherri Pancake Main metaphor: web email client

  8. Service Oriented Architecture (SOA) • Decompose program into distributed services • Use standard messaging/invocation protocols • Dynamic discovery and invocation

  9. User Interface Service Registry Service 1 Service 2 Service 3 Service Oriented Architecture looks up services invokes invokes invokes Invocation through DCOM, CORBA, Web Services…

  10. User Interface UDDI Registry Service 1 Service 2 Service 3 Service Oriented Architecture built with Web Services UDDI SOAP messages SOAP SOAP SOAP

  11. Web Services • Standards by W3C and OASIS • Message format: SOAP • Interface description: WSDL • Registry interface: UDDI (Universal Discovery Description and Integration) • WS-Interoperability, WS-Security, WSRF, WSRP, WS-Context… • Free servers: Tomcat/Axis, JWSDP • Stable Java APIs: JAX-RPC, JAXR, WSDL4J, SAAJ, JAXP

  12. User DB User Interface (Struts on Tomcat) Service Registry Genbank Sequence Query Service BLAST SWISSPROT tmhmm EMBL … New Bioworkbench Architecture store user data looks up services queries invokes invokes invokes

  13. SOA Challenges • Registry Server • Dynamic Invocation • Data Type Management • Dynamic UI Generation

  14. Challenge 1: Registry Server • Requirement: store and query invocation info: • Input and Output Data Types • Service port, operation, uri • Categorization(s) • UDDI advantage: it's standard. • UDDI disadvantages: • Unnecessary complexity • Hard to find solid, free implementations (jUDDI, Sun's RS)

  15. UDDI Technical White Paper, http://www.uddi.org/whitepapers.html

  16. WSDL to UDDI Mapping Understanding WSDL in a UDDI registry, P. Brittenham et al on IBM developerWorks

  17. Registry Server: our Current Approach • Build interfaces using RDBMS for persistence • Incorporate UDDI 'later' if really required

  18. Challenge 2: Dynamic Invocation • Options for invoking web service: • Pre-compiled stubs (java2wsdl & wsdl2java) • Dynamic invocation • Our requirement: incorporate new services without recompiling the application • JAX-RPC includes API's for invocation (DII) • Our current approach • Store all info required for invocation in RDBMS • Use DII Call object for invocation. • Special problem: input and output data type management

  19. Service Registry Challenge 3: Data Type Management User Interface (initializes input, interprets & displays output) Fetch data types invokes Service Challenge: dynamically create objects in webapp/UI to gather & send input, and to correctly typecast output.

  20. Data Types • Idea: use XSD's from Registry Server to dynamically generate Java classes • Open source projects: Castor, XMLBeans... • Problem: need do it without recompiling webapp. • Current approach: dynamically load .class files provided by service author.

  21. Challenge: Dynamic UI Generation • Need to invoke services without recompiling UI • Possible solutions: • WSRP • Automatically generate UI using reflection API on inputs & outputs

  22. Remaining Work • Add more data sources (EMBL, Genbank) • Complete dynamic invocation system • Build dynamic UI system • Wrap bio apps as web services • Deploy

  23. Lessons Learned • UDDI, and the mapping of WSDL to UDDI, is too complex • Writing web services is easy; deployment is tricky(tomcat, axis, postgres, webapp deployment) • This is better than the Perl implementation... how?

  24. Acknowledgements UI Design, Focus Groups: Mike Cleary Architecture, built the UI: Kevin Fowler Architecture, built data services: Jesus Castagnetto Worked on Proposal: Mike Cleary Greg Quinn Chris Smith Hannes Niedner Information, support, and brainstorming: Brian Saunders Roger Unwin Andreia Maer Cherri Pancake

More Related