You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by sc...@jpmchase.com on 2009/01/15 12:35:02 UTC
Entitlements in webservices
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.
Re: Entitlements in webservices
Posted by sc...@jpmchase.com.
Hi Andrew,
Yes, manually controlling the WSDL is a great idea, I guess then I am
also moving to a more contract first approach :)
Thanks & Regards,
Scott Sinclair
JP Morgan Chase
45, Waterloo Street
Alhambra House - 5th Floor
(Exotics and Hybrids - JPMorgan Structured Products)
Glasgow G2 6HS
Scotland
Desk Phone : (+44)-141-228-5450 (direct)
e-mail : scott.w.sinclair@jpmchase.com
"Andrew Clegg" <an...@nervechannel.com>
Sent by: andrew.clegg@gmail.com
15/01/2009 11:49
Please respond to
users@cxf.apache.org
To
users@cxf.apache.org
cc
Subject
Re: Entitlements in webservices
This isn't a job for the web service layer -- this is a job for the
business logic layer that retrieves the data from the database (or
wherever it's coming from). In my opinion.
In the long run I suspect it'll be much less effort to maintain two
separate interfaces, one for internal clients and one for external,
backed by different parameters to the database queries.
You could try to do something funky with filtering the WSDLs and SOAP
messages, but you'd risk an error letting something leak out to your
customers, and if you're serving financial information that could get
you into hot water...
Andrew.
2009/1/15 <sc...@jpmchase.com>:
> 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.
--
New site launched: http://biotext.org.uk/
I am retiring my old email addresses.
Please use firstname@nervechannel.com where firstname = andrew.
-----------------------------------------
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.
Re: Entitlements in webservices
Posted by Andrew Clegg <an...@nervechannel.com>.
This isn't a job for the web service layer -- this is a job for the
business logic layer that retrieves the data from the database (or
wherever it's coming from). In my opinion.
In the long run I suspect it'll be much less effort to maintain two
separate interfaces, one for internal clients and one for external,
backed by different parameters to the database queries.
You could try to do something funky with filtering the WSDLs and SOAP
messages, but you'd risk an error letting something leak out to your
customers, and if you're serving financial information that could get
you into hot water...
Andrew.
2009/1/15 <sc...@jpmchase.com>:
> 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.
--
New site launched: http://biotext.org.uk/
I am retiring my old email addresses.
Please use firstname@nervechannel.com where firstname = andrew.
Re: Entitlements in webservices
Posted by Andrew Clegg <an...@nervechannel.com>.
2009/1/15 <sc...@jpmchase.com>:
>
> 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?
PS there are good arguments for working WSDL-first, especially when
you're supporting external clients whose code you have no control
over.
http://static.springframework.org/spring-ws/sites/1.5/reference/html/why-contract-first.html
Andrew.
--
New site launched: http://biotext.org.uk/
I am retiring my old email addresses.
Please use firstname@nervechannel.com where firstname = andrew.
Re: Entitlements in webservices
Posted by Daniel Kulp <dk...@apache.org>.
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 scott.w.sinclair@jpmchase.com 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
dkulp@apache.org
http://dankulp.com/blog