in Search

Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

Pragmatic viewpoints on SOA

From DonXML,

Intro to Web Services - It's All About the Message - NYC Code Camp

Writing WSDL by hand seems about as efficient as writing IDL by hand back in the COM days. Every time I'm involved with web service creation we concentrate on creating Data Transfer Object classes to represent the message and let the .Net framework worry about WSDL. It makes evolutionary design of web services and TDD with mocks a lot easier too.

Regardless of your style, you should never, ever couple your internal business classes to the messaging schema and vice versa. Unless you don't care about maintainability anyway.

From Udi Dahan, Common SOA Pitfalls as well. What he describes seems pretty dumb to me, but I've seen the exact same thing proposed a couple years ago at a former employer.

Published Feb 26 2006, 03:39 PM by Jeremy D. Miller

Comments

Don Demsak said:

Try out the WSCF VS plugin. You only need to write the XML Schemas by hand, and the plugin handles the WSDL. I agree, no one should ever have to write WSDL by hand, ever. WSDL screams for a tool to create it, and WSCF does a great job. This way, you can concentrate on XML Schema.

# February 26, 2006 5:27 PM

Joshua Flanagan said:

Be careful with that interpretation; proponents of contract first service development do not advocate writing WSDL by hand as an ideal solution. While the current tooling (or lack of) may require a bit of direct angle bracket manipulation, that is not the crux of the argument.

The point is that the contract is a critical part of your service. The WSDL is a representation of the portions of the contract that can be codified. Contract first proponents are suggesting that's the part you should be intentionally designing, as opposed to leaving it as a side-effect of your current platform's serialization engine. There is no philosophical opposition to tools that let you author your contract without getting into the XML details.

Of course, this only matters in a truly heterogeneous environment. If you are only going to call your .NET web services from your own .NET clients, then there is no danger in code-first services (although you may want to consider .NET Remoting).

# February 26, 2006 7:29 PM

Jeremy D. Miller said:

Josh,

Remember that you can control the serialization of the DTO to your heart's content with attributes. As long as you stay away from exposing DataSet's as part of the DTO or sending XML in a big string blob like something called Photon that you might remember. You're perfectly fine as long as you're sticking to primitives and structures of primitives.

I've usually been in the situation where I control both the client and server. In that case I prefer to code the client first and drive the design of the DTO via TDD to meet the needs of the client. That, IMO, is the best way to create the message structure.

If you're building the schema/message in a manner that's divorced from the needs of the client, you're very likely to create something that's wrong. The whole "build it and they'll come" attitude of some integration architects is a waste of valuable resources.

# February 26, 2006 7:46 PM

Don Demsak said:

Manual trackback.

# February 26, 2006 8:42 PM

Joshua Flanagan said:

Well, I was going to respond by saying that if you are using DTOs and care enough to mark them up with attributes, then you are already on board with the contract first ideals... but Don beat me to it with his post, so I'd just come off as a "me too" if I said anything...

# February 27, 2006 12:25 AM

johnwood said:

>> Regardless of your style, you should never, ever couple your internal business classes to the messaging schema... <<

I would take that one step further and say that you shouldn't have business classes to start with. If internally you're all OOP and externally you're all SOA then you're just faking it and you'll run into trouble down the road for sure. The whole point of contract first is that you start out with a schema, a model. This is your data model, throughout your application. Sure you may need view-models and various other translations of that model internally, and you will need type safe DTOs, but by creating business objects you're developing business functionality that is tied to the class and is hidden from the enterprise, and that goes against everything SOA stands for.

# February 28, 2006 12:20 AM

Jeremy D. Miller said:

John,

Not to flame you, but your comment hit a nerve with me this morning.

I couldn't possibly disagree with you more. It's called loose coupling. Tieing your business logic to the message transport is the strongest possible coupling you can do. You've totally destroyed your ability to change business logic without breaking the externally facing services.

