A Service Oriented Geek - All Comments

re: It is official, I am a Microsoft Premier Field Engineer!!!!

anachostic — Sat, 15 Dec 2007 17:21:28 GMT

Congratulations!

Honestly, I'm surprised. I thought your blood had turned green for life, but I guess you're not ready to fall back in the hammock.

If you're having a goodbye lunch/dinner, I'll drop by.

re: The Seven Deadly Sins of SOA

tom.fuller — Fri, 09 Nov 2007 16:33:48 GMT

pkr,

I think I sort of shor-circuited what I mean by do not design for just the hear and now. What I wanted to impart is the benefit of delivering to the broadest interoperability spec from the get go. I also like to look at things like flexible data responses that can be changed by the consumer (think option enumeration that says get me order or orderwithdetails). I also don't mean you have to implement every branch of this when you begin but you have to think about that logic as being something that other consumers will want to modify. This is a big contract/interface first type rant really. Just be sure you aren't limiting your ability to evolve your contract without dramatically breaking all of the existing consumers.

On top of that, I am always frustrated by those that believe their application requirements have somehow figured out the only way this code will ever be called for eternity. Very often I am in design "discussions" about building logic into a central component that could someday be exposed as a service and there's this immediate pushback that this logic won't be used in an OLTP type fashion. It's only for batch processing ... ever ... I know it for sure ... the soothsayers up at the top of the hill told me so it must be true.

That's where I think there's big mistakes being made. If you don't at least consider how to factor your code to look at making that component useful to non-batch oriented processes then you've just delivered a one off piece of code that is legacy as soon as you install it. I guess that's what I mean. It's more of a consider the long term vision for the key business components/processes whenever you're delivering anything and if you can deliver it as a something that is service oriented ... do it.

I think this is different than what you were thinking I was recommending. I don't believe you go out and guess how to implement requirements that don't exist but you do have to be prepared to evolve in that direction. Does that answer the question?

re: The Seven Deadly Sins of SOA

tom.fuller — Fri, 09 Nov 2007 16:33:27 GMT

anachostic,

