Hey all,
In 5.2 we're introducing a new concept, not sure of the full extend of the change yet as we're still working out ideas, called "ServiceContext".
Background:
First, our service method calls are getting very big... some have 10-15 parameters. As we add general features to the service tier, we don't want each one to incur more and more parameters. It's enough that we're already using the entity fields as params motif.
Second, we often have objects like ThemeDisplay and/or PortletPreferences which make using these methods from the web-service perspective painful as we don't really have any good way of dealing with these, except passing null. And yet, they are so entrenched that we can't really eliminate their usage outright.
Third, many methods require values such as groupId, plid, etc.. which identify the scope to which the particular instance belongs.
Fourth, two new features we've recently added could cause the number of params to increase (which is really a subcase of
First):
- ExpandoBridge (a simple API for adhoc, custom attribute definition, build on top of Expandos)
- Indexing of ExpandoBridge custom attributes
Fifth, fields like companyId, userId, addCommunityPermissions, addGuestPermissions etc... which are continuously repeated over and over throughout the service tier, should eventually be moved into the ServiceContext and dynamically evaluated based on implementation of some Interface which dictates which data to obtain from the context. For instance:
- if an entity implements Owned, then dynamically obtain userId, userName from the context
- if an entity implements Scoped, then dynamically obtain scope values from the context
- if an entity implements Permissioned, then dynamically obtain permission values from the context
Proposed Solution:
All of the above define the "context" within which a given operation is to be performed.
What we've done is defined a simple object called ServiceContext which will act as a single entry/extension point and auxiliary parameter which will (eventually) replace all of the above.
So, the result might be that a method which looked like this:
1 public MBMessage addMessage(
2 String uuid, long userId, String userName, long categoryId,
3 long threadId, long parentMessageId, String subject, String body,
4 List<ObjectValuePair<String, byte[]>> files, boolean anonymous,
5 double priority, String[] tagsEntries,
6 PortletPreferences preferences, Boolean addCommunityPermissions,
7 Boolean addGuestPermissions, String[] communityPermissions,
8 String[] guestPermissions, ThemeDisplay themeDisplay)
9 throws PortalException, SystemException;
may end up looking like:
1 public MBMessage addMessage(
2 String uuid, long categoryId, long threadId, long parentMessageId, String subject,
3 String body, List<ObjectValuePair<String, byte[]>> files, boolean anonymous,
4 double priority, String[] tagsEntries, ServiceContext serviceContext)
5 throws PortalException, SystemException;
and all of
- long userId
- String userName
- PortletPreferences preferences
- Boolean addCommunityPermissions
- Boolean addGuestPermissions
- String[] communityPermissions
- String[] guestPermissions
- ThemeDisplay themeDisplay
be available from the ServiceContext object, thus reducing the amount of params.. and allowing for a cleaner API as well as for extensibility without polluting the API with objects that simply make life more difficult.
Thoughts?
Please sign in to flag this as inappropriate.
