December 2005 - cddlm-wg

Sessions at GGF16
by Milojicic, Dejan S (HP Labs) 11 Dec '05

11 Dec '05

Hi Team, I propose the following three sessions at GGF16: 1. Demos of reference implementations 2. CDDLM and relationship to other technologies (mapping to OGSA architecture, provisioning, etc.) 3. Planning interoperability demonstrations at GGF17 Please let me know if you have any other interests or needs. We may not be allowed to have all three sessions - we are entitled only to two, but last time we were approved to have the third session by technical area directors and I expect that we will be again. If we get only two, we can do the planning offline as we have done at earlier events. Thanks, Dejan.

1 0

No CDDLM meeting next Wednesday
by Milojicic, Dejan S (HP Labs) 11 Dec '05

11 Dec '05

Hi, I will be traveling next Wednesday and can not attend the meeting. If there is interest, someone else can host it. It is my understanding that Steve will be absent as well. I recommend that we address any questions by email until the following week. Thanks, Dejan.

1 0

Deployment API test plan
by Guilherme Mauro Germoglio Barbosa / Projeto Ourgrid - Projeto Ourgrid/LSD 08 Dec '05

08 Dec '05

Hi, As I read the test plan, I've found some typos in it. You can find them in: http://lsd.ufcg.edu.br/~guiga/cddlm-docs/ In the http://lsd.ufcg.edu.br/~guiga/cddlm-docs/deployment_test_plan-typos_marked.… the typos are marked, in the http://lsd.ufcg.edu.br/~guiga/cddlm-docs/deployment_test_plan.sxw they were corrected. Guilherme

2 1

deployment API notes
by Steve Loughran 07 Dec '05

07 Dec '05

Returning to the deployment API, here are some notes and issues I made while working on it in the runup to GGF15. I had some notes about Axis2 and xmlbeans, but I have dealt with them myself. These are issues with the deployment API specification itself. We can discuss these via email, or I can file them as bugreps, which will keep the issues open. -steve Possible enhancements to deployment API Spec clarifications -what is our policy for queries on values (esp state values) that arent there yet e.g. terminatedtime, terminationrecord -there is no definition of what the value of the started/finished/failed timestamps are. Implementations may either have null values (Softricity) or return an error that a property is undefined (HP) -add property for 'failed time' on a system, recording when it entered the failed state. rationale: the other transitions all have a timestamp. There may be a delay between failing and terminating. -add a property for both nodes that lists all current properties. rationale: makes it good for testing/diagnosis, discovering extras. -add a management capability for this property, so it can be used in other places. it would seem generally useful for any system w/ dynamic properties, and is more useful at runtime than WSDL, especially on platforms that do not support dynamic WSDL generate/parse. the value of this would be the same as for the property in the wsdl; a list of qnames. * see GetResourceNames Testing enhancements -see what happens when you ask for a property qname with an incomplete, missing prefix ":ex1" "pre:" ":" "a:b:c" (legal) "::" " : " System Enhancements -AddFile to require you to specify file extension? make it an option. Rationale: used in filesystem mode to generate extension, many things depend on it. Unless we derive the extension from the URI. Possible: make it an informal bit of metadata. -Addfile to take a (relative) expiry time expires:after-run expires:+23455 expires:2005-10-23 OGSA-Basic Profile Changes ========================== HP Impl must support GetResourceProperties() plural as it is required. OGSA defines the following requirements which are not in conflict with the deploy API, but nor are they explicitly mentioned. To be compatible with the OGSA BP, they need to be met: R0420 A DESCRIPTION MUST contain in the Resource Property Document schema, as referred to by the wsrf-rp:ResourceProperties attribute on the portType, a Resource Property Element ogsa-bp:ResourceEndpointReference as defined in the schema http://www.ggf.org/namespaces/2005/07/OGSABasicProfile-1.0.xsd (see Appendix D). R0421 A RECEIVER SHOULD respond to a wsrf-rp:GetResourceProperty request where the child of the wsrf-rp:GetResourceProperty is the QName ogsa-bp:ResourceEndpointReference with the wsa:EndpointReference of the endpoint to which the message was addressed. R0411 A DESCRIPTION MUST contain in the Resource Property Document schema, as referred to by the wsrf-rp:ResourceProperties attribute on the portType, a Resource Property Element ogsa-bp:ResourcePropertyNames as defined in the schema http://www.ggf.org/namespaces/2005/07/OGSABasicProfile-1.0.xsd (see Appendix D). R0412 A RECEIVER MUST respond to a wsrf-rp:GetResourceProperty request where the child of the wsrf-rp:GetResourceProperty is the QName ogsa-bp:ResourcePropertyNames with the complete list of the xs:QNames of all Resource Property Elements contained in the Resource Property Document at the time of receipt of the message WSDL ==== -collect and incorporate all requested changes. Are there bugs in the XSD of WSRF? -have template WSDL files for each endpoint, portal and system, that import the core WSDL -have a build process that turns these templates into WSDL that describes the real endpoint (or hard code to some local URL as a hint). This is to force WSDL tools to act. Proposed new Faults =================== UnsupportedFeature -generic unsupported ness; UnsupportedUrlSchema -for AddFile: if the caller asks for a schema type (e.g. https:) that the endpoint does not uspport.

