Why SOA Works (QUOTE)

Object Oriented Design works because an Object represents a real-world "thing".

Service Oriented Architecture works because a Service represents a real-world "What we do".

--- 

Not sure whom is being quoted though I found it in "Service Architecture Methodoly, Version 1 - agust 2005, Capgemini".

WCF Windows Service (Debugging)

Seeing the popularity of SOA rising, Microsoft's WCF services are rightfully being used more and more. Ofcourse, those services need to be hosted somewhere. One of the options for this is in a Windows Service (or technically speaking in a Process Service).

But, with the development of Windows Services comes the, generally accepted, burdon of deploying (compiling, installing, starting, attaching debugger, stopping, uninstalling) these services with every change we make, atleast if we do this by the book.

Not settling for that situation I counted my (too many) options and choose the following stratagy:

1) As goes without saying, allways make sure your service has hardly any "guts". Have all the logic in a seperate class that is seperately and indepentdently unittested.

2) Add a "program.cs" to your WindowsService-project, change its type to "Console Application" finally have Visual Studio start that project up when you start debugging your solution. (see source here: Run-windows-service-as-a-console-program.

Happy Servicing


Notes:

• Don't worry, by changing the type to "Console Application" you only tell Visual Studio to start (technically speaking "exec"-buildtask) the main-function of the program.cs you can still deploy your services without any changes to the sources/binaries.
  
  
• Try to group your Services in one Windows Services (technically speaking adding multiple appdomains to the process). If applicable this does save a significant amount of memory.
  
  
• Microsoft's upcoming OSLO concept might make this approach less needed;
  
  
• Add the following configuration block to your "app.config" to get usefull Console output:

<system.diagnostics>
  <trace autoflush="false" indentsize="4">
   <listeners>
    <add name="configConsoleListener"
type="System.Diagnostics.ConsoleTraceListener">
   </listeners>
  </trace>
</system.diagnostics>

The Business-IT-Gap has a face

With all the current hypes, just think about the Architecture, SOA and SaaS hype, you might think that agility, stability and interoperability are goals in itself. That they are specific magical ingredients recently discovered about to solve all IT related problems. This would not be an unlogical conclusion. After all, that's what is being promised you will need and get an agile business because that is what everybody needs.


Is it not? No, not at all!

In fact you just met the "Business-IT-Gap" in person. It might be the manager asking a developer for an application that should (obviously) be flexible and stable. Or it might be a sales person or consultant explaining a client that they really need to go for a SOA-solution for agility reasons. Either way you are actually physically facing a (e.g.: talking/listening to) person embodying the Business-IT-Gap.


Really? Explain!

The whole reason why the Business-IT-Gap exists is because managers have lacked to provide enough guidance about what kind of flexibility and interopability and the dagree of stability is that was needed (a responsibility now being hijacked by people calling themselves Architects).


Lacking this guidance resulted in systems lacking flexibility or the wrong kind of flexibility (thus maintainability) and interoperability. Moreover, because every developer has its own personal view on the type of flexibility needed, changes are that what is flexible in one application is fixed in another. Thus in fact lacking this guidance cannibalized the overall investments in flexibility. Believe me this is not theoretically speaking, this is what I see day in and out! I can't believe nobody else notices this...


So what should I do?

Of course, it's not only you. It's the whole branch! Developers should demand more guidance. Sales people and consultants should not propagate agility, interoperability and stability etc. "pur sang". They should explain that it is about Just Enough and about Just Right and that divers from situation to situation and company to company. You just can't and don't want to be totally agile either given a solution or given an total enterprise. It's about finding the right balance between what can be fixed and what should be flexible. Because flexibility comes with a big cost that can only be returned (roi) if it will be used sooner or later. Just think about architecting a house. Realizing all your dreams and whishes (read: requirements) in a totally agile structure would have you end up with something crazy like a hyper expensive stretchable balloon!

But now that you know, you can and should close the gap by asking the right questions and demanding a reasonable answer!


Happy closing the gap!

SOA In the real world

Een prachtig 'boek' over de concepten en de praktijk van SOA kun je hier downloaden.

Wat mij betreft een 'must read' voor iedereen die niet weet wat SOA is en een 'should read' voor iedereen die met SOA te maken heeft.