Hi John, 2008/6/23 John Kaputin (gmail) <[EMAIL PROTECTED]>: > The WSDL 2 spec talks about equivalence between components. This is to do > with collapsing equivalent components derived from different parts of the > XML infoset into a single component in the Component model. I think there > are some assertions about it too. If I remember correctly, that was the > requirement behind having an equals() implementation that tested for the > logical equivalence of components and the equals(WSDLComponent) method
I guess you're referring to section 2.15 of the core spec. I guess there isn't an interop as I don't think that would make sense - hence we haven't needed to get this to work so far. Also, I don't think we can be testing for equivalence in Woden today as the equals(WSDLComponent) method just delegates to Object.equals() > resulted because of the problem with implementing equals(Object) in an Impl > class that implements both the Component and Element interfaces. > > For example, we wanted to override equals(Object) in DescriptionImpl, but > this implements both the Description component and the DescriptionElement > interfaces. The equivalence checking behavioiur for a Description component > and a DescriptionElement are different, but at the DescriptionImpl level we > can't tell which 'view' of the object the caller is seeing (component or > element). We could just define equals(Object) as comparing the two objects at the component model level. Then if you really want to compare at the XML level then you need to serialize both objects under comparison to XML and compare them using something like XMLUnit. We might be able to do something to simplify this with a layer on XMLUnit. > > We do need some form of equivalence checking to satisfy the spec and while > implementing equals(WSDLComponent) across Woden might achieve this, it will > break the transitivity of the Object equals() method as Jeremy says, which > will limit the ability to make use of some aspects of Java (e.g. in the > collection classes). I've been trying to think of the use cases for the equals() method. For me it boils down to: does this WSDL (in object form) describe the same service as this other WSDL (in object form). Likely reasons you'd do this: a) you've read the WSDL from disc / URL twice and you want to see if they're the same. The DescriptionImpl objects will always be different, but the content will be equal. b) you've read WSDLs from two different locations and you want to see if they're the same - describe the same service, same service endpoint etc. Again the DescriptionImpl objects will have different object IDs. The WSDLs describe the same service if the component models are the same. The way in which a web service client interacts with the web service is the same whether it is using WSDL #1 or WSDL #2. i.e. there is nothing in the element model of the WSDLs that would cause the web service client to behave differently. If there was, then this should have been surfaced at the component model in some way. At least this has been my understanding, so if this is a false statement, please say. c) you've read WSDLs from two different locations and you want to see if they describe two different instances of the same web service - i.e. you have a choice of which the request should be sent to. For me this, and further variations on this theme (e.g. same web service, different transport) require the web service client to dig around in the WSDL a bit further than just calling equals(). I think this is possible today using the accessor methods we have today. d) you've read a WSDL and you want to split the WSDL into 2 - an interface and a service endpoint WSDL. Then you want to check that when you've done that, the result is semantically the same as what you started with. This is really a variation of b). So, based on this I think it the equals(Object) method should compare at the component model only. If there is a use case for comparing at the element model level then this is really equivalent to comparing at the XML level and can be done using something like XMLUnit on an xml stream / DOM object. So I propsose equals(Object) should compare at the component model only. > > Don't forget the issue still pending on the Woden wiki [1] about merging the > Component and Element APIs into one API. This might simplify implementing > the equals(Object) method, but we will still need to test for Component > equivalence to satisfy the spec. What will merging the APIs really give us. I think that would be less intuitive. I guess I'd like to see how users of Woden wish to use it and what the shortfalls of the current APIs are. > > [1] http://wiki.apache.org/ws/FrontPage/Woden/APIReview/OneWsdlApi > > regards, > John. > > On Fri, Jun 13, 2008 at 11:39 PM, Jeremy Hughes <[EMAIL PROTECTED]> wrote: >> >> 2008/6/13 Jeff MAURY <[EMAIL PROTECTED]>: >> > Just to finish the discussion: >> > >> > 1) I agree that XMLUnint will solve the problem >> > 2) I think the equals method should work on the component level because >> > Description is the component representation of the WSDL >> > 3) If the user wants to test equality at the element level, he should >> > use >> > the toElement methods and use equals on the results. >> >> That sounds like a nice idea, but both toElement() and toComponent() >> methods return 'this' ... so >> >> myDescription.toElement().equals(foo) >> >> will call the same equals() method on the same object as: >> >> myDescription.toComponent().equals(foo) >> >> but I can see your sentiment that the toElement() method should >> produce an object that effectively *is* the element model of the WSDL >> and so equals() method would test for equality at the element model >> level. I did have thoughts around the terminology we use - our meaning >> of the term "model" isn't quite the same (IMHO) as the meaning of the >> word "model" in the MVC pattern. >> >> I think if we starting thinking in terms of the MVC pattern then we >> would have a single model (in the MVC sense of the word) of the WSDL >> which would at least contain a representation of the XML (like >> DescriptionImpl does today) and optionally a calculated representation >> of WSDL in terms of what the spec calls *components*. This is pretty >> much what we have today in fact, except that we would just start >> saying we have *one* model. Then we would move to saying we have an >> "Element view" of the model and a "Component view" of the model. That >> way the equals() methods would be on the view and you would only ever >> compare an instance of one type of view of a WSDL with an instance of >> the same type of view of another WSDL. >> >> My only hesitation is that this is quite a significant change. Is it >> worth it just so that .equals() works? And we'd need hashCode() of >> course. It may provide further benefits - it would be easy enough to >> create other views on the model (if there was a use case for that). >> >> Regards, >> Jeremy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
