DISQUS

Ryan, that would be great. It does look interesting, but so does everything else :) Time is such an annoying limitation, I don't know why the universe bothers us with it.

Yeah, our architecture turned out to be roughly DDD as well - I think you naturally get there after a building a few systems - the nice thing about the standardized practices is that a lot of the rough edges you end up with when you grow your own architectures have been all filed down, and like you said you gain a common vocabulary with which to communicate with the community.

Harry, not a tweeter. I opened an account once, but the only thing it really did for my was disrupt my ability to concentrate even more than my RSS reader and e-mail already manage to do :) So are you guys working on some MVC stuff over there at DX?

Jesse, those are good points. I think ASP.NET MVC and MVC in general is about more than just control, although that plays a big role. Testability, built in support for IoC containers, a formalized separation of concerns, the tremendous weight loss achieved by dumping View State are also important considerations. I would almost say that if you want to realize an architecture for your app that DOES cleanly and intelligently keep business logic or data access out of your business layers you're developers need *more* experience and discipline if they are using ASP.NET WebForms than if they are using MVC, because in WebForms it is extremely easy for business logic and data access concerns to start creeping into bed with the view logic if you aren't very careful. I also tend to believe that the abstraction of Web Forms won't keep you safe from HTML - unless you're building some intranet app that is little more than scaffolding over a database - I've spent as much time tweaking HTML tags using classic ASP.NET as writing server side code, and even more time than that worrying about the ID's that were generate :) ). Not to say ASP.NET WebForms don't have their merits or that the abstraction isn't useful in many cases, just that there may be more to consider than just if (ControlFreak) MVC else (ClassicAspNet).

Thanks David, I'll tell him you said hi.

Ryan, I haven't really even looked at N2, but I will now. We do not need to give schema editing capabilities to end users, that model sounds interesting. Have you contributed to the Umbraco source? I believe I've seen your name around Codeplex in connection with Umbraco before. (It stands out because an old friend of mine is named Ryan Roberts. I presume you are not he :)

@ Mayur - I didn't know Cuyahoga had a 2.0 beta - very exciting. Please do let me know how your social networking modules come along, especially if you decide to open source them :)

@David L. - thanks for the valuable feedback. As I said in my post, if we were a consulting firm creating solutions for clients, I probably would have sighed on the dotted line with Ektron. Our licensing requirements are a bit trickier though. Not so say they don't have a model that can work for us, it is just more complicated.

@Fredrik - thanks for the offer, but if I am unable to contact anyone in the company directly (and I tried pretty hard), then it isn't for us. I shudder to think about what support will be like if I can't even get a salesperson to talk to me!

@Vijay - great resource, thank you!

Yes, I know - the VB thing is really a pretty petty bias on my part, but I like to study the code of the open source tools I use, and I just really don't like to read VB.NET. That isn't the main reason we passed over DNN though, I've looked at it pretty closely several times over the years and ultimately decided against it (although is has been more than a year now so maybe it deserves another look).

Once the project has stabilized then I think that is a great idea.

I'm glad you like it, thanks for the compliment. It's still very much a work in progress, so please don't be shy with any feedback, suggestions, requests etc. as you pick through it.

Probably not a problem limited to SOA - I imagine OOP went through similar pains. I feel for all those misunderstood acronyms, especially once they fall into the hands of the marketers and have their meaning and lifeforce sucked right out of them. Eventually the marketers tire of them, and then, slowly, they become real again.

It was in the spam filter. Wonder why?

Rob, I responded with a new post. Thanks for the debate, It's been englightening.

Rob, I'm not in much of a position to disagree with you practically, because as I've mentioned I have very little experience in this arena. Still, I would have a hard time saying that SOA isn't necessarily about technology - can you have a service that is purely human based, with no integration point with technology? I didn't so much mean it is technology like web services are a certain kind of technology, but at the end of the day your architecture will be manifested in technology if it is manifested at all. You can't apply SOA to bridges or football arenas, SOA is a technology architecture.

In my mind, the city metaphor is not just "architecture in general", or "enterprise architecture in general" whereas SO is a particular of flavor architecture in general. The important part of the city metaphor for me is the autonomous nature of each level in the systems hierarchy and that each logical entity transacts with those around it through a globally standardized infrastructure and set of mandated conventions that permeate the whole system, and yet a particular unit of logic, be it a web service or a LOB application, is as N-tier as it cares to be on its own time. Traditional architecture or generalized EA doesn't mandate service autonomy or a common, enterprise wide infrastructure (or protocol), or centralized governance or loose coupling, but the city metaphor does imply those things, and from what i can tell those things are a pretty important part of most accounts of SOA I have seen.

I can't even picture what SOA could possibly be about if it isn't about how units of business functionality as automated by software are expected to interact with one another. Loose coupling, share contract not class, all that jazz is all about defining the relationships between such units of business functionality, and it standardizes that realtionship to maximize certain qualities such as reuse or loose coupling, and a standardized method of interactions to me feels a lot like how autonomous humans are similarly enabled to transact with one another in very complicated ways via a common set of laws, conventions and standardized infrastructure that is our society.

And I haven't really heard of SOA being applied to application architecture, except in the context of composite applications, so I can't speak to that, but I have a hard time picturing it. In any case I don't see SOA as just a style, if scope isn't involved then I'm totally missing the point. If it were just a style you can apply here and not there, then you could have one application handily crafted in the SOA style and one in the N-Tier style next door, but the connection between them isn't addressed. You could say to a visitor "Here we have our ERP system, it was built using the post-WS-* SOA style. And here we have our CRM, it was constructed in the JBOWS style. I don't recommend using that system at night, it isn't in the best neighborhood" But then I don't think you would have an SOA, as I have come to understand it. As I have come to understand it, the term SOA applies to all participants in a given system if they are N-tier or anything else.

@Sam, intent is much clearer. Thanks for the great series, BTW, very good info.

@Loraine, thanks for the links, I'll definitely check out those resources.

@Pat, I agree, those tenets are important in defining, or at least implementing SOA. I would say they are probably a subset, though, the final list being different, possibly vastly so, from one school of thought to the next.

I don't actually feel marketed to - I feel educated by your posts and read them carefully, but the culmination ends up here, and it almost sounds like candy bar commercial

Introduction to Neuron as WCF/SOA Enabler and "BizTalk and Neuron: Better Together"

Neuron ESB and Publish-Subscribe, Mediation, Routing, etc.

And I'm not dogmatic about N"open-source" by any stretch - I think Neuron is a top notch product, and from my very limited experience it has by far more fit and finish than any other ESB offering in the .NET space, at least from what I've been able to dig up.

So I wasn't trying to be disparaging or negative, but your series of posts appears to be organized like a typical white paper where part 1 is the general educational material and part 2 is how the problem is solved by a product. I've learned extensively from white papers and never felt like the case study at the end detracted from the educational material within, yet promotion or evangelism of the product is still a goal. Perhaps my assumption may have been off base, but that's how it goes sometimes. I apologize if I offended, my tone was intended to be matter of fact without any implication of a sneer.

Ken, Oren's book was my technical resource for the DSL, but Martin Fowler is also writing a book on DSL's (the link is in the project description) and he has a chapter where he describes a State Machine DSL which was the basis for the actual State Machine language structure. So Martin Fowler did in fact inspire the DSL, and Oren's book enabled me to create it easily in Boo.

Thanks Alex. Let's use something like Hsi.Code.Extensions, so that we can reserver Hsi.Extensions for when we build end user extensibility points into our products :)