Confcall-prot-17aug05
From GEANT2-JRA1 Wiki
Contents |
Agenda
- Lookup Service Discussions - read the Lookup Service Implementation document
- XML database technology Evaluation progress (MG) - Data storage possibilities for LS
- LS component design discussions - discussion on model to be used and whether generic service design needs a revisit
- LS protocol disucssions - go through paris discussions on contents of messages and reach an agreement for phase 0
- Discussions on usage of identical schemas for storage and messages
- Rich's questions during previous call (LS and topology - impending problems)
- Multiple data responses problem
- Discussion on MA as operational service
- Missing functionality
- Different approaches to complete
Minutes
Attendees
Martin Swany (UoD)
David Schmitz (DFNm)
Loukik Kudarimoti (DANTE)
Jeff Boote (I2)
Szymon Trocha (PSNC, scribe)
Roman Łapacz (PSNC)
Maciej Głowiak (PSNC)
Rich Carlson (I2)
Discussion
MG started with desribing evaluation of data storage possibilities for Lookup Service. He compared eXist databse with Berkley DB XML and relational DB like Postgress or MySQL (summary available). He thinks eXist is more advanced than Berkley DB and more flexible than SQL datbases. He tested xquery XQuery and XPath languages and they looked fine. He thinks we could use them for XML translations. Some test made by Jana showed problems with stability of eXist on Windows (pointer exception). MG added that the last stable version on eXist was very old and he suggested to use development version. He thinks it is stable enough for our deployment. He also tested XML DB API for eXist and it worked. RL noticed that eXist should be used on Linux platform. MG commented that it was a Java-based software thus it could work on each platform but on Windows some problems had been encountered. MG added that Berkley DB was a stand-alone library. It is not a client-server DB and has library written in C++ and directly linked to the application. But he didn't tested it. MG said one can access data from eXist using SAX too. It needed Web container.
ST asked whether we could already choose a DB for Lookup Service or it needed some more work. MS said that evaluation helped him to decide using eXist for the next phase. He thought it integrated well with perfSONAR environment.
The group decided to use eXist for Lookup Service.
LK introduced to LS component discussion about what kind of component should the group use: the one that had been defined as generic or use something else. He thought the answer laid with the design choice the group had made: whether we were going to convert everything from XML to Java objects and Java object to XML for XML DB query or we wanted to adapt different model. If we decided on that part we could decide on it fairly easy. LK asked if anybody had comments about converting XML into Java object like we did in MA ServiceEngine. MS though we couldn't get rid of it sometimes but he would like to think on a long term how we could minimise it as this was an performance issue. LK said that from the performance point of view we would probably have to support different models. The reason was that maybe simple queries might be satisfied by just not converting into XML but if we wanted to provide the same functionality we wanted to provide for Lookup Service in the future we would need to convert into Java object. MS agreed.
LK said that for phase 1 we wanted to deregister and lookup. Registration involves checking to some extent the content of registration (what information has bene passed). He felt that we would need convertion into Java objects in order to have the conversion properly done. MS said that with different schema approach it would be simple. All the checks we would need to apply could be done on the schema level. He believed we could handle lookup and query directly against XML database. XML schema language provides amasing power in terms of constraining. LK still thought information should have been handled by Java objects. For example check for values which are empty (not null). He asked if we use the schema which is much more open and all the checks had to be done in the application logic. He saw that the approach we had been using until now were not the same approach that we had used in schemas elsewhere. LK asked what about schemas for each service e.g. for MA service we might need to do different kind of validation and MP service another kind. MS answered it would be a good argument to use different schemas in different places. LK asked if we did that we had to talk about technological feasibility to deal with that kind of situation. Whether we could decide on run-time what schema to be used. MS answered than rather by component not real-time. MG asked if others thought about XSSLT (XML transformation language). If we had request in XML and wanted to store data in other XML and between two points we wanted to check if data was correct we could use it. eXist can support XSSLT and there is also a library for Java. RL added that if we wanted to use existing generic service we should take convertion to java objects but if not we could omit this conversion. LK commented we would need to convert. We need to think for phase 1 where Lookup Service is more simplistic which approach to take: converting or just XML. In future we would rather prefer to use both. MS agreed.
The group decided for phase 1 to use translation to Java objects (but support not doing it in future) and try to stick to generic service components we have defined.
LS protocol discussion. The group started to work on that during meeting in Paris (LS protocol). LK asked JB who had been absent then if he had any comments. He agreed with the content of what the request had to contain.
The group agreed on the content of messages proposed during the meeting in Paris.
Discussion on usage of identical schemas for storage and messages. RL said he didn't analysed documents sent by MS and JZ and asked MS to explain them. MS said the key question was how to relate the service metadata that described the given MA service with measurement metadata. He thought of having data section for service data that contained metadata. He thought it made sense what Lookup Service was really representing: here is an Measurement Archive, here is what that Measurement Archive told me it had. RL asked if MS had considered putting characteristic element outside of metadata block and chaining it to other metadata block (as RL did in his example sent to the mailing list). MS answered that use case i.e. the characteristic represented in a chained metadata was actually reflected in the config file right now. RL asked if he could update CVS with such example to see the use case where we could have many characteristics for one service. MS would say many characteristics for one interface. He believed that characteristic belonged to metadata block chained together with the one describing interface. It's all about many characteristics for a given interface, many interfaces in a single 'Measurement Archive service.
LK asked MS for clarification: service description would be in metadata section, generic service information and measurement information would be in data? MS confirmed there would be metadata contained within data. LK asked whould should data section contain metadata? MS explained that case: here is a measurement service, this measurement service has data and the data that it has is described by this metadata.
RC explained his concerns about what Lookup Service would send back: an unordered or ordered of Measurement Services. JB said in phase 0 we should send the whole list not trying to do any topology related things. He added Topology Service hadn't been something to implement algorithms. JB said it would be much easier to add new topology algorithms if it was done in the client and it would be much easier to support the same topology algoithms if it was in the server.
Conf call ended at 17:00 CEST.
Download to listen to this conf call
Back to JRA1 events