Behavior and business logic is best accomplished by the Domain Model approach. I.e., business classes with behavior. You obviously can't expose these Making the DTO's be the real business entitites leads you back to a procedural "Transaction Script" with code duplication galore. Maybe your service layer is simpler, but your internal application architecture would be a pile of shit.

Back to Udi's post a little bit. I'd really question the value of a service that does nothing but expose data. Does it really pull its weight? Isn't it a little bit stupid to scatter the actual business logic that acts on a business entity over other services? You don't pull data across the wire and then process it. You do the processing at the point where the data is known to maximize code reuse and cohesion. SOA doesn't change the fundamental rules of development. Yeah, you expose an endpoint to exchange messages to open this business logic to other systems.

SOA is integration and external transport. Building a good internal application architecture, where most of the functionality still is, means loosely coupled OO.

"you're developing business functionality that is tied to the class and is hidden from the enterprise, and that goes against everything SOA stands for"

- it's not important to stand for SOA. It's important to deliver value and I think that's best done with good code. Assuming that I write good code, I can extend good code more efficiently than by adding more unnecessary remoting and messaging. If I decide to expose a service off of my application later, I can do it because the code is loosely coupled to begin with.

# February 28, 2006 7:51 AM

johnwood said:

Jeremy,

So then why is it called SOA and not Service Oriented Transport? SOA is all about loose coupling. OOP is all about tight coupling. You seem to be implying that you need OOP in order to layer, but that simply isn't true. By developing an architecture where service encapsulation is possible, with a decent ESB and framework, you can accomplish service encapsulation and implement layering without resorting to putting/hiding all your business logic in classes.

The domain model isn't the only, nor the best, solution to developing business layers. If it was Fowler's book would only have one chapter. You end up with hidden business logic, it restricts your ability to re-use the business logic because it's tied to the data in the class and the class hierarchy, your business logic ends up being scattered throughout the system rather than focused in one place, and developing the service facade over this is tricky because it's difficult to pinpoint the remoting boundaries when all your business objects are stateful.

Yes SOA is a combination of transaction script and service layer patterns but again to think that OOP is the only methodology or domain model is the only pattern that allows reuse just isn't correct. To the contrary, services promote *more* re-use than objects because of the loose coupling between the data and the logic.

>> Assuming that I write good code, I can extend good code more efficiently than by adding more unnecessary remoting and messaging. <<

The difference between our philosophies is rooted on the fact that I believe that SOA should deeply manifest itself in the design of business applications, and you think SOA is a nice solution to remoting. And to be honest I think you're missing out.

# February 28, 2006 10:24 AM

Jeffrey Palermo said:

John,
I look forward to seeing a blog post from you describing what your SOA architecture looks like and how it has worked for you.

Your comments make me scratch my head for a bit because SOA is not a new topic, and before web services, people used DCOM to make it happen, and all of that was implemented with classes behind the service interface.

Anyway, I'm not getting your full thought process just by these few comments, so I hope you'll expand and dedicate a full post to the subject. Along with that I'd like to hear of past experiences you've had that worked and experiences where stuff didn't work.

# February 28, 2006 12:46 PM

John Wood said:

To dismiss SOA as "a web thing", "an integration issue" or an "XML remoting solution" is, I think, missing...

# February 28, 2006 3:06 PM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?

Enter the numbers above:

Add

About Jeremy D. Miller

Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#.

This Blog

Home
Contact

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab

Jeremy D. Miller -- The Shade Tree Developer

Pragmatic viewpoints on SOA

Comments

Don Demsak said:

Joshua Flanagan said:

Jeremy D. Miller said:

Don Demsak said:

Joshua Flanagan said:

johnwood said:

Jeremy D. Miller said:

johnwood said:

Jeffrey Palermo said:

John Wood said:

Leave a Comment

About Jeremy D. Miller

This Blog

Syndication

Recent Posts

Tags

News

Blogs I Read

Archives