1. 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.
EGEE is a project funded by the European Union under contract IST

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

3. Intro Meeting held on 14 Oct at CERN Focus on WSDL, tools and APIs
Agenda and minutes available at:
PTF Web Pages now available at:

4. 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.

5. 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 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 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

6. 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.

7. 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.

8. 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)

9. 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.

10. 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

11. 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

12. 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

13. 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

14. 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 (