Recently, the EMC Developer Network has started posting some “Design Patterns”. I use the term loosely to mirror their terminology. Each “pattern” is really just a quick description of the problem and two approaches to solve the problem. It is all very high level.
Before I get any further, kudos to them for actually taking the time to begin developing these “patterns”, starting last fall. There is a definite need, and their choices for the first two are ones that are encountered quite frequently, at least by myself. All I am doing here is offering some feedback, most of which I have already shared.
If you develop Documentum solutions, you need to check them out if you haven’t already. They are:
- When to use registered tables versus object-types with no super type: I talked about this issue myself shortly before this was posted and there are some interesting comments. There is a discussion on the topic as well.
- When to connect as a Named User or as a Gateway User: This speaks to the problems currently faced when interfacing between ECM and CEVAS as envisioned in ECM 2.0. You can read the discussion and see the precursor to this post.
I also want to add that if I hadn’t read Patterns of Enterprise Application Architecture, I wouldn’t be able to make comments that are, I hope, constructive.
Defining ECM Design Problems
The first step in formally defining a Design Pattern is to define the problem/domain. Let’s take the 2nd example. The problem, as given, is as follow:
Developer wants to build an application on top of Documentum Content Repository to create/update/read/act on content stored in Documentum Repository. They have two available options. They can either connect to Documentum Content Server as Named User or Gateway User. Click here for a diagram that explains Named user and Gateway User mechanisms.
In the named user access, the application connects to Documentum as a user it is performing action as, where as in Gateway user access, application connects to Documentum as a application user that performs actions on behalf of the users that is interacting with the application.
Only the first sentence actually talks about the problem, even though both paragraphs are in the section Problem. The description needs to define the problem in more detail, giving the business case and an example or two.
Only by defining the problem in detail can the reader truly understand the different solution patterns and see which situations that each may be required. It is a fair to list the Patterns in this domain and/or to define any Pattern groupings.
In the example that we are looking at, Named Authentication and Gateway Authentication are actually the name of two groups of Patterns, and not two patterns themselves. The Patterns that I know (proposed names in bold) are:
- Named Authentication with Shared Authentication (Single Sign-On)
- Named Authentication with Stored Credential Authentication (user id and password stored as separate values in the 3rd party solution)
- Named Authentication with Generated Credential Authentication (Connection maintained by gateway user that spawns user sessions as required for the named user)
- Multi-Level Gateway Authentication (Different Gateway Users for different authorization levels in the 3rd Party System)
- Single-Level Gateway Authentication (As described in the article.)
Check out the post for my thoughts on these patterns.
Defining the ECM Design Pattern
For each Pattern, there are several things that need to be elaborated upon in order to fully define it. They are (tip of the cap to Martin Fowler):
- Description: Describe the Pattern. Include a diagram to illustrate the concept more clearly.
- Functional How-To: Give a description of how it actually works. Describe how different components interact to implement the Pattern.
- When to Use It: Give the Pros and Cons. Comparing and contrasting to other Patterns in the domain would be beneficial. (Ex. Single-Level Gateway Authentication doesn’t track requests in the ECM system by user. Use a Named Authentication approach, or pass the requesting user as a parameter, to achieve auditing).
- Examples: Where applicable/available, code snippets and other items that may assist people in implementing the Pattern.
I’m not going to go into defining any of the Patterns at this time. I may do so here if there are requests. Patterns are going to become a larger part of the Developer Network in the near future, probably after the hinted-at arrival of wikis. At that time, I will be taking time to write these out for all to share.
If you have any other Patterns that may fit in this domain, add it in the comments, add it to the Discussion thread on the Developer Network, or just wait for the wiki to arrive.
Remember, Share and Enjoy!
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