1 0

Testing Fault Values Thrown on Unsuccessful CDL Language Tests
by Steve Loughran 07 Dec '05

07 Dec '05

As promised, my thoughts on how to declare what kind of failure we expect on a test, in a way that does not mandate that implementations actually include the same error message or fault type. The reason for this is that some of the existing tests I have cannot yet move to using the new CDL test file format, because I not only test that parsing the CDL doc fails, I verify that the exception contains an error string that I know about. public void testDirectLoop() throws Exception { assertInvalidCDL(EXTENDS_DIRECT_LOOP, ExtendsContext.ERROR_RECURSING); } public void testIndirectLoop() throws Exception { assertInvalidCDL(EXTENDS_INDIRECT_LOOP, ExtendsContext.ERROR_RECURSING); } public void testBadReference() throws Exception { assertInvalidCDL(EXTENDS_BAD_REFERENCE, ExtendsResolver.ERROR_UNKNOWN_TEMPLATE); } public void testUnknownNamespace() throws Exception { //This is a Xom error @ parse time. assertInvalidCDL(EXTENDS_UNKNOWN_NAMESPACE, "UndeclaredPrefix"); } While we can't control what errors get thrown from 3rd party libraries, we can hint as to the fault code expected from an exception, leaving each implementation free to act on the hint. comments? Testing Fault Values Thrown on Unsuccessful CDL Language Tests =============================================================== When testing to failure, the actual fault type matters. That is, if a successful test should normally throw a "no prototype for extends" exception, and suddenly it starts failing with a "undefined element cdl:cdl", then the test should fail. The current iteration of the CDL test language allows one to declare that a test should fail, but does not specify what the failure message is. This is an inevitable consequence of the specifications not defining the error messages. We may specify that things should fail, but not how. Proposed changes ================ fault code in test documents ============================ -the <ct:failed/> message is extended to support a SOAP fault code; a qname of namespace and string. <ct:failed> <ct:code namespace="http://http://gridforge.org/cddlm/serviceAPI/faults/2004/10/11/" value="extends-loop" /> </ct:failed> If the namespace attibute is absent, we default to the one defined above; the CDDLM faults ns. Defined fault codes for common failure modes ============================================ These can be added to constants.xml, though we may want to pull this into a separate document. It has always been the plan to produce an informative documents of faults that the deployment API endpoints should produce. Adding parse time fault codes which implementations may implement could benefit users, as well as the test suite. Test routine asks implemententations to verify the fault ======================================================== After catching any Throwable (other than ThreadDeath, which must be rethrown), the exception is handed to the CdlProcessor, which has a new interface method boolean isExpectedFault(String test,QName faultCode,Throwable thrown); -Parameter "test" is the name of the test -Parameter "faultCode" is the constructed QName of the fault, built from the test document -Parameter "thrown" is the received exception. It is up to the individual exception to verify if the exception thrown matches that expected for that test or the faultCode. Implementation options are 1. The current behaviour could be implemented by always returning true. boolean isExpectedFault(String test,QName faultCode,Throwable thrown) { return true; } 2. having every routine in the CDL parser throw an exception (such as an AxisFault) that has a fault code. boolean isExpectedFault(String test,QName faultCode,Throwable thrown) { if(thrown instanceof AxisFault) { AxisFault fault=(AxisFault )thrown; return faultCode.equals(fault.getFaultCode); } //anything else return true; } 3. Having a lookup table that maps from faultCode to throwable string boolean isExpectedFault(String test,QName faultCode,Throwable thrown) { String search=lookupErrorText(faultCode); return thrown.getMessage().indexOf(search)>=0; } 4. Having a lookup table that knows what exception to get for a particular test boolean isExpectedFault(String test,QName faultCode,Throwable thrown) { String search=lookupErrorText(test); return thrown.getMessage().indexOf(search)>=0; } 5. Having every fault implement a FaultCodeComparison interface interface FaultCodeComparison { boolean isFault(QName faultCode); } and casting every fault to the check: boolean isExpectedFault(String test,QName faultCode,Throwable thrown) { if(thrown implements FaultCodeComparison) { FaultCodeComparison fault=(FaultCodeComparison)thrown; return fault.isFault(faultCode); } //anything else return true; } This is better than (2) as the check logic could be different for different fault classes, and allows the implementation to look for nested faults. 6. Remembering the fault codes generated by an implementation, and verifying the same fault is thrown. This requires manual verification of the thrown information, and some persistence mechanism. It is also potentially very brittle. 7. A combination of the above. Such as looking for a specific string for a specific test, then checking for expected faults via a FaultCodeComparison interface, then falling back to a string search from fault code value if the interface was missing. The point is: it is up to the implementor of the CDL runtime to choose how to process faults; implementing the default behaviour is easy; extending it to support other checks requires more effort, but is optional. The only area that requires collaboration across implementations is in defining the fault codes for common errors. Again, this does not require implementation inside the parser implementations, as the CdlProcessor implementations can use one of the many proposed mechanisms to map verify that the caught fault was appropriate for the given test name and fault code.

1 0

RE: [cddlm] Doubts about SWITCH
by Stuart Schaefer 07 Dec '05

07 Dec '05

Roberto, >> 1. In the 'component-model.xsd', the Switch element has the following >> element: <xsd:element ref="case" minOccurs="0" maxOccurs="unbounded"/>. >> Is the 'minOccurs' value ZERO correct? I think that this attribute >> should have the value 1 (one), unless there will exist an "otherwise" >> without a "case" element. The switch element should allow one to specify only the "otherwise" clause, if no "case"s are defined. I am not sure that a simple <xsd:sequence> covers this correctly, but that is why there is a minOccurs="0". >> 2. Is it possible to have more than one cmp:switch element in the same >> level of a CDL and referring to the same lifecycle? If so, does the >> order of the switch matter? Yes, this is allowed. Yes, order matters. >> 3. Should all the components execute a lifecycle operation or a switch >> can avoid a component to be called in a certain operation? A switch can avoid components being called. However, this should be used carefully to ensure that the system is still left in a deterministic state after the transition has completed. >> 4. How to proceed when there is more than one ref to the same component? >> Should we execute more than one time the same operation on that >> component? Good question. Cycles should be avoided, possibly an error case. However, as it is unspecified in the documentation, my recommendation would be to invoke the operation which should lead to a fault. >> 5. As we can have more than one "case" element for the swith, what does >> the otherwise mean? Should it execute when all case conditions are false >> or when the last one is false? The case element follows that of BPEL. It is an "if-then-elseif" construct. Only one case should fire. Thus, the otherwise should only be used if all other case conditions are false. Stuart

1 0

Meeting tomorrow, 12/7, 6am PST
by Milojicic, Dejan S (HP Labs) 07 Dec '05

07 Dec '05

Hi, There will be our regular meeting tomorrow. Please use our usual phone numbers: > +1 866-639-4732 (toll free while in US) > Code 2362906 (followed by a '#' sign) > +1 574-948-0379 (toll & international) Thanks, Dejan.

1 0

Problems in the component-model.wsdl
by Guilherme Mauro Germoglio Barbosa / Projeto Ourgrid - Projeto Ourgrid/LSD 06 Dec '05

06 Dec '05

Hi all, I think I found a bug in the component-model.wsdl. From line 50 to 55 is written: <wsdl:message name="taskActionRequest"> <wsdl:part name="taskActionRequest" element="cmp:taskActionRequest"/> </wsdl:message> <wsdl:message name="taskActionResponse"> * <wsdl:part name="taskActionRequest" element="cmp:taskActionRequest"/>* </wsdl:message> Isn't the line in bold wrong? The file with /*<wsdl:part name="taskActionResponse" element="cmp:taskActionResponse"/> */is attached. Guilherme

2 1

testing, document fragments
by Steve Loughran 02 Dec '05

02 Dec '05

...except of course a cdl:system it is not, in fact it is one node under a system. Returning a system is not adequate, I am meant to strip out and return the first child of a system expected: <?xml version="1.0" encoding="UTF-8"?> <MyServer> <hostname>www.cddlm.org</hostname> <port>80</port> </MyServer> actual: <?xml version="1.0" encoding="UTF-8"?> <system xmlns="http://www.gridforum.org/namespaces/2005/02/cddlm/CDL-1.0"> <MyServer xmlns=""> <hostname>localhost</hostname> <port>80</port> <hostname>www.cddlm.org</hostname> </MyServer> </system> junit.framework.ComparisonFailure: test []: Namespace URI inconsistent between {}MyServer and {http://www.gridforum.org/namespaces/2005/02/cddlm/CDL-1.0}system I seem to believe that <cdl:system> can have multiple nodes underneath. If I return a doc with a single root node, I can only test documents that have one thing to deploy, and so miss out on a whole suite of tests I propose that 1. the resolve() operation returns a document containing a cdl:system and all children 2. we retrofit the system wrapper to all existing CDL tests. -steve

2 4

FW: [wsi_announce] Invitation to Attend WS-I Webinar, "WS-I Interoperability Profiles, Sample Applications and Testing Tools Explained" on December 7
by Milojicic, Dejan S (HP Labs) 02 Dec '05

02 Dec '05

FYI ________________________________ From: Janice Carroll [mailto:JCarroll@virtualmgmt.com] Sent: Friday, December 02, 2005 6:20 AM To: wsi_announce(a)lists.ws-i.org Subject: [wsi_announce] Invitation to Attend WS-I Webinar, "WS-I Interoperability Profiles, Sample Applications and Testing Tools Explained" on December 7 On December 7, WS-I will sponsor a Webinar, "WS-I Interoperability Profiles, Sample Applications and Testing Tools Explained". Christopher Ferris and Mark Nottingham of the WS-I Basic Profile Working Group, will discuss the technical characteristics of the WS-I interoperability profiles, sample applications and testing tools, and their importance to an organization's Web services initiatives. The Webinar will also address how companies can implement the WS-I deliverables and use them to their advantage as they move to embrace Web services and service-oriented architectures. Date: Wednesday, December 7, 2005 Time: 2:00-3:00 p.m. ET All WS-I members are welcome to attend. To register for this free Webinar, go to: <BLOCKED::http://w.on24.com/r.htm?e=18091&s=1&k=95212C5AA77A1C3892B5D56D E0F76EF7&p> http://w.on24.com/r.htm?e=18091&s=1&k=95212C5AA77A1C3892B5D56DE0F76EF7&p artnerref=atssc_WSI_12_07_05 <http://w.on24.com/r.htm?e=18091&s=1&k=95212C5AA77A1C3892B5D56DE0F76EF7& partnerref=atssc_WSI_12_07_05> Sincerely, Janice Carroll WS-I Membership Coordinator 401 Edgewater Place, Suite 600 Wakefield, MA 01880 Tel: 781-876-6228 You are currently subscribed to wsi_announce as: vbp(a)hp.com. To unsubscribe, send a blank email to leave-wsi_announce-26112B(a)lists.ws-i.org.

1 0