Session Beans implement business logic and workflow in a server-side EJB design. Use cases are widely used for specifying workflow. Thus, architects naturally draw upon use cases to identify Session Beans. However, given that use cases do not have a formal definition, two analysts may come up with different sets of use cases for the same problem, leading to different sets of Session Beans.
We inject more objectivity into this process by adopting the Event Partitioning (EP) technique in conjunction with the concept of control objects. EP drives use case definition by focusing on external business events that impact the system; a use case is the system’s response to a business event. A control object models system functionality that cannot be naturally ascribed to a single entity object.
The key idea is to translate control objects (controllers) to session beans, and use EP as a candidate technique to arrive at these controllers. By default, we associate a controller with each event (use case). A controller orchestrates the task execution for its use case. We then look for controllers whose functionality may naturally be assigned to some entity object, and get rid of these superfluous controllers. The end result is a smaller set of controllers, which translate to session beans. To this list we may add specialized beans for, say, encapsulating patterns such as Façade for improving performance.
In typical Web applications, the controller may either be in the presentation layer (as in servlets) or in the service layer (as in enterprise beans). We choose them to be in the service layer as it offers several advantages such as reduced network traffic and ease of transaction control.
Now that we have identified the session beans, which of these session beans must be stateful? A session bean must be stateful if it orchestrates a processing sequence in which control returns to the browser before the sequence is completed.
Rajeshwari & Shubhashis,
Software Concept Lab,
Infosys Technologies Ltd.
Can you please give us more information about thr Event Partitioning (EP) technique and the concept of control objects.
Jacabson divides the classes of an object-oriented design into 3 types
Entity objects drop out of the system's ER diagram and represent business information.
Interface objects encapsulate the mechanics of interacting with users and external systems.
A control object models system functionality that cannot be naturally ascribed to a single entity object. These classes will orchestrates the task execution for its use case. For example consider a Internet auction site which has an usecase "search for item". Suppose the entities for the Auction system are "Member" / "Auction" and "Item". The search cannot belong as a method to any of the entities. This will form a "controller". However if you had a usecase "Add Auction", this could be ascribed to "Auction::Add()", hence this will be a method of the class and not a controller. Do u get my point?
Event partitioning technique clearly delineates an event. An event is initiated when an external stimulus is exerted on the system and is finished when the system has done something in response to it. Ideally the outcome of an event will be system sending a message to a terminator or system changing its internal state in response to the stimulus. For more reading refer to E Yourdon, "Modern Structural Analysis", Yourdon Press Computing Series, 1994
your artical is excellert but I have a couple on concerns though. Is the controller class depend on the number of entities that gets interacted with in a use case or is there any other method by which the controller can be determined i.e. if my "xyz" use case has 3 entities then I should mapp it to a controller class, and if I have only one then make it as an entity.
It seems the defination of the controller is similar to the defination of control classes in UML.
The terminology and base paper that this pattern is sourced from is a little out of sync in concept in terms with UML. In UML, the common analysis class sterotypes used are <
But, what isn't a small issue is the focus on these stereotypes being part of the "analysis" process -- not really part of the design/implementation model. Even in Jacobson's original OOSE the use of the three stereotyped classes (then called interface, entity, and controller) was part of "robustness analysis" and was used in large part the way it is used today -- to bridge the gap from the use-case world into the "OO" world and allow for the realizations of use-cases using scenario diagrams.
The confusion probably comes from the fact that Jacobson had models called "Requirements model" and "Analysis model". Our Analysis corresponds to his Requirements, and his Analysis overlaps with our Design. The key point is that Entity, Interface and Control objects are design decisions, not essential aspects of the problem domain.
Jacobson's notion in OOSE of interface, controller, and entity objects were used in "robustness analysis"... RUP does not explicity talk about robustness analysis as a distinct lifecycle phase but in UML there are three sterotypes analogous to the original Jacobson ones -- boundary, control, and entity.
Regardless.. the use of these stereotypes is not really a design activity. The value of the three stereotypes is that is allows for a migration from the system use-case model into the object model by creating collaboration and use case realizations.
The mapping of interface, control, and entity classes into design classes which can be implemented (regarless of whether that be in j2ee, etc.) is still non-trivial for many large and scalable applications. Your paper and pattern capture is something we've seen many clients moving towards and makes a greatset of heuristics and first cut..
These three stereotypes help in setting the boundaries for the system, EP and performing the analysis. But it's the extend to which we perform the analysis activity one performs which might lead to the design activity. These three stereotypes are just means to achieve the above activities. If David is referring to Object Domain Model by "the object model" then that is something which is generally done during the business modeling and gets evolved as we proceed in elaboration phase of RUP. Another point worth noting is that the development is Architecture Centric and Use Case Driven. So, ultimately, once decided upon the architecture, the development revolves around the architecture. So, apart from the Domain model, there are subsystems which must be designed to support the architecture and realize the layers and services as narrated in the architecture.
Considering the Auction example, does it mean that the controller does sort of in-memory joins of the entities -Item, Member and Auction?
For more details on this article please refer to:
1)According to your article "...session beans implement business logic and workflow.....".So are you considering Entity beans just as an objectified interface to the database?
2)In a system with numerous use cases if you try to map all the events to session beans the system will be flooded with Session Beans even if you remove superfluos controllers.Dont you think that this is an overkill?
What is your comment on having a single controller which takes the request code and then creates dependant object/objects which will do the further processing.
3)What I understood from the article was that Event Partitoning(EP) is used to arrive at a common use case instead of different sets of use cases for the same problem.So EP is useful in constructing use cases which is a technique used for requirements gathering.
Actually the work of EP ends there.The concept of Control objects is the one which is having more importance.Correct me if I am wrong.
thanks & regds
Here are my comments...
In EJB based scenario, session beans implement business workflow and processes. This does not mean they cannot implement business entities.
A given logical component can be a - process component or a entity component. How you implement the logical component physically is a matter of choice. For eg. if you have a logical entity component you can model it as session bean or an entity bean in an EJB framework. Though by default entity bean is used. These physical implementations are based on the contraints of the environment and the quality attributes the system is intended to perform. For eg.One particular implementation for a project used EJB 1.1 with NAS 4.0. In this environment, applications deployed using entity beans as domain objects experienced severe performance problems. The team resorted to using session beans for domain objects along with an object-to-relational mapping tool (Toplink).
The main aim of CBD is reuse. So if components have to be reusable, what should be the granularity of these component be? The pattern address this issue. The design prescription suggested ensures that the components that are created are :
1. coherent unit.
2. exhibit low coupling with other components.
Having just one controller which maps to bean will lead to big component that will be less reusable. For example, assume that the concepts of warehouse and inventory have been combined into one component. This could be problematic if a future application needs warehouse information, but not inventory information.
Similarly, smaller component tend to be more flexible. It’s also easier to reuse them in future applications. Unfortunately, smaller components typically result in a higher degree of coupling. One will find significantly more interactions between smaller components. This could also lead to performance problems. If two or three small components send each other a lot of messages, it might make sense to combine them into one. Smaller components may also be more difficult to manage, simply because more of them exist.
EP technique allows one to arrive at the usecases that satify the principles of component design - high coherence and low coupling. Notion of reusablility and extensibility of components is brought forth by this.
Software Concept Lab,
Infosys Technologies Ltd.
Read ur article at infosys site. It looks like it is another representation of MVC architecture which I beleive solves lot of issues in an object oriented world. But when you consider specifically wrt EJB's, it boils down to in-memory joins of entity beans, for some usecases.
Mapping Process definitions/system usecases into business usecases are perfect but how efficiently one can do with EJBs. Considering a typical query aggregation usecase where you are making a join call on tables/objects - say E3 of your article, won't it be a killer performance wise if you use Controllers and entity objects?
well i saw ur comments about components granularity. Now this is a major problem and usually we find ourselves making components that are not reusable at all or to a vrey low extent. Usually we end up making a very large component or small components with high coupling (both have their problems and are not reusable). The only re usable components that i have come across till now are not Business Components but some components relating to the Presenation layer that can also be generic.
If you have been successful in making some resuable Business components then i will definitely like to share the experience.
I think if we were to use one session bean per event then there will be too many session beans. Do you have any other way to identify the session beans needed???
With respect to the questions about Event Partionining.. In addition to Yourdan's "Modern Structured Analysis" -- which is a good book on SA but is filled with typos, another reference is McMenin & Palmer's "Essential Systems Analysis" which really helped to make EP more widespread in the SA/SD community. Also, the notion of "essential" analysis comes from them and is slowly weaving it's way into use case analysis and user-centric design -- for example, the latest version of the Ration Unified Process has a concept paper on essential use cases and UCD.
Without looking up the references if you don't have them, a simple way to think of EP is to determine the external entities of the system (i.e. the actors in UML speak) and list the major events/messages/commands that flow between the system and its actors...