Anti-pattern of SOA or WCF

Question

While I can find lots of article advocating SOA, or WCF, my question is that what should not be exposed as service, is there any lessen that we learn from SOA failure. WCF is a way to implementing SOA, if we use WCF, does that means we are implementing SOA. For sure there are lots people using C# writing unmaintainable code.

Answer 1

I think you're right. In my current assignment (web development), every single access to the database is implemented as a service. We are "PURE SOA", as the lead architect said... Wow !

In facts, this adds a lot of complexity to everything. When I want to read the content of a simple table, I must generate something like 8 projects, 42 files, 8 assemblies and probably 9 config files !

A lot of complexity as I said. Chances are someone somewhere will forget one file... Exposing simple process as a service is stupid.

In my books, you should expose your processes as a service when :

• Many applications using different languages and frameworks have to call your stuff.
• There are more than one platforms involved (Windows, Unix...).
• The data being handled are the core of the enterprise.

Also, notice that a service must be DESIGNED to be a service, and that designing a service is at least as complex as designing a library : error trapping must be carefully crafted, logging must be flexible enough, documentation must be complete, etc.

Well, as I can see, most of the services I use daily will not be used by other people : no documentation, poor error handling, code subject to frequent changes, second zone data...

Very interesting question. 1 point :o)

Answer 2

SOA as a concept is a great idea.

SOA as implemented using HTTP-WS/BPEL et al is a joke that deserves to die in my not so humble view. I stopped taking the system seriously shortly after learning their only concept of distributed transactions are compensation transactions... bzzt NEXT!!

Answer 3

There are two major anti-patterns I am aware of:

• Directly exposing objects from your business layer through your service layer
• Exposing specific fine-grained methods, like those in your business layer

The recommendation is for your service layer to contain coarse-grained, generic methods, and for them to accept and return somewhat large message-based requests and responses. The goal is to provide a fairly generic interface, without making too great of assumptions about how the service will be used, and without requiring numerous calls to achieve basic functionality. Try to minimize the number of web service calls.

Here is some excellent advice at a high level: http://apparchguide.codeplex.com/Wiki/View.aspx?title=Chapter%2013%20-%20Service%20Layer%20Guidelines

Here is a specific example of the type of "message" classes that guide is talking about, and how to implement one in WCF: http://dotnet.org.za/hiltong/pages/windows-communication-foundation-tutorial-part-3-messaging-messagecontracts.aspx

Answer 4

I published a few SOA anti-patterns

• Transactional integration anti-pattern
• The Knot anti-pattern
• Nanoservices anti-pattern

The point is that a lot of people regard SOA as putting web-service front end in-front of logic and forget the implications of the resulting RPC (also known as the fallacies of distributed computing)

Answer 5

SOA is one of the worse presented concepts. SOA is an architectural style and has nothing to do with web-services or any technology. I agree that explaining SOA through web-services and BPEL is plain misleading, BPEL has usually nothing to do with SOA but instead is a way to implement WS orchestration. Vendors made an awful mess of it.

I suggest a very nice downloadable book, which explains really what SOA is:

http://www.infoq.com/minibooks/enterprise-soa

Then you could read this interesting blog entry

Regards