tags:

views:

74

answers:

1

I have a POJO that I would like to expose as XML from a web service, preferably with JAX-B.

The fields that need to be exposed in XML depend on what type of user is making the request. For instance, we have a role for HumanResources and Finance users. A User might be defined as:

@XmlRootElement

public class User {

@XmlElement public String someHumanResourceData;

@XmlElement public String someFinanceData;

}

I want HR users to see the HR data, and Finance to see the Finance data, but nothing more than that. HR should not see Finance data.

Is there a recommended approach on how to do this? What are some search terms I could use to lookup more information on the Web?

A few ideas that I don't find appealing: 1) I could use subclassing to expose a FinanceUser and HumanResourceUser that only has the relevant data, and a parent User with the shared data. However, this is fragile and may work on a small example, I feel I need a more flexible, compositional approach for production. 2) A co-worker recommends a "shopping cart" approach in which the client requests what fields he/she wants with each request. I'm not finding a standard way to do this or even many other people who have done this approach. It sounds really home-grown and labor intensive to me.

Any other ideas?

A: 

Why don't you just check the user's role in your server-side web service implementation?

What is your web service interface?

public interface DarcysWebService {
    public HumanResourceResponse getHumanResourceData(Authentication a, HumanResourceRequest req);
    public FinanceResponse getFinanceData(Authentication a, FinanceRequest req);
}

I would then check the authentication data supplied (username, password) against your database of users (uuid, username, password, role), and then use the role to determine whether the response is a message saying "Error - you don't have access privileges" or to actually populate the data fields/objects in the response with the requested data.

JeeBee
This solution is option #1 from the original post, right? You've created two types: HumanResourceResponse and FinanceResponse. Based on some criteria you're returning a different subtype. I'm looking for something compositional and flexible.
Hamlet D'Arcy
You want a web service? You want to restrict the data returned. You could have a "DarcyWSResponse" object that had members of "FinanceData" and "HRData", which could extend a common object. I'm just saying that it's handy to wrap the web service parameters and response in an object.
JeeBee
And I would certainly design the Web Service from the viewpoint of what operations you want to be available on the web service first, not the data structure. The web service APIs (Ajax, JAX-B(?)) will handle all the XML and SOAP encoding transparently.
JeeBee
There are a large number of constraints on this project due to large amounts of legacy code. In production there are hundreds of objects, and dozens of roles. Subclasses is not an option. Also, the beans are already defined, so we don't have the luxury of contract first.
Hamlet D'Arcy
Well use the POJO support in Axis 2 to expose your existing objects and methods.
JeeBee
So you want "something compositional and flexible" but within "a large number of constraints" when "Subclasses is not an option"?
JeeBee
I'm not saying your advice wasn't correct. Just that my team has already rejected that approach based on criteria not listed in the post. The POJO support in Axis2 requires ADB (Axis Data Binding) or JibX, while our preferred solution is Jax-B for interoperability with our other services.
Hamlet D'Arcy