This post originated from an RSS feed registered with .NET Buzz
by Sam Gentile.
Original Post: SOA, Shadowfax, Indigo and concerns
Feed Title: Sam Gentile's Blog
Feed URL: http://samgentile.com/blog/Rss.aspx
Feed Description: .NET and Software Development from an experienced perspective - .NET/CLR, Rotor, Interop, MC+/C++, COM+, ES, Mac OS X, Extreme Programming and More!
I am trying to get my head around SOA especially now that I am in the midst of designing a grand managed (.NET) distributed architecture for one of my clientsand my team that will take the next 18-24 months to do and deploy (yes, its that big). Previous writings have described issues that have come up with both ES and Remoting in terms of security and there is always the wanting to create an architecture that is “ready” for Indigo. I must confess SOA to be one of those paradigm shifts - it really does mean the death of objects. I find it ironic that just when .NET makes Object Oriented mainstream for the masses and in particular VB programmers, we are on the heels of another paradigm shift that has swept some of that away already. Of couse, for most of us C++/Java programmers we have all been doing OOD/COM/Corba/RMI and objects for nearly 20 years now and see the glaring issues that are leading people like Don and many others to SOA.And to the end, Indigo is not really about Web Services per se, its about SOA. What's the big honking paradigm shift in SOA I am talking about? Its from an object-oriented to a message-oriented system.In a sense, we have been heading this way for years right? If you look at MTS and its big culture shock of traditional OO objects being not that great anymore in favor of stateless components and then COM+ to XML Web Services, we have been on a steady progression from OO to loosely-coupled service-oriented architectures anyhow. Its still a big paradigm shift for usArchitects anyway.
Before I talk about Shadowfax bringing SOA functionality to .NET today, let me talk and ask about a nagging concern that I would ask Don or Yasser about next time I saw them. When Don and Yasser say “ When building Service Oriented applications, you should use ASMX to expose your services. It is totally fine (and recommended) to use Enterprise Services and/or System.Messaging as appropriate within a service's implementation”, I grok that but my nagging concern, and I may just not understand so help me out here, is that ASMX endpoints imply XML Web Services right? That may fine for certain classes of apps but not all, especially today. The real question I have is about performance. Whereas COM, COM+ and .NET components essentially deal with a v-table pointer type access directly to the object they can be in memory binary fast. I know thats not the case for DCOM and such but my concern is sending heavyweight XML SOAP messages around to ASMX endpoints can be prohibitly expensice in terms of memory, size of messages, network traffic, and raw performance for many applications today. I am refering to the quote to use ASMX endpoints today for all your apps. I am not sure I am getting my concerns across correctly but maybe its enoough for people to riff on and pull me out of the dark.
Anyhow, late to the party, I came across Shadowfax which lets you start to do things with SOA in .NET today, not Indigo timeframe, but be even more ready for Indigo. There is a M0.1 Pre-Alpha release, Intoductions and Quick Starts. This looks like great stuff and I will be diving into this to help with my architecture. Thoughts?
Previous Topic
