WSMX Development Days Minutes 12/09/2005

From Wsmx-WIKI
Jump to: navigation, search

10am-11am


  • Tomas would like to see the structure of working groups (relation between SEE, WSMX and development team) on the website.
  • What is wrong:
    • Development Focus (need to be less theoretical and more practical)
    • Too much overhead, not enough functionality
    • Need a running version of WSMX on a server (both stable and latest)
    • 1 person should be in charge of each component
    • Need more people to contribute to components (based on man months)
    • Set of use cases that can be used with the running version of WSMX
    • One click for WSMX, One click for components
    • Clear requirements for components
    • Need to update the website (more information needed)
    • Dedicated software releaser
    • CVS changes all the time without dissemination
    • Third party versioning (might only be an issue with wsmo4j)
    • Execution semantics are too complicated and components are missing
  • What is right:
    • Love!!
    • Playground
    • Component oriented architecture makes life easier
  • What should change:
    • Decentralisation of releases
    • More attention to what is happening in wsmo
    • Iterations
  • What must change:
    • Web site
    • Documentation
    • Dissemination of Information (more publications)
    • Development required
    • 1 to 1 relationship between person and component responsibility
    • Better planning
    • Sexy use cases
    • More developers from inside and outside DERI

11am-12pm


  • WSMX and GRID
    • Website, documentation - up to date and user friendly.
    • Use case web site section.
    • Visibility of status of components
    • Use-case - Extract component requirements for milestones
    • Use Case -> Requirements -> Functionality

1pm-3pm


State of current components

  • Adapter Framework - Brahmananda
    • Regsiter adapters (Through Web Service)
      • To register an adapter you provide a jar file containing source code and description xml.
      • Dependancy is only on tomcat
      • public key returned on regsitration
    • Deregister adapters
      • provide public key returned at registry time
    • Invoke WSMX through adapter framework
      • implements the entrypoint interface from the integration API
      • provide message and mesage type
    • Documentation is 50% complete (completed by next week)
  • Core - Thomas
    • Consists of the microkernal and distribution architecture
    • Microkernal
      • Stable
      • Add bulletproofability
    • Distribution architecture
      • more likely to change
      • deals with multiple wsmx's each witha microkernal sharing components between them
    • Removed javaspaces dependancy, wsmx falls back to internal transport mechanism if no java space available
  • Communication Manager - Matt
    • two interfaces, recieve and invoke
    • Receive
      • Currently no implementation
    • Invoke
      • WSIF - not so good for complex data types
      • Reverted to SAAJ - SOAP message level (this is enough as we know all the info when the interface is invoked)
    • Grounding
      • Need to find a home
    • Need to add embedded Jetty server for web service interfaces
    • Dependancy on Choreography, Resource Manager, Execution Semantics
  • Execution Semantics - Maciej
    • complex execution semantics (workflows for all components)
    • theoretically should work, storeEntity execution semantic is tested (as mock ups are sufficient)
  • Resource Manager - Matt/Mick/Michal
    • WSMO Resource Manager created (needs testing)
    • WSDL resource manager needed
    • Mapping API Resource Manager needed
    • Heavy dependancy on MYSQL, should consider hsqldb
  • Triple Space Storage - Brahmananda
    • Supports store, get, query
    • Provide standard API for wsmx to invoke
    • Currently can only store triples (looking at ORDI)
    • Try to layer on hsqldb also
  • Discovery - Ed
    • Absolutely nothing of use
    • New document being started in WSMX WG
    • Existing keyword based discovery needs to be converted to the integration API format
  • Data Mediation - Adrian
    • Runtime Data Mediator
      • Instance Trsnaformation is possible as long as mappings exist
      • Storage needs to be organised
        • WSMX?
        • Ontotext Mapping Store?
      • Dependancy on reasoner, resource manager
  • Negotiation - Noone
    • Ruben and Holger are looking at it
    • Laurentiu's cluster will probably look at this
  • Selection - Mick
    • Deliverable will be written
    • maybe an implementation
  • Choreography - James
    • API and Object model exists (was in wsmx, now in wsmo4j)
    • Choreography Engine version exists (wsmo4j version issue)
    • Need to look at relationship with communication manager and grounding.
    • Need to look at interaction with Process Mediator
  • Process Mediation - Emilia
    • All documentation is ready to go
    • Implementation is not started yet (interface is complete)
    • Dependancy on Choreography engine (WSMO4J version issue)
    • will be developed by Emilia, Maciej and someone else
  • Orchestration - Sami
    • Information will come from DIP
    • Sami will be here by end of September
  • Security - Comments from Aine
    • Aine is working on a document which can be the basis for d13.15
    • Messaging security betwen WSMX and web services
      • Transport Level Security (SSL)
      • Message level Security (WS-Security)
      • Trust - certificates, WS-Trust
    • Security between WSMX and Components
    • Triple Space Security and Trust
  • Front-end - Mick/Adrian
    • Ontostar project is underway
    • Ontology Visualisation is complete (except attributes + parameters)
    • Chreography and LE Viz are next
    • SWT version of mapping tool nearly finished (needs to be integrated with wsmo studio)
    • Need WSMX communication component
    • Need monitoring tool
    • Need adapter man
  • Third Party Libraries
    • WSMO4J needs to be upgraded to 0.4.0 (once a stable 0.4.0)