Want to add a comment again because I just saw something like this. The situation was they were trying to increase "reusability rate" up by bundling interfaces together using "OO concepts". For example, forms were bundled into one interface even though they had different data fields. Another example involved customer interface which were made to handle individual's data and corporate data even though most of the data were different.
The question was, if to add all data from all bundled functionalities into an interface or use use dynamic list. For example, in the second example above, all individual's data fields and all corporate data fields are added to the interface parameter list. This obviously is not very good practice because if individual's data field is modified, all service consumers (i.e. service needing individual's data AND service needing corporate data) needs to be modified as well. There's also an overhead of sending and receiving unnecessary data. The better solution seems to be to use a List and dynamically change content. For example, consumer needing individual's data receives a List with individual's data and consumer needing corporate data receives a List the corporate data. This seems like a good solution but it really isn't. An interface should only have one MESSAGE definition for input and one MESSAGE definition for output. I think the problem like the one above comes about because people equate messages and interfaces. Furthermore, I think this problem comes up because developers are still accustomed to designing service PROVIDER interface first and using OO concepts to increase "reusability". H.Ozawa 2009/8/25 Sasan <[email protected]> > > > Gregg, > > If a service takes a parameter as List<SomeType> this will be mapped to a > complexType of SomeType with maxoccure = -1 > > the content of SomeType will then be exposed by other complex types in the > same schema. At least the practice prototype is behaving like this. At the > same time, I have seen that a some attributes of a customized type ( a > custom class) has not become visible if it doesn't have bean convention > accessors, this is why I think its risky to fully rely on reading of complex > Type and then client will not have full understanding of SomeType by just > parsing wsdl. This however this is a problem for dynamic access to services > that have either List<SomeType> or SomeType on its own, as a parameter. > > Sasan > > > ------------------------------ > *From:* Gregg Wonderly <[email protected]> > *To:* [email protected] > *Sent:* Monday, August 24, 2009 10:32:39 PM > *Subject:* Re: [service-orientated-architecture] Re: good or bad practice? > or maybe ugly > > > > Sasan wrote: > > I'm sorry that I have to talk technology oriented. In this particular > > case the client only has access to abstract contract i.e WSDL. So if > > list includes the type i.e. List<SomeType> , it is possible to identify > > the content structure of "SomeType" but it seems to be very risky > > because based on some prototypes, some of the content might not be > > discovered if "SomeType" do not fully comply with a java bean convention > > (having getter/setter for all attributes). this is only for dynamic > > access to services > > I fail to understand how the SomeType being "known" because it is in the > declaration as List<SomeType> has any baring on "risky". No matter what > type of > object is in the List, it has to be a usable "type" for the application. If > you > are using some non-native transport technology such as XML driven by some > kind > of packaging standard such as WSDL, than your objects have to allow you to > construct the needed content. If you need JavaBean conventions supported, > than > it doesn't matter what type of object that is does it? > > There really is no reason that adding type information would make things > more > risky it seems to me. > > Gregg Wonderly > > >
