Hi Morris, David, Yes, of course. In addition (or inclusive of this), it could also eventually become a vehicle for verification of PGI-WG outputs (profiles, etc.) as the middlewares adopt them. There are many possibilities, and as this is already a long email I'll only focus on a few for now... As Morris very rightly suggests, the demo needs to be easily usable by others, with a low preparation overhead, also focusing on stability and maturity. I'm planning to upload the demo to GIN-CG's OGF Forge this week - at least a preliminary upload, with short minor commits next week to clean up the code base. It already goes some way to being an approachable system to download, configure and run, but needs a bit of work. Since there are many ways in which the demo could be extended, I think we'll need to consider how best to include any extensions as they are developed, without sacrificing current functionality, usability and stability. Currently, the demo is written in Perl, since it's very easy to deal with command line invocations and is quick to develop and extend, but currently the code is quite monolithic, but with partial comments. Modularisation of the code base could be a logical first step, and would facilitate distributed development and extensibility. This would enable generalisation of the application used ('Minem' at the moment), and configuration for utilising other (emerging) specifications and profiles. And of course, the general approach of the demo could be applied to other languages, such as Java, if desired. As David suggests, it would be a good idea to position it as a test framework of HPC-BP services in a 'compliant-like' way. At the moment, it only utilises CreateActivity / GetActivityStatuses operations - it's service response parsing is quite naive at the moment (after all, it is only a demo!). So, as it stands it's very much an application-oriented demonstrator that provides just an indicator of basic compliance, but there's no reason why parsing completeness (from a service response perspective) couldn't be extended, and also use the other methods on the BESFactory porttype - TerminateActivities, GetActivityDocuments and GetFactoryAttributesDocument for example. The latter two could be done for each endpoint prior to running the actual application part of the demo, for instance. One of the major strengths of this activity has been the willingness of participants to assist and provide endpoints, as they have for previous interop testing. This is really the foundation for its success so far. Building on this, and looking to the future, it would be great if we could try to secure (what do others think?): - A commitment from middleware endpoint providers to provide and maintain endpoints would be ideal for both demonstrating and development. To what extent is this practical? - For greater credibility, actually having endpoints provided on proper DCI's also seems compelling (as we have with GridSAM on the UK NGS). At least from my experience, security trust configuration is always an issue - ironically perhaps, the basic standards interop testing is quite straightforward :) In terms of security, would it be a good idea to move away from UsernameToken support and move towards X509 certification? This is more in line with how the infrastructures are deployed in a production sense, so keeps the security configuration more simple and more realistic. My apologies for the long email - but hopefully a starting point for further discussions. Any thoughts very welcome! Cheers Steve David Wallom wrote:

Hi Morris,

I completely agree that this should become a key function of the GIN group, I would as I suggested during the standards AH suggest that this could also become a sort of compliance system for HPC-BP.

David

On 16/03/2010 08:06, "Morris Riedel" <m.riedel@fz-juelich.de> wrote:

...

Hi folks,

I had some discussions with several people here at OGF and we thought that it makes sense to have at least one telcon per month under the GIN umbrella to keep the HPC-BP demonstration alive and discuss possible extensions in terms of middlewares/standards/applications. One aim of this would be to make the demo more mature and stable in order to show it at numerous events w/o high preparation efforts.

Before I will ask for a specific date I'm open to hear your opinions on this and/or any further suggestions.

Take care, Morris

------------------------------------------------------------ Morris Riedel Distributed Systems and Grid Computing Division

Jülich Supercomputing Centre (JSC) Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel

-- Dr Stephen Crouch, Software Architect, OMII-UK, Electronics and Computer Science, Room 4067, Level 4, Building 32, University of Southampton, Highfield, Southampton SO17 1BJ Tel: +44 (0)23 8059 8787 EMail: s.crouch@omii.ac.uk Fax: +44 (0)23 8059 3045 WWW: http://www.ecs.soton.ac.uk/~stc