Contract first is definitely the way to go, but you COULD try something like:
Create the SEI interface and types that it references JUST using the "public" data. Create subclasses of all the types that add the extra fields for the internal stuff. Have an "abstract" impl that does most of the logic. Two subclasses: 1) Public subclass would just reference the SEI. 2) The internal subclass would have @XmlSeeAlso annotations to add all the subclasses of the data types. Publish them on two different URLs. The public one should JUST have the base classes in it. All JAXB will read/write would be the base types as it wouldn't know about the subclasses. The "internal" one would know about all the subclasses and it's produced wsdl would have extensions for all the types that the internal clients could use. In theory, that SHOULD work. Dan On Thursday 15 January 2009 6:35:02 am [email protected] wrote: > Hi, > > I have the requirement to provide webservices, to internal clients who > should see all data we have, and external clients who should see a subset > of the data. > > Is there an established way in webservices or CXF to handle this? > > One easy way would be to have a layer which would walk the object graph of > a returned value, setting NULL or 0 where appropriate. The problem is that > some clients may think 0 is a proper value and that they are seeing > something they should not be seeing. > > I think a cooler way would be to have different WSDL generated, so the > client stubs don't even have the fields in their generated classes. But > how can I make one interface publish 2 different WSDLs and is there a way > to autogenerate the WSDLs (as I am doing), but perform some kind of > filtering on how the POJOs are published to WSDL? > > Thanks for any help! > > > Scott Sinclair > > > > ----------------------------------------- > This communication is for informational purposes only. It is not > intended as an offer or solicitation for the purchase or sale of > any financial instrument or as an official confirmation of any > transaction. All market prices, data and other information are not > warranted as to completeness or accuracy and are subject to change > without notice. Any comments or statements made herein do not > necessarily reflect those of JPMorgan Chase & Co., its subsidiaries > and affiliates. > > This transmission may contain information that is privileged, > confidential, legally privileged, and/or exempt from disclosure > under applicable law. If you are not the intended recipient, you > are hereby notified that any disclosure, copying, distribution, or > use of the information contained herein (including any reliance > thereon) is STRICTLY PROHIBITED. Although this transmission and any > attachments are believed to be free of any virus or other defect > that might affect any computer system into which it is received and > opened, it is the responsibility of the recipient to ensure that it > is virus free and no responsibility is accepted by JPMorgan Chase & > Co., its subsidiaries and affiliates, as applicable, for any loss > or damage arising in any way from its use. If you received this > transmission in error, please immediately contact the sender and > destroy the material in its entirety, whether in electronic or hard > copy format. Thank you. > > Please refer to http://www.jpmorgan.com/pages/disclosures for > disclosures relating to UK legal entities. -- Daniel Kulp [email protected] http://dankulp.com/blog
