|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 12
Messages: 12
Messages: 12
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Ari Bixhorn on the Unified Programming Model of Indigo
Indigo Product Manager Ari Bixhorn recently did an interview in which he outlined how Indigo will create a unified programming model for distributed computing, bringing together ASMX, WSE, Remoting, and Enterprise Services technologies under a single namespace. He also discusses the support of Indigo on Longhorn and the Compact Framework.If you look across the technology stack for building distributed applications with Microsoft tools today, each technology provides a powerful way of building a distinct type of application. For example, WSE provides you with support for the WS-* protocols for interoperability. .NET Remoting has a great extensibility model, provides location transparency, and so on. But what many developers want is a way to have access to these different elements together within a single application or technology space. They want to combine the interoperability you get with ASMX or WSE with the transaction support you get with Enterprise Services. Today, there is an impedance mismatch across all these existing stacks that makes it difficult to combine all this functionality. To address this mismatch, Indigo will unite the technologies under a single namespace, System.ServiceModel. A developer then uses inheritance to build services applying the proper attributes to configure the Indigo plumbing to make the service accessible across AppDomain boundaries.
Ari also went on to discuss the support for Indigo in Longhorn and the Compact Framework.In terms of operating system support, Indigo will ship as a core subsystem of Windows code-name Longhorn and will also run on Windows XP and Windows Server 2003. We're not planning on providing Indigo support for the Compact Framework for version 1, but we've heard from quite a few customers who would like such support, so we're looking at that carefully for future versions of the technology. To read the entire interview, click here
|
|
|
Message #154241
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
60000 LOC reduced to a few lines of code
Maybe this article will help a little to reduce the level of misconceptions about Indigo, as could be seen in the thread "Ask TheServerSide:Is SOA Really The Future or Just So Much Hype?". Apparently people think that MS advocate Webservices for everything. ;)
Indigo provides a unified programming model that enables developers to build service-oriented applications explicitly—loosely coupled, autonomous services that provide end-to-end security and reliable messaging assurances.
ASMX, Web Services Enhancements (WSE), .NET Enterprise Services, .NET Remoting, all will be We brought together through a single namespace.
Indigo reduces the complexity of creating these apps. People are already providing these kinds of solutions, but they take a lot of work; Microsoft is providing a tool that will help them do this faster, more easily, and with greater productivity.
In other words, precisely want we expect from MS. Meanwhile, the Java world can not compete because they are occupied with (for the umpteen time) yet again a new EJB specification. Trying to make it work.
Regards
Rolf Tollerud
|
|
|
Message #154270
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
funny quote
PM: At the 2004 VSLive! Orlando keynote, Dave Mendlen mentioned that you had a 60,000-line app that had been reduced to a handful of lines by Indigo, but I don't recall hearing about this later. Do you have any more information on that? Do you have a reference to that online?
AB: The app he was referring to is one we built internally. We wanted to build the canonical Hello World Web service, but also add end-to-end security, end-to-end reliable messaging, and distributed transaction support to it. So we built that Hello World Web service using Visual Studio 2003, rolling our own security, reliable messaging, and transaction support. When we built this application as a service with Indigo and Visual Studio 2005, it required only three attributes, or three lines of code. This app demonstrates just how much Indigo does for you, as well as how much Indigo reduces the complexity of writing distributed, interconnected applications.
So now we find out what that statistic was all about. That is hardley a convincing argument that the "indigo model" is easier in practice. It's easy to understand how a simple hello world webservice might take 60K lines handcoded and take 4 lines using code generation. But that is a completely non-sensical argument. It would be like saying, "we decided to fabricate a one-off car and make all the parts ourselves. when we built a car using kits it was much easier and faster than fabricating everything."
the hard part about using messaging centric approach isn't writing security, reliable transaction management or implementing clients, it's figuring out how to take synchronous process and figuring the best way to break it into async stages. Only reason these things are "hot features" for Indigo is because JMS providers have been providing these for a while now. With MSMQ, you do have to write a lot those pieces, but who says I have use .NET with MSMQ. I can use some other .NET compatable messaging system. It will be nice to have Indigo, but I think the product manager is overselling a bit here.
|
|
|
Message #154274
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
funny quote
Not to mention it's still going to be a while before we can build anything using indigo anyways....
|
|
|
Message #154281
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MS takes the leadership in distributed computing
Peter,
I know that even if you will kick, scream and protest in thousands and one ways I still know that you will not be able to resist becoming an expert in Indigo. And be very good at it too. Why not? It is your mama’s street.
Want to take a bet? I could use a little extra cash.
Regards
Rolf Tollerud
|
|
|
Message #154284
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
well duh
I didn't say Indigo isn't useful did I? I said the product manager is "over selling" Indigo. It's his job and right to over sell something he manages. No self respecting developer focused on delivering solutions is going to "not learn" a tool simply because there's hype wrapped around it.
Frankly, I think it's a good thing MS is building Indigo. Biztalk will benefit from it and developers will save some time. In the early stages, the learning curve will negate any advertised "productivity benefits." Once people are used to Indigo and have had sufficient time to switch from MSMQ, it will make life easier. That will take 2 years probably, which is normal. Having gone through the process of implementing our own security on top of ASMX and MSMQ, it took time, but by no means was it brain surgery. Arguing over where we could de-couple components to handle things asynchronously was by far the hardest part and involved some lengthy debates. Anyone familiar with using messaging systems will know what it's like, so I won't bother reciting the same old stories.
|
|
|
Message #154297
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
it was the best of times it was the worst of times
In the past the players in this field have been so few:
According to Bill Roth at Sun the EJB were written for (and by) the systems software architects at the roughly 80 companies in the world that build enterprise-class transactional software.
Like sitting in proverbial Ivory tower. As SOA gets traction, expect that number to be more like 80000 or so soon.
So be prepared for some competition..
Regards
Rolf Tollerud
|
|
|
Message #154304
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
few?
what are you talking about? the players in this area are numerous. before Java and J2EE, CSC, SAIC, IBM, Tibco, EDS and several other service firms were doing SOA. Of course it was all proprietary and there wasn't a standard. Maybe you need to travel a bit and see what the rest of the world is doing. Reading up on history might be beneficial too.
|
|
|
Message #154369
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
funny quote
Please note that I am not trying to start a flame war here. But there are couple of things in this post that I would like to expand upon, if only for the sake of self enlightenment.And just as disclaimer (I have noticed that the absence of this caused problems to people in some other forums), I work for Microsoft.
As to the loc reduction, it was not the presence of code generation that reduced the lines of code. The original Hello World web service was code generated as well, just like an average web service in VS 2003. It was the additional plumbing that was added by hand - things like security, reliable messaging etc. Indigo provides this plumbing as value adds under the covers,via attribution (declarative model) or direct API calls (imperative) and that is what reduces the code size.
Also, while we do say that Indigo is a messaging platform, I think the word "messaging" should be taken in a much looser context, and not in the strict sense of message queuing a la MSMQ and JMS. While Indigo makes it very easy to do MQ style messaging, it also supports several other paradigms including ones similar to today's web service invocation patterns and traditional object RPC. So if you are a COM+ or EJB developer, and like that component oriented style of programming, where you can simply decorate your component with sttributes to express your needs like dist. transactions or reliable deivery support, Indigo supports that seamlessly. On the other hand maybe you view your world as one where you develop pieces of software that communicate passing messages into well known queues or by exchaning XML documents a la web services or by invoking well known distributed objects at well known endpoints a la .NET Remoting or Java RMI - go for it with Indigo, once again all of these are seamlesly supported. I think the real beauty of Indigo lies in the fact that the same underlying plumbing & platform is being utilised to provide with all of these programming models, and the combined richness there in. And at the same time the fact that these value added services like end-to-end message security, reliable messaging and distributed transactions etc. are all expresses ad implementations of established(or in the process of being so) standards like WS-Securty, WS-ReliableMessaging and WS-AtomicTx is the icing on the cake.
Just my 2 cents.
Kind Regards,
- Jit
|
|
|
Message #154374
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
thanks for the clarification
from first hand experience, that's a welcomed improvement. From an distributed object/application perspective, the message queuing is the minimum requirement. Having seen new developers struggle with distributed applications, having a standard way of doing things can't be bad. I look forward to the final release.
on a related note, one of the reasons why IBM wins so many contracts is because they have a whole suite of products build around MQSeries. If it wasn't for MQSeries, I really doubt they would have taken the lead from BEA Weblogic. I know of several shops that chose Websphere because of MQSeries and the goodies that come with it. JBoss and Weblogic are both better at supporting the latest specs, but they loose to IBM because of the IDE integration/code generation features.
|
|
|
Message #154384
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Can you say the 'C' word? Commoditization?
Peter,
"I know of several shops that chose Websphere because of MQSeries and the goodies that come with it"
The IBM way of doing it:You can build a service-oriented architecture out of MQSeries. You can build them by hand. The challenge has been that the only people who can really construct them were people who wanted to go spend a couple 10 million dollars on software. You'd buy MQSeries, you'd buy TIBCO, you'd buy a transaction monitor, you'd buy a security manager, an identity management system, an audit system, you'd wire it all together with about 50 consultants with PhDs and at the end of the day you have a nice, one-off, service-oriented architecture. Microsoft Indigo Architect John Shewchuk
http://www.internetnews.com/dev-news/article.php/3357621
The Microsoft way:For me, Indigo is only a program-to-program communications layer. When an Indigo program talks to another Indigo program, what flows on the wire will be proprietary, but when Indigo is talking to something else, it will rely on Web services standards for the communication.
What could be easier? I promise you when Indigo comes out I learn it all over the week-end.
Regards
Rolf Tollerud
|
|
|
Message #154385
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
canabis and too much smoke
Peter,"I know of several shops that chose Websphere because of MQSeries and the goodies that come with it"The IBM way of doing it:You can build a service-oriented architecture out of MQSeries. You can build them by hand. The challenge has been that the only people who can really construct them were people who wanted to go spend a couple 10 million dollars on software. You'd buy MQSeries, you'd buy TIBCO, you'd buy a transaction monitor, you'd buy a security manager, an identity management system, an audit system, you'd wire it all together with about 50 consultants with PhDs and at the end of the day you have a nice, one-off, service-oriented architecture. Microsoft Indigo Architect John Shewchuk http://www.internetnews.com/dev-news/article.php/3357621The Microsoft way:For me, Indigo is only a program-to-program communications layer. When an Indigo program talks to another Indigo program, what flows on the wire will be proprietary, but when Indigo is talking to something else, it will rely on Web services standards for the communication. What could be easier? I promise you when Indigo comes out I learn it all over the week-end.RegardsRolf Tollerud
when i see that happen consistently, across several diverse domains I'll believe it. Just like anything else, most problems are the result of bad management by developers or managers or both. considering how easy is it for managers to constantly change the functional requirements and make 180 degree turns, it very easy for a project to loose sight and get totally loss. At that point, it makes absolutely no difference which platform you use.
keep on believing what you want, but the platform is a tool. Who gives cares about the platform if your specs are so screwed up that it's not implementable. Learning how to extract the important bits and bring focus to a project is what matters at the end of the day. That and having the authority to make decisions when things go off course. Of course depending on the chosen platform, one still has to write the custom bits to glue things together, but that can be managed with focus.
|
|
|
Message #154395
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM Guild
One can wonder why haven't IBM made (or at least tried to make) something similar to Indigo? After all they also have nearly unlimited resources and talented people. (though I have to admit that I never met one ;)
The answer is that they never will give up the "One billion dollar=Small IBM contract market". Their policy is somewhat similar to the guild system during the middle ages in Europe: During the middle ages in Europe, working men of particular trades usually joined associations called craft guilds. These Guilds served to regulate occupations and preserve a monopoly of crafts
Membership was difficult, or impossible, to obtain. Membership was passed on to sons or sons-in-law of members, or could be purchased at extreme cost. Guild Rules and Regulations were strict. They decreed that nonmembers could not practice the trade within their territory. At the beginning of the Industrial age these Guild's insistence on obsolete standards and processes became a severe handicap to modernization.
Just as IBM now.
Regards
Rolf Tollerud
|
|
|
| |
|
| New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET |
|
|
Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.
SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.
VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.
Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]
One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts.
(June 24, Article)
Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage.
(June 24, Article)
Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server .
(June 18, Cartoon)
Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps.
(June 29, Podcast)
Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience.
(June 25, Tech Talk)
In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier.
(May 24, Article)
Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year.
(May 10, Article)
Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information.
(April 24, Article)
TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks.
(April 11, Article)
In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services.
(March 29, Article)
Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition.
(March 22, Chapter Excerpt)
|
|
