Hi, First of all thank you for giving me the opportunity to take part in GSOC 2010 and special thanks goes to Sagara who helps me in mentoring the project. I have attached my proposal in [1] also attached inline at the end of the mail. I would like to get some feedback or improvements from Woden community as this is the community binding period. My mentor Sagara also mentioned some issues with naming of new packages. I would really appreciate your feedback on this proposal.
Thank you Regards, Dilshan [1] https://issues.apache.org/jira/browse/WODEN-20 *Title: Implement read-write API and Serialization strategy for Apache Woden Component level API (Woden -20)* *Student*: Dilshan Edirisuriya *Abstract* Apache Woden implements the W3C WSDL 2.0 spec. According to W3C WSDL 2.0 spec the Woden has two APIs,Element Level and Component level APIs.The Component Level API is a read only API and implementing a read write features is the main goal.Further defining a serialization strategy for the Component level API is also required. another goal of this project is identifying those serialization alternatives and encapsulating them using a strategy pattern and implement them. *Content* Through the Component API and the Element API the Woden API provides two 'views' of WSDL. The Element API is an XML centric view and it visualizes physical constructs of the WSDL 2.0 document. The Component API is an implementation of W3C WSDL 2.0 'component model' that provides a flatten view of the WSDL 2.0 document. At the moment WSDL 2.0 documents can only be created or modified programmatically through the Element API. As mentioned above the Component API is a read-only API and implementing such an API for Woden component model is the first goal of this project. Adding new methods in to an existing read-only API will only result in extra complexity of the Woden API therefore creating a new read-write API that extends from the read-only API is the BEST solution for this. Here I introduce a new package as org.apache.woden.wsd120.editable to hold new API interfaces. The following set of interfaces will be added in to this new package. EditableDescription EditableInterface EditableInterfaceFault EditableInterfaceOperation EditableInterfaceMessageReference EditableInterfaceFaultReference EditableInterfaceFaultReference EditableBinding EditableBindingFault EditableBindingOperation EditableBindingMessageReference EditableBindingFaultReference EditableService EditableEndpoint EditableFeature EditableProperty EditableElementDeclaration EditableTypeDefinition Each of the above interfaces will extend from the particular WSDL 2.0 component and additionally they will contain following methods to make them read-write. 1.) Factory methods that will be used to create new sub components of the components and later add them them to the components. The Woden Element level API provides AddXXXX methods that encapsulates both the creation of sub component elements and also adding of the necessary references. The same naming convention will be used for the Component level Factory method. 2.)Create a new method called, 'Add(Component subComponent)' to add the existing sub component to the component. This method will be needed for the Serialization strategy. 3.)Create new methods, 'attach(Component subComponent)' and 'detach(Component subComponent)', which will be used to respectively attach sub components to a parent component and detach sub components form the parent component. These methods will be needed for the Serialization strategy. W3C WSDL 2.0 *component model* [1] does not provide any details about the XML info-set and the physical constructs of a given WSDL model also the W3C WSDL 2.0 *specification *section 4 [3] discusses some of the modularization options. It is decided an interface called "SearalizationStrategy " to be developed based on the GOF strategy pattern to represent the possible serialization strategies. There also will be a method on the Woden WSDLFactory to set a desired serialization strategy. Following are some of the possible serialization options and they will represent each of the approaches as an implementation of the "SearalizationStrategy " interface. Furthermore "SearalizationStrategy " interface defines a single method called 'serializeInternal()' that encapsulate each of these different serialization algorithms. 1.) SingleFileSearalizationStrategy - The simplest serialization strategy. Here all the components of the particular WSDL 2.0 component model serialize as a single WSDL 2.0 document. 2.) NamespaceBasedSearalizationStrategy - Here all the components belong to a single namespace, serialized in to a single WSDL 2.0 document. This can be resulted in the creation of several WSDL 2.0 documents for different namspaces and it requires to design a suitable naming convention to name these documents. 3.)SingleFileSingleXSDSearalizationStrategy - Same as the SingleFileSearalizationStrategy. Here all the WSDL 2.0 components are serialized in to a single document except for type components which will serialize into a separate XSD Schema document. 'serializeInternal()' method on the SearalizationStrategy interface encapsulates the above strategies and are used internally in the WSDLWritter that works on Element level where final the serialization depends on each algorithm. Furthermore introduce 'searilze( OutputStream sink)' and 'searalize(Writer sink)' methods on the EditableDescription. The users can serialize WSDL 2.0 Description by calling any of these methods. example code segment is given below. WSDLFactory wsdlFactory=WSDLFactory.newInstance(); EditableDescription desComp =wsdlFactory.newEdtitableDescription (); // fill the tree desComp.setSearalizationStrategy(SearalizationStrategy.NAMESPACE_BASED_SEARALIZATION); NamespaceBasedSearalizationStrategy desComp.searilze(System.out) *Deliverables* 1.) The read-write component level API and the implementation for Woden WSDL Component model. 2.) Implementation of searalization strategies for Woden WSDL Component model. 3.) Set of Junit test cases for unit tests of above two deliverable. 4.) Required documentations for developer documentation and also for future developments. 5.) Samples and a user guide for theses new features.
