WSMX Development Days Minutes 12/09/2005
From Wsmx-WIKI
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)
- Regsiter adapters (Through Web Service)
- 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
- Runtime Data Mediator
- 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)