In response to your first point about whether or not a consumer should be able to access the business object directly. I think there's been a lot of evidence collected that steer designers away from exposing business object behavior directly. Now from a layering perspective that may just mean you're building a business services layer (aka business workflow) on top of the business component. The next quesiton is do you also put a layer in front of that which can abstract the technology choice you make for distributing your code. Now this is where I have admittedly "softened" on my opinion. In the past I've been a hardliner that said just make it a web service. ASMX is not going to kill your performance enough for you to avoid it so just do it and that way you've used the most reusable technolgy mechanism from the start. Well, this always come under heavy attack/scrutiny (even though I believe the performance issues we're talking about here are insignificant). So this is where I will now say you can make direct calls to a service interface that is implemented as a simple set of public methods that another consumer can reference. This is your "direct call" model. The problem that comes now is how do I manage versioning and deployment. I am now forced to deploy that DLL to numerous locations and attempt to keep them in sync. This is why I would also build the service interface that implements any number of WCF bindings and if the consumer can migrate to the central version some day then they're much better off.

Now on to your comment about performance. This once again comes back to how you feel you want to manage and scale your business logic. If you feel comfortable making the "direct call" approach an option then you have to be prepared to scale each of those applications depending on their user demands. If you decide you'd like to have a single location to version and scale your business logic (imagine you have a fat client, web client, and mobile client all using the same business logic) then you can take advantage of more robust hosting and load balancing technologies centrally. This is more of a "to distribute or not distribute question". If you look at some of the stuff from Fowler he'll say the first rule of distributed component design is "don't distribute your component". I struggle with this because of the complexity of managing multiple versions in multiple applications. I personally like the idea of maintaining all of my model code and business process code in one place. I just feel like that'll more than pay for itself when you consider the churn that that type of code will go through (after all isn't that the stuff we want to be very agile with, isn't that the stuff that can provide immediate business value?). The hit to start up IIS and do a DNS lookup and deal with wire level transformation is somewhat moot in my opinion. If you decide to distribute your objects then you're dealing with some form of this (even low level RMI/RPC stuff has to marshal things). It's just how much are you willing to spend to get the benefit of centrally managed code.

The Seven Deadly Sins of SOA : J2EE Technology Blog

The Seven Deadly Sins of SOA : J2EE Technology Blog — Mon, 05 Nov 2007 04:33:11 GMT

Pingback from The Seven Deadly Sins of SOA : J2EE Technology Blog

re: The Seven Deadly Sins of SOA

pkr — Tue, 23 Oct 2007 10:27:05 GMT

Great read, however I have a question about one specific area. In (6) you describe that should always strive to consider what else could use a specific component and not design simply for the here-and-now. I agree with that however it does pose a dilemma. In my experience this can lead to a confusing code-base. When you write code that isn't immediately been used then you run the risks of; the code remain unused and languishes in the code-base becoming the ever uttered, "why do we have this, why do we have to maintain this", designers navel gaze about the possibilities, and you "needlessly" increase your surface area. Having said all that I do appreciate what you are saying but I find it difficult to argue for it.

Link Listing - October 17, 2007

Christopher Steen — Thu, 18 Oct 2007 07:55:55 GMT

Modular schemas, include, and tooling support [Via: Anil John ] The Seven Deadly Sins of SOA [Via:...

Link Listing - October 17, 2007

Christopher Steen — Thu, 18 Oct 2007 07:54:31 GMT

Link Listing - October 17, 2007

re: The Seven Deadly Sins of SOA

anachostic — Tue, 09 Oct 2007 01:31:09 GMT

#3 and #7 strike a chord with me, you'll no doubt recall.

Regarding layering applications: It sounds like you've reversed or at least softened your stance that the business layer must be accessed via web service. Or you've decided that the business layer must be accessed by a WCF protocol. I still hold my beliefs that services - web or otherwise - should be treated like another UI. A UI to be consumed by other applications versus the standard human UI. The service would expose a full or restricted API on the business object it is fronting. Oh wait, you said that. My point is, I think the UI should be able to use the business objects directly.

Seguing into performance: My sticking point with web service calls is not serialization, it's all the other web stuff: request/response, DNS lookup, port connections, the spin-up of an IIS app if it's been idle, blah, blah. That compromise can be made for infrequently-connected clients, but for the primary application, why should it have to suffer? In the name of consistency? The old argument has been updated now that WCF allows binary transports, but that conflicts with #5, right? Maybe not, since I'll bet you can expose a service on multiple protocols.

Merging back with layering: If you treat the business objects as the point of consistency and the human UI loads the objects in-process and the application UI (WCF services) loads the objects in-process, they should both get adequate performance. Further, you have the option to only expose methods that are safe for other applications to use, e.g., the human UI needs a delete method which is present on the business object, but you don't want all other applications seeing/using this method.

In closing, I always find your views informing and interesting. I continue to argue that SOA should not be a golden hammer. It should be an extension of the enlightenment of coding in such a way that business logic is encapsulated. Woah, even I don't understand that. 2nd try: If you're not building reusable business objects, SOA won't help you. If you are building business objects, SOA <i>could</i> help you.

I'll shut up for now. Get Jeff and Robert back in on this.

re: My Love/Hate Relationship with the XMLSerializer

tom.fuller — Sun, 07 Oct 2007 13:31:11 GMT

We decided to update the orchestration to do exactly the same thing the xml deserializer does. It wasn't too hard to just add it to the map as a functoid. If I was starting over, I would eliminate the use of the character type from the web service. Or course that would potentially impact a lot of other consumers (proxy regens, regression testing, etc...).

re: My Love/Hate Relationship with the XMLSerializer

anachostic — Sun, 07 Oct 2007 03:16:18 GMT

Great troubleshooting. I remember those days.

So was it decided to change the service to use string or to change the orchestration to use chr()?

Link Listing - July 17, 2007

Christopher Steen — Fri, 20 Jul 2007 05:47:18 GMT

Link Listing - July 17, 2007