March 2006 - cddlm-wg - lists.ogf.org

Last call for Application Contents Service Specification 1.0
by Keisuke Fukui 08 Mar '06

08 Mar '06

Folks in ogsa-wg, cddlm-wg and acs-wg, We, acs-wg, has come to completion of the ACS Specification 1.0 after discussions and reviews. This is the last call for comments before submission to the GGF Editor for publication. If you have comments, please get them to me by 9 am Japan time on Monday November 7. If there are no significant comments I plan to submit the document on Monday afternoon. Below is the link for the document: https://forge.gridforum.org/projects/acs-wg/document/draft-ggf-acs-spec-1.0… Regards, Keisuke Fukui ACS-WG co-chair

1 1

Component Model Interop Plan
by Stuart Schaefer 02 Mar '06

02 Mar '06

I'll steal Steve's format..... Component Model Interoperability testing Goal: To achieve deployment-time interoperability of the component model frameworks written by different people. Means of achievement: Testing Means of testing: Pre-defined components and CDL templates, with measurable outputs. Process: A core set of test components are created: 1) A simple component with a predefined resource property <testvalue> defined in its CDL. Additionally, this component should expose resource properties for timing conditions, and its state transitions. These would include <timeOfInitialize>, <timeOfFail>, ..., <stateList>. The <stateList> would be a comma separated list of the transitions the component took in its lifetime: initialized, running, failed, terminated, destroyed. 2) A component which exhibits failure conditions. a. Fails on transition to a specified state. b. Fails on change of a resource property. c. Faults on change of a resource property. 3) A component which can test the value(s) of other component's properties and assert truth. This component is ideally a delegate, thus the remainder of the system which it tests would act as a separate child system. This component should also receive events and be able to assert conditions based on the event. Each implementer creates a test harness that uses their own Deployment API client to test these components. No actual deployment is expected to be done, since these are not tests of deployment, but of the infrastructure. The tests to be implemented follow the component model test plan. In order to do this, I will need to update the Component Model Test Plan to fully specify these components and the explicit positive and negative test cases. If this methodology is reasonable, I will start that process. Stuart Stuart Schaefer CTO sschaefer(a)softricity.com Softricity, Inc. 27 Melcher Street Boston, MA 02210 ph 617.695.0336 x112 fx 617.338.7769 www.softricity.com - Virtually, Anything Is Possible(tm) The Softricity Desktop(tm) enables applications to be as instantly available and easy to use as electricity "All problems in computer science can be solved by another level of indirection". -- Butler Lampson

1 0

[Fwd: WSRF/WSRN in Apache and Axis2]
by Steve Loughran 02 Mar '06

02 Mar '06

This should be of interest to anyone using Muse. -------- Original Message -------- Subject: WSRF/WSRN in Apache and Axis2 Date: Thu, 02 Mar 2006 11:23:19 -0500 From: Sal Campana <scamp(a)apache.org> Reply-To: axis-dev(a)ws.apache.org, scamp(a)apache.org To: pmc(a)ws.apache.org, axis-dev(a)ws.apache.org Yesterday I sent a statement to the Muse Project announcing that IBM wishes to contribute the project a foundation for building a next-gen version of the specs with the focus of running on Axis2. I am including my statement as an FYI of our intentions to the PMC and Axis team: We are currently looking at merging the three Apache projects (WSRF, Pubscribe and Muse) into a single entity under the Muse project. While I have done some work on this there have been other things happening which have made me reconsider the project as a whole. We have been talking with a team at IBM, whom we work with through the spec committees, to do a joint next-generation implementation of WSDM, and its sub-specifications. The implementation would not only position the WSDM effort in a more future-proof way (i.e. move towards WSDM 2.0), but continue to move the project forward in a positive direction. IBM has code which they would like to contribute as the foundation for this effort. The code will initially be run in Axis2 which would please those who are seeking an Axis2 implementation of WSDM (WSRF,WSRN, etc). IBM is willing to contribute base code, which will be reviewed by us, and developers to the effort. IBM would like to be part of moving the Apache WSDM effort forward, and is excited about the possibilities of being part of the project. They are even planning on contributing tooling around this effort to the Eclipse Project. I believe this to be the right thing to do for the direction of the Muse project. Bringing IBM to the project will entice more users, generate more interest in the project and bring more active committers moving the effort forward.

1 0

Test documentation
by Steve Loughran 02 Mar '06

02 Mar '06

