|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 9
Messages: 9
Messages: 9
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
The 11th Fallacy of Enterprise Computing
Ted Neward has added to the "The Eight Fallacies of Distributed Computing" originally created by Peter Deutsch (and extended by James Gosling) to add two more in his Effective Enterprise Java book. Over the weekend he came up with the 11th: Business logic can and should be centralized.The reason this is a fallacy is because the term "business logic" is way too nebulous to nail down correctly, and because business logic tends to stretch out across client-, middle- and server- tiers, as well as across the presentation and data access/storage layers.
This is a hard one to swallow, I'll grant. Consider, for a moment, a simple business rule: a given person's name can be no longer than 40 characters. It's a fairly simple rule, and as such should have a fairly simple answer to the question: Where do we enforce this particular rule? Obviously we have a database schema behind the scenes where the data will be stored, and while we could use tables with every column set to be variable-length strings of up to 2000 characters or so (to allow for maximum flexibility in our storage), most developers choose not to. They'll cite a whole number of different reasons, but the most obvious one is also the most important--by using relational database constraints, the database can act as an automatic enforcer of business rules, such as the one that requires that names be no longer than 40 characters. Any violation of that rule will result in an error from the database. The 11th Fallacy of Enterprise Computing
More on the 11th Fallacy
Craig McClanahan responds to the 11th Fallacy
|
|
|
Message #122935
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AOP
I don't fully understand AOP, but after reading the articles I think that this is a perfect example of the use of AOP. Doesn't it allow you to centralize your business logic in on "place" while still using it across multiple tiers? Like the name thing here. Put the name rule in the "rules" aspect. Every tier looks to this aspect to decide what it will do with the rule information. if its a web form, put in some javascript to defend against long names. If it is the DB then put in a varchar length of 40. if the rule changes then the individual tier will deal with it appropriately. So doesn't it make sense to Almost always centralize yor business logic in this way?
|
|
|
Message #122984
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The 11th Fallacy of Enterprise Computing
Always the problem really: you ideally need to check your business rules (things like field value constraints) at each tier because you can't/shouldn't/didn't rely on the tier above to check those constraints... but in order to prevent unnecessary processing requests, you don't really want the database to be the "first and final check" for your data constraints (because someone leaving off their last name should give very fast feedback to the user)
Web apps are a great one: you have tiers, at bare minimum you have client and your webapp server tier. Generally you'd use javascript or something to catch the easy errors, like forms not having all mandatory fields filled out, number of characters etc.. But you can never assume this will take place (can just turn off js, or manually hit the URL). So even with just two tiers there is a need for two lots of code to enforce the "this field needs to be filled out" rule. Add in a typical database as well and you now have the "need data" rule present in javascript, jsp's/servlets/javabeans, and in your table schema.
Say I now want to change that business rule about the data.. I have to change it in each of the tiers. Which is all well and good until I forget to change it in one spot. So what's really needed is to centralise the business rules and distribute the various "engines" which can apply the business rules.
As yet, I haven't come across anything which does this across everything.. Fair enough across javascript and jsp/servlets, but across anything further back it starts getting a bit messy (the database is the killer I think.. without some messy stored procedures or else regenerating the table constraints all the time.. ).. But taking that approach you can perhaps have the "centralize business logic", all it has to do is have a sophisticated enough set of engines and a rich enough language to describe the business constraints on the data.
That's at least some ideas on the data constraint aspect of business "logic".. Guess the same could apply for some of the business processing logic.. Though generally the actual processing type logic need take place only on one of the tiers. and you have to ask: at what point does trying to centralize things make the application less reliable/understandable/maintainable/realisable/testable through trying to use generic declarations of the business logic versus just coding the business logic where it needs to be..
regards,
Nathan Lee
|
|
|
Message #123007
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AOP
I don't fully understand AOP, but after reading the articles I think that this is a perfect example of the use of AOP. Doesn't it allow you to centralize your business logic in on "place" while still using it across multiple tiers? Like the name thing here. Put the name rule in the "rules" aspect. Every tier looks to this aspect to decide what it will do with the rule information. if its a web form, put in some javascript to defend against long names. If it is the DB then put in a varchar length of 40. if the rule changes then the individual tier will deal with it appropriately. So doesn't it make sense to Almost always centralize yor business logic in this way? Michael,
I couldn't agree less. My understanding of AOP is that, the business rules are the various 'aspects' of the system.
We almost always have to deal with 2 important concerns while designing an application.
1)The "hierarchial relationship" between the business entities,and
2)The "business rules" which apply on the business entities.
Again,there are 2 different types of business rules
a)The rules which define the various types of interaction between the business entities. b)The rules which validates individual entities. Both these rules ,combined together,form the aspects of the system.
If we are able to maintain the "hierarchial relationship" in one single place and seperate out the business rules into a 'another layer' and
|
|
|
Message #123009
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AOP
I don't fully understand AOP, but after reading the articles I think that this is a perfect example of the use of AOP. Doesn't it allow you to centralize your business logic in on "place" while still using it across multiple tiers? Like the name thing here. Put the name rule in the "rules" aspect. Every tier looks to this aspect to decide what it will do with the rule information. if its a web form, put in some javascript to defend against long names. If it is the DB then put in a varchar length of 40. if the rule changes then the individual tier will deal with it appropriately. So doesn't it make sense to Almost always centralize yor business logic in this way? Michael,
I couldn't agree less. My understanding of AOP is that, the business rules are the various 'aspects' of the system.
We almost always have to deal with 2 important concerns while designing an application.
1)The "hierarchial relationship" between the business entities,and
2)The "business rules" which apply on the business entities.
Again,there are 2 different types of business rules
a)The rules which define the various types of interaction between the business entities. b)The rules which validates individual entities. Both these rules ,combined together,form the aspects of the system.
If we are able to maintain the "hierarchial relationship" in one single place and seperate out the business rules into a 'another layer' and empower this layer with a special feature,by letting it intercept the hierarchial relationship ,at runtime,then we are dealing with aspect oriented programming.
The main challenge,i feel,is that we always maintain the "hierarchial relationship" between business entities ,in more than one layer. The application layer ,if object oriented,provides the relationship between abstract entities,but the relationship between actual business entities is implemented in the database. Since,aspects intercepting the data layer is ruled out,it can only implement those business rules which are applicable to abstract business entities.
The another approach to this problem,which struck me often,is that we should introduce one more vertical layer ,before or after, the middle layer,which will take care of validating the business entities,since we laready have the middle layer taking care of the first type of business rules.
surajeet
|
|
|
Message #123014
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A good argument against dumb VOs/DTOs
It's one of those quixotic crusades of mine, I firmly believe that all non-layer specific logic can and should be encoded in a way that is applicable across all the layers.
What exists on almost all the layers? The humble DTO.
It's always irritated the heck out of me the insistence that we be as un-object-orientated as possible and keep all logic out of these objects. Most arguments against it assume that it's an all or nothing propositions - All logic or no logic. No it isn't, just put the layer independent logic in.
I've heard some very specious arguments against this before, the real humdinger was the one that it would cause the communications to slow down because of all that logic that had to be transported between layers.
I admit that this is likely to be flame bait - but consider this point, you can localise a lot of business logic to just one set of classes, nicely satisfying DRY. The checks are performed on multiple layers, but isn't that the point?
If you want to go a little further you can make the DTOs use a validation factory to perform layer specific checks.
Bob Boothby.
|
|
|
Message #123017
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Sounds like an Anti-Pattern to Me
When I read Deutche's fallacies:
http://today.java.net/jag/Fallacies.html
They appear to fall into a different category than what Ted is throwing out there. Ted's statement reads more like an anti-pattern to me than a fallacy. I'm certainly in favour of exploiting the database for enforcing data relationships for example (at persistence time) - and for simple SSN validation why not do it in the web tier? As with most things in s/ware engineering, I think it is dangerous to get too dogmatic about these things.
As I work on the ILOG JRules product I also get to see a lot of business rules. Most are significantly more complex than the simple field validation examples cited here. In many cases there are thousands of business rules being maintained by dozens or hundreds of business users (not developers). In these scenarios (insurance, banking, car hire for example) there is a enormous amount of value in centralizing business rules. Additionally government compliance regulations may make this a requirement for accurate audit purposes.
Sincerely,
Daniel Selman
|
|
|
Message #123026
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A good argument against dumb VOs/DTOs
The humble DTO.It's always irritated the heck out of me the insistence that we be as un-object-orientated as possible and keep all logic out of these objects. Most arguments against it assume that it's an all or nothing propositions - All logic or no logic. No it isn't, just put the layer independent logic in. Now this is going down to the level of mobile code, even perhaps templating that can be transformed on each node in the layer.
This is where things like Jini and agents come in, because we have mobile objects and Java's ability for mobile code (and with Jini, secure, location-independent mobile code), and agents can extend an object's capabilities to not only represent attributes and behaviours, but also a concept of location/environment.
The DTO point, annoys me as well. Sure, make a coarse grained object because we need to reduce number of transfers, but that doesn't mean that all the logic should go out of it. Take JavaSpaces and Entries, these can be (and are looked up as) basic DTO's but there is _nothing_ that prevents the Entry classes from having behavioural methods.
The issue is that if the IT world is moving (or insisting we move) to a Service Oriented Architecture, the problems of the basic DTO will come to the forefront. We need SOA simply because we are getting to the point where you can't put all logic in either one layer or one machine, due to various reasons, such as massively heterogenoeous environments, different operating systems, mergers and acquisitions, and even something as banal as office politics.
|
|
|
Message #123044
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I see
I guess my interpretation of AOP was that it created vertical layers. Maybe not. Although the vertical layer you talked about is sor t of what I had envisioned.
|
|
|
Message #123137
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Missing some of the point
I think this is a really good blog, but the examples about storing business rules in the database generating a lot of server requests sort of misses the point.
Rules like this should be enforced at the user interface level because they make it better for the user.
Choice A) Allow the user to enter as many characters as they want and send the data back to the database. The database either truncates the data or sends back some cryptic error to the user about how "table.column constraint x violated" and the user has no idea what's going on.
Choice B) Let the user enter whatever they want, but if they enter too many characters pop up a javascript alert window when they submit that tells them in English.
Choice C) Limit the number of characters the user can type. When they get to the maximum length stop accepting input and give a beep.
Choice B and C are equally efficient in terms of server hits, so the programmer should be free to choose either. Wrong, choice C is better for the user. They get immediate feedback of their mistake, no intrusive popups, don't have to look at the screen even to know what's going on, etc...
Programmers spend way to much effort trying to do all this stuff to make the computer happy and forget that at the end of the day all this stuff is for humans. Centralizing all the rules may make a program more efficient or easier to maintain, but can be murder on the end users.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
