Report from the PTF Fabrizio Pacini Datamat S.p.a. Turin, IT-CZ JRA1 meeting, 4-5 Nov 2004 Report from the PTF Fabrizio Pacini Datamat S.p.a. www.eu-egee.org EGEE is a project funded by the European Union under contract IST-2003-508833

Contents Introduction WSDL, WS-I, and Tools Common APIs Use Case with gLite APIs Requirements Procedure

Intro Meeting held on 14 Oct at CERN Focus on WSDL, tools and APIs Agenda and minutes available at: http://agenda.cern.ch/fullAgenda.php?ida=a044106 PTF Web Pages now available at: http://grid05.lal.in2p3.fr/svn/egee-ptf/index.html

WSDL, WS-I, and Tools (1/5) MEB and CL have done some work testing the various code generators against some example WSDL files to see what the various limitations are gSoap (2.6.2 and 2.7) for C/C++, Axis (1.1, 1.2RC1) for Java, SOAPpy (0.11.4) for python, SOAP::Lite (0.55, 0.60) for perl. All of the tests are in the EGEE CVS repository in the wsdl-test subsystem and can be checked-out in the standard way Consumer.wsdl (R-GMA), File Access Service (Data Mgt.) LB.wsdl (WMS). These are not the current versions but contain the majority of features required for our service APIs.

WSDL, WS-I, and Tools (2/5) All WSDLs have been modified to pass the WS-I tests and exist in both rpc/literal and document/literal versions Problems encountered: SOAPpy has some limitations in terms of the XML schema that it supports (problems with Consumer.wsdl) gSoap 2.6.2 and gSoap 2.7 work for rpm/literal WSDL files. gSoap 2.7 raises incorrect warnings about needing to reference "elements" when using a literal encoding although the generated code is OK. gSoap 2.6.2 does not handle document/literal WSDL bindings at all. with Axis 1.1 there is no way to have a working client/server which is also WS-I compliant Recommendation: Standardize on Axis 1.2RC1 and gSoap 2.7 Action (on MW cluster reps.): Try the Axis 1.2RC1 release to ensure that there are really no show-stoppers

WSDL, WS-I, and Tools (3/5) Encoding Both gSoap 2.7 and Axis 1.2RC1 support the document/literal format this brings up the question about which one to standardize on (or whether to standardize at all) rpc/literal is supported in .NET too, although with some restrictions. If we don't standardize on a document/literal format, then we should document the restrictions from .NET to try to avoid them if possible. Recommendation: WSDL definitions must be WS-I compliant. Developers may choose between rpc/literal or document/literal. With document/literal the operation name and request element name should match; i.e. be document/wrapped. We are going to have several common port types implemented by several different services Action (on CL): Investigate whether there are any problems with the code generators when mixing portTypes defined with different encodings.

WSDL, WS-I, and Tools (4/5) Python/Perl code generators The impression is that these are in a much more primitive state than the java and c++ tools. AF had some experience on the perl side and said that it was difficult to get it working, but that it does now. So at least there is a proof-of- principle that SOAP::Lite can be used on the client side. For python no one has yet had any experience with this WMS is directly affected by this: DTMT will determine whether the bindings generated with SOAPpy can be used for the EGEE WSDL service definitions and with the security framework Namespaces: what namespaces (in WSDL) should be used and how should they map into the standard code layout. CL will investigate with Alberto what conventions should be used for namespaces and circulate a proposal.

WSDL, WS-I, and Tools (5/5) The wsdl-test subsystem will be extended (by CL) to include a full example which contains the typical WSDL functionality needed The intention is to actually implement the necessary clients and servers to ensure that the full chain works in all of the languages Use of xs:import to import type definitions and wsdl:import to import WSDL definitions into a service definition Faults Complex type inheritance Definitions of simple types with restrictions, e.g. enumerations Arrays of both simple and complex types https (i.e. security)

Common APIs (1/3) The goal of this discussion was to identify common portTypes that are likely to be shared between many different services First one is delegation portType: Interface definition available in CVS JRA3 will be providing a standalone CGI script to implement this on the server side Libraries will also be provided to allow the easy implementation of both client and server The delegation port type currently has no faults defined Clearly there are a set of faults which do need to be defined here Action on OM, DG: ensure that the delegation WSDL is finalized with an appropriate set of faults.

Common APIs (2/3) Another probable need is to have a common portType for ACLs: setACL getACL It has been asked why LB does not expose such interfaces A priori this is a simple interface but this will immediately bring up the issue of a common format for the actual ACLs CL will add a sample version of a portType to the wsdl-test example which will be intended for discussion

Common APIs (3/3) … others: getVersion Not yet defined as a common portType Long term: have a look at WS-MetadataExchange (specifies how metadata about a service should be collected) Service Configuration and management AdM proposal on how to standardize the configuration of services needs to be tested The gLiteIO module is the first to implement it: testing group is having a go at it now

Use Case with gLite APIs (1/2) Walking through the simple "Hello World" job submission to verify that the APIs in the design document were complete and correct Missing/unclear pieces: Delegation chain string CSR getProxyReq(string delegationID) string delProxy createProxy(string CSR) putProxy(string delegationID, string delProxy) JRA3 has to create and document the libraries which will handle the proxy generation Details of the WMS and CE interaction to determine the job status Send around the API for this interaction Clarify how this interaction works CSR certificate signing request

Use Case with gLite APIs (2/2) Missing/unclear pieces: LB interface From the documentation it is not clear which FLAG (e.g. CHILDSTAT) should be used to retrieve the job status from the WMS. It should be made more clear in the documentation. queryJobs and userJobs returns 2 objects (jobs, jobstates) Is it really needed? Seems to be not really well-suited for languages other than C/C++ CSR certificate signing request

Requirements Procedure Insufficient time to discuss this point CL will distribute a proposal for managing the requirements and circulate this to the PTF list for approval NA4 group managing the requirements DB also involved (http://egee-na4.ct.infn.it/requirements)