This is the autogenerated test documentation. I tried using XSL to do it, but it refused to treat the XML as stuff to be escaped, so reverted to legacy procedural programming in java. Anyone can create it, the stuff is all on CVS. Just run "ant test-docs" to have it put into build/xsl/testdocs/index.html. 1. The description of each test is in the test xml file. If anyone find an error in a description, or wants to expand it, then make the relevant change to the CDL file. 2. Whoever add a new test package, must update the build.xml 3. whoever is unhappy with formatting/layout should know -things like the html tags for the lists and text entries are all in a .properties file in the printing package, edit as you see fit. -the layout of the nested XML is extracted from the test XML file. It cannot be changed at print time. Dont even try, believe me. Dejan, As this file is autogenerated, and as new tests are expected, I would not recommend any attempt to import into msword. Just stick it in as is, as an attachment. -Steve

1 0

deployment api test plan
by Steve Loughran 01 Mar '06

01 Mar '06

As promised in the phone call, my expectations for interop testing. Deploy API testing Goal: To achieve interoperability between api clients and api servers written by different people. Means of achievement: Testing Means of testing: Cross-testing client code against server code, SOAPBuilder style. Process: Everyone implements a test suite that uses their own client API to make calls of the server. This test suite must accept a URL to point to the portal endpoint. (NB: it should be a simple URL, please don't use full WS-Addresses here as life would be too complex) This client test suite must implement the tests as defined by the deployment test plan, and should work against the local implementation. To test against the other implementations, we need accessible endpoints. This can be done in three ways 1. public endpoint. Lets implementors update nightly, good for iterative development, and for letting implementors trace/debug their side of the app. Bad for security: we need to lock down our implementations to only deploy a finite set of components from CDL. There may also be WS-N problems here, as we wont be able to send messages back through a firewall. 2. Redistributable installer. Implementors share releases of their application, testers install it themselves on suitable hardware. 3. VMWare image. Implementors create a vmware image and share it around. Good for complex installs, good for security. Takes up lots of disk space and bandwidth, unless ultrasmall linux distros get used. I don't know which of these three I'll use yet, I may do #2 before #1, because for smartfrog, we have the build targets to create distributions already. Next Steps -Implement your deployment API, if not already done so -Implement the test clients -make sure that your WS-A handling is fairly broad, and handles the reference properties/params, plus addresses from a broad set of WS-A namespaces. -get your tests running against your local implementation -get your tests running against a remote implementation -decide which of the three ways to accessible endpoints you want to follow, and go about it. I've said I'm targeting the end of march for an accessible endpoint, and that is still on my roadmap. There is nothing to stop anyone bringing up their endpoint earlier and sharing the URL.

1 0

Notes from the CDDLM meeting on 3/1 6am PST
by Milojicic, Dejan S (HP Labs) 01 Mar '06

01 Mar '06

Attendees: Ayla, Stuart, Steve, and Dejan. Notes taker: Dejan. > 1. Update on specs Deployment APIs spec will have to undergo minor changes based on a feedback we received and then potentially go through another (shorter?) public review. Steve will look into it some time after next 10 days. Component model is ready for becoming public document. > 2. Update on test programs Stuart: CDL processor complete with one error case, deployment API complete and running, will be done within next 2 weeks. Component model done and half of the test cases. 2 weeks away. Ayla: 100% of CDL tests pass without problems. > 3. various Interoperability: Stuart will post the note about his plans wrt interoperability of component model. Current plan is still the same, complete the CDL interoperability before GGF17 (and document it!), complete Deployment APIs at latest at GGF17. TBD about component model, subject to Stuart's progress with the proposal. At the moment, it is unclear who will attend GGF17. Ayla will not attend, Steve is uncommitted, Stuart will try to attend, Dejan as well. We presume that Jun will attend. Steve will have his endpoints up and running by the end of the March. He will post a note summarizing his expectations from others wrt deployment APIs interoperability. Can I please ask everyone to post a quick status of the progress if he/she does not plan to attend the meeting in the future. The status should consist of a) update no the completeness of the reference implementation, b) the % of CDL tests passing and c) the progress of putting up endpoints for the deployment APIs tests. PLEASE: PLAN TO ATTEND NEXT MEETING, WE WILL DISCUSS STUART'S PROPOSAL FOR INTEROPERABILITY OF COMPONENT MODEL AND STEVE'S EXPECTATIONS FOR EVERYONE'S TESTING OF DEPLOYMENT APIs. Thanks, Dejan.

1 0

Reminder, CDDLM meeting tomorrow, 3/1 6am PST
by Milojicic, Dejan S (HP Labs) 01 Mar '06

01 Mar '06

Hi, We shall have a regular meeting tomorrow at 6am. We will use our usual numbers: +1 866-639-4732 (toll free while in US) Code 2362906 (followed by a '#' sign) +1 574-948-0379 (toll & international) Agenda: 1. Update on specs 2. Update on test programs 3. various Thanks, Dejan.

1 0