On Tue, Mar 24, 2009 at 7:34 AM, Simon Laws <[email protected]> wrote: > So, base on comments from Scott and Raymond, these are the changes I'm > planning > > - Fix up the binding.jms XSD to allow "any" content within the > <response> . This will allow wireFormat elements from the Tuscany > namespace to be included here which can't be done at the moment. Any > concerns about this schema modification?
Just wanted to mention there's an OASIS JIRA open here: http://www.osoa.org/jira/browse/BINDINGS-71 though since in 1.x we haven't introduced WireFormatType, etc., right? so maybe "any" is better for now. > - Change the jms binding providers to create a local interface > contract by cloning the interface contract from the local reference or > service So I think this amounts to saying that the question of whether or not a DataTransformationInterceptor will still be satisfactorily answered by DataBindingRuntimeWireProcessor, (once we at least clone the original IC), given that the DTI itself has the ability to no-op when both sides' DataType(s) are equals(). I was wondering if this were the case, sounds like you've given it some thought, so if it pans out this way, great. > - Change the wire format interface to support a method to reconfigure > the binding interface contract. The wire format providers will then > have the opportunity to reset the binding interface contract, in > either the request or response direction, based on the interface > contract style and data format they expect Sounds good. > - Change the interface implementation to allow operation input types > and output types/faults to be reset independently. Sounds helpful. I guess probably better to break apart outputs & faults in anticipation of them using different databindings in a future use case. > - Change the operation model to represent separate input and output > wrappers rather than the single wrapper info based model that we have > at the moment. This will require a number of changes elsewhere to take > account of this I can't think of anything helpful to add, except to say thanks for tackling this, since this last task seems like the hardest part. Scott
