The problem is that there is another concept that is rarely listed, what are your anti-principles?
In the same way as Anti-Patterns give you pointers when its all gone wrong then Anti-Principles are the things that you will actively aim to avoid during the programme.
So in an SOA programme people will fire up principles of "Loose Coupling", "Clear Interfaces" and the like but they often won't list the Anti-Principles. These are often more important than the Principles. These are the things that indicate danger and disaster.
So what are good (bad?) SOA anti-principles?
Small return Values
This is where people have been used to Batch interface where returns are just codes and descriptions with reports being used to indicate problems. The sort of statement here is just return a code and description rather than returning a decent amount of data
Direct Calling
This anti-principle is all about where people just get a WSDL and consume it directly without any proxy or intermediary. Its programme suicide and it shouldn't be done
Interface Generation
This anti-principle says that you shouldn't generate your interfaces from code but should design them up front and make them explicit. So from an anti-principle perspective you are banning the "right-click generate WSDL" IDE approach to Web Service exposure.
No matter what the project you are doing you should think about your anti-principles as much as your principles. Think about what is bad practice as much as what is good practice. Make it clear, make it explicit.
Anti-Principles - making clear where people are going wrong.
6 comments:
Hi, would you please elaborate on Direct Calling ? What kind of a proxy or system in between should we use and for what purpose ?
Regards,
Bulent Erdemir
Bulent,
Direct Calling means just discovering a WSDL and making the direct call from the consumer without any intermediary. The intermediary can be a "pass through" (i.e. does nothing) but it needs to be there so that in future as things evolve it is able to insulate consumers from that change. There are 3 levels of intermediary that are required
1) Service producers should always proxy before exposing.
2) Service consumers should always proxy before consuming
3) There should be an intermediary between the producer and consumer.
Now this could be as simple as having a DNS switch that can be used to put in place more intermediary functionality in future or it could be an ESB, HTTP Proxy or something else. The point is that direct calling of a consumer to a producer creates a tight coupling between them and makes change difficult.
About "direct calling",
I think it's over the top to create proxies (ESB flow) for all services.
How do you think about the below link?
http://blogs.mulesoft.org/to-esb-or-not-to-esb/
hiki, the point of that Mule post is one I agree with. A fully fledged ESB is not always required. The point of enabling a proxing model however is to make sure it can be added simply if the problem scales to a level that demands it. A proxy could be as simple as a straight re-direct at first but the point is that the model is there to enable a more formal intermediary to be established.
What about systems exchanging huge amounts of data on a regular basis so each can have its own "local" copy of the data? When should you consider this a necessary evil and where does it indicate a broken architecture?
Todd, I think you've hit the nail on the head. Anti-principles are context specific while anti-patterns tend to be universal. If you have two systems (say an MDM solution and a CRM solution) then having two copies of the data could be acceptable. Equally if you are using the information for different purposes (fast operational access v data warehousing) then it would be fine. On other occasions it would be the wrong thing, e.g. people just taking a local copy because they have some mythical belief in local databases.
Post a Comment