little while ago, Ron Jacobs, product manager for the patterns &
practices team, addressed issues of patterns for SOA, with an eye
toward .NET. Jacobs said there are four major tenets to be considered
when designing service oriented applications.
These are: boundaries are explicit; services are autonomous; services
share schema and contracts, not classes; and service compatibility is
determined by policy. Underlying these tenets is the notion that
systems must be built to anticipate change -- that they will need to
adapt to new services in the future.
Anti-patterns
Jacobs mapped out the path to successful patterns by outlining a few
"anti-patterns." These are software design "solutions" that tend to
achieve negative results.
"The goal of SOA patterns is to bring loose coupling to architecture
for systems that sustain for a long period of time," Jacobs told
TheServerSide.NET, "But anti-patterns do just the opposite. They have
you use loosely coupled Web services in a tightly couple way."
Like others, Jacobs emphasizes the importance of creating good SOA
contracts. Here flexibility and extensibility can become negative factors.
He said: "One anti-pattern I describe is 'loosey-goosey.' This is the
idea that you are going to have an interface that accepts a fixed set
of things but which also [allows] an extensible hunk of XML that
someone might send. If I do this, the contract is weak."
If you use a pattern like this, you tend to rely on the implicit
behavior of the service, he indicated. It works, but can falter when
it encounters services outside of its initial experience.
"If [an architecture] is based on implicit behavior," said Jacobs, "it
is very fragile."
The message is the message
Like others, Jacobs points to the experienced distributed systems
designers' natural tendency to create RPC-based systems, which showed
up in the first days of Web services. With Windows Communication
Foundation as it is now constituted, message-based systems are
expected to become more common.
"In the model of RPC thinking, you have parameters you send to a
procedure. Originally, with SOAP [Simple Object Access Protocol],
there was an RPC style of SOAP and a document style of SOAP, and the
market chose the document style," said Jacobs.
In document or document-processor styles, system boundaries become
more explicit, thus achieving one of Jacob's main SOA tenets. "It is
also important to keep the [system] details confined within these
boundaries," he said.
"The goal is to do more while knowing less. Knowing less about the
system you are using is key," said Jacobs. In designing interfaces,
especially, you do not want developers to have to know implementation
details about the systems with which their systems interact.
Better results
One thing that makes the recent SOA crusade a bit different than
previous distributed architectures is the fact that Web services
standards have been made available. But , as Jacobs attests,
architects quickly realized that Web services alone did not assure
better software interoperation -- just as merely moving from DCOM to
WCF does not assure success.>>
You can read this in full at:
http://www.theserverside.net/articles/showarticle.tss?id=SOAPatterns
Gervas
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
