At the Microsoft Patterns & Practices Summit in Redmond today, SOA and distributed architectures were the topic of considerable discussion. Rockford Lhotka, principal technical evangelist at Microsoft partner Magnetic and creator of CSLA .NET, said SOA is nothing new. But he has started to see some best practices emerge in building distributed parallel systems.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
“The term SOA, frankly, frustrates me. I said a couple of years ago that the ‘S’ in SOA is a dollar sign,” said Lhotka. “Service orientation is looked at by a lot of people as this shiny new thing when it’s really something we were already doing 20 or 30 years ago called message systems.”
He went on to explain that developers have been using objects for many years before the industry created the term “services.” But now that it’s called SOA, consultants are making a lot of money explaining it to clients.
Creating distributed applications where code spans across multiple machines and data centers is all about efficiency. As such, it is wise to avoid anything that could cause a system to waste messages. And now that processor speeds have all but ceased to increase, processor performance is boosted by incorporating numerous cores that can work in parallel.
In SOA – though Lhotka does not like to call it that – developers often must merge parallel and distributed computing. To keep performance high, Lhotka said there should be no resource sharing between disparate components. In it’s place, applications should be broken apart and run in parallel with a strong independent messaging system.
A perfect example for how this is done in incredibly rich applications exists in the video game industry with games like World of Warcraft. In this particular game, users travel through literally an entire visual world. The reason users’ systems don’t overload and crash is their machines only render the small area of the map they inhabit at a given moment.
“You should avoid shared resources because then you have to have some sort of lock management – some sort of access control,” said Lhotka. If resources are shared, services can end up spending a lot of time figuring out what resources other services are consuming.