|
|
Browse by Tags
All Tags » Indigo AKA WCF (RSS)
Sorry, but there are no more tags available to filter with.
-
Kirill just sent me code for how to call the Amazon Simple Queue Service from WCF: 1. run svcutil on the SQS WSDL: http://queue.amazonaws.com/doc/2006-04-01/QueueService.wsdl 2. consume the proxy using code like the following: MessageQueueClient queueMessageClient = new MessageQueueClient ( "MessageQueueHttps" , queueAddressUri); queueMessageClient.ClientCredentials.ClientCertificate.Certificate = clientCertificate; SendMessage sm = new SendMessage (); sm.MessageBody = "<Body>This is message 1</Body>" ; queueMessageClient.SendMessage(sm); Message message = queueMessageClient.ReceiveMessage( new ReceiveMessage ()).Message[0]; Console .WriteLine( "Message Received: " + message.MessageBody); Very cool, IMHO. What's interesting here is that not only does the Amazon SQS service use WS-Security for encapsulating certs in a SOAP message (and using transport security for encryption), it also uses the WS-SecurityPolicy assertions in the WSDL, so that SecurityPolicy-aware processors like WCF can generate the right configuration for the client proxy to enable interop very easily. The metadata story has always been critical to helping simplify the process of "practical" interoperability. It's great to see Amazon adopting the tools that make this possible. Read More...
|
-
Coming soon to an MSDN download page near you... Aside from a handful of bug fixes that we deferred to the RTM milestone, you're basically getting the final product. Time to Go Live! :) Read More...
|
-
I usually don't quote other bloggers, but after reading Dare 's recent entry , I couldn't resist... Reach is the Most Important Thing when Building Services on the Web Dave Winer has a blog post where he responds to a post entitled SOAP, REST and XML-RPC by Randy Charles Morin. He writes I wonder if it's be possible for me to disagree with Randy Morin without getting flamed. I never said XML-RPC is better than SOAP or REST, or more perfect or pure, or better documented. I don't care if the others have better websites, or more advocates posting on mail lists. The reason I advise would-be platform developers to support XML-RPC is because at least for some developers (including me) it's so much faster to implement, so we spend less time creating glue and get to building applications sooner. I've learned that the sooner developers get to the fun part, the more likely they are to deploy. And if that's the goal, why not support it? BTW, I never said they shouldn't support SOAP or REST, in fact I often provide multiple interfaces to my would-be platforms, because I've learned that if you want uptake for new ideas, you shouldn't argue over small things like this, you should say yes whenever you can. I agree 100% with Dave Winer. If you are building a service on the Web, then you shouldn't discriminate against any platform, application or device. This means you can't pick one approach or one technology for building your service because different platforms have different levels of support for various approaches. A developer using Visual Studio will find using SOAP easier then REST or XML-RPC while on the flip side a developer using Python or Perl is likely more at home dealing with XML-RPC than using SOAP. Choosing one technology over the other is choosing to discriminate against one platform or set of developers over the other. In some cases this is necessary to keep maintenance costs down by supporting a small set of protocols but in general if you are building a service on the Web, you want it to be inclusive not exclusive. Arguments of technological superiority be damned. Ahh... it's so refreshing to see a pragmatic viewpoint on the whole protocol dogma permathread. Yes, if the most convenient way to invoke a service in your language is by concatenating XML fragments and sending as an HTTP request, SOAP doesn't get you anything, and you're going to be cranky if I make you wrap your body in a SOAP envelope. On the other hand, if you have a typed language (java, VB, Read More...
|
-
I usually don't quote other bloggers, but after reading Dare 's recent entry , I couldn't resist... Reach is the Most Important Thing when Building Services on the Web Dave Winer has a blog post where he responds to a post entitled SOAP, REST and XML-RPC by Randy Charles Morin. He writes I wonder if it's be possible for me to disagree with Randy Morin without getting flamed. I never said XML-RPC is better than SOAP or REST, or more perfect or pure, or better documented. I don't care if the others have better websites, or more advocates posting on mail lists. The reason I advise would-be platform developers to support XML-RPC is because at least for some developers (including me) it's so much faster to implement, so we spend less time creating glue and get to building applications sooner. I've learned that the sooner developers get to the fun part, the more likely they are to deploy. And if that's the goal, why not support it? BTW, I never said they shouldn't support SOAP or REST, in fact I often provide multiple interfaces to my would-be platforms, because I've learned that if you want uptake for new ideas, you shouldn't argue over small things like this, you should say yes whenever you can. I agree 100% with Dave Winer. If you are building a service on the Web, then you shouldn't discriminate against any platform, application or device. This means you can't pick one approach or one technology for building your service because different platforms have different levels of support for various approaches. A developer using Visual Studio will find using SOAP easier then REST or XML-RPC while on the flip side a developer using Python or Perl is likely more at home dealing with XML-RPC than using SOAP. Choosing one technology over the other is choosing to discriminate against one platform or set of developers over the other. In some cases this is necessary to keep maintenance costs down by supporting a small set of protocols but in general if you are building a service on the Web, you want it to be inclusive not exclusive. Arguments of technological superiority be damned. Ahh... it's so refreshing to see a pragmatic viewpoint on the whole protocol dogma permathread. Yes, if the most convenient way to invoke a service in your language is by concatenating XML fragments and sending as an HTTP request, SOAP doesn't get you anything, and you're going to be cranky if I make you wrap your body in a SOAP envelope. On the other hand, if you have a typed language (java, VB, Read More...
|
-
Guy Burstein wrote : When will RC1 be shipped? As far as I understood, the majority of changes in this build are on the WF part. So, should we really upgrade to June CTP? RC1 will be shipped late August with Vista RC1. Actually, the WF bits aren’t super different than the stuff we shipped with Vista Beta2 (in May). The WCF bits have a fair number of changes. Most of them are a bit “under the surface” – e.g. we put it a fair amount of work to be able to build a “packet router” on top of Indigo – a scenario that was very hard to do with beta2. We also put in deeper support for POX. And the Infocard (now "CardSpace") UI has changed quite a bit. I think you should check it out :-) Read More...
|
-
Check it out here . This build is based on our "RC1" tree. It's not a final WCF RC1 build but it incorporates all the final programming model tweaks that we made from the Beta2 build we shipped in May. The quality of the WCF bits is high, but not quite at the same level as the final Beta2 release (e.g. the stress results for the Beta2 build were better), but it's reasonably good - it's from the middle of "ask mode" - which is when we stop fixing a whole bunch of bugs and start raising the bug bar, so that we can reduce the churn and increase the stability. The final RC1 build will have a couple hundred additional fixes, so it will definitely be better ("go-live" quality), but we absolutely encourage folks to download this June CTP for new projects or for porting from Beta2. Read More...
|
-
With the WinFX --> NetFX 3.0 name change, we also took the opportunity to consolidate all the old WinFX community sites (windowscommunication.net, windowsworkflow.net) into a new global domain - netfx3.com . We also added sites for CardSpace and WPF. The existing samples from the old sites didn't get automatically carried over to the new site, because some of them were stale (especially my Indster demo :-)). So if you're like me and didn't update your sample to the beta2 bits, you'll need to do that before reposting it. The site has a pretty snazzy new look and feel, and Clemens is personally doing the care and feeding, so we're hoping to make this site as popular as www.asp.net is for ASP.NET developers... and the only way we can do it is with your help! :-) Read More...
|
-
In the best tradition of last minute marketing name changes, we just announced the following: WinFX --> .NET Framework (NetFX) 3.0 Infocard --> CardSpace While the feature is called CardSpace, the actual digital identity artifacts are still known as "information cards". None of the software in NetFX 3.0 is different - we are still shipping WCF, WF, WPF, and CardSpace both in Vista and as a downlevel redist. It's nice that we're going to continue to maintain the .NET Framework brand - it's probably the strongest / most recognizable developer brand we have. Too bad we didn't think of that two years ago :) Read More...
|
-
My, how fast the word travels . Last week, we rolled out a CTP of two new "infrastructure" services hosted in the Live cloud - a Relay and a Security Token Service. Anyone who's ever built a P2P app is familiar with the firewall / NAT traversal problem - both peers are often non-addressible from the outside, and so you have to use some sort of relay as a solution. The various Instant Messenger clients, Groove, Napster, etc are all well-known examples of applications that had to roll out relaying capabilities on their own. The idea behind the Live Labs Relay service is to have a relay in the cloud that developers can use for ubiquitous connectivity instead of having to roll their own. While the protocols for using the Relay are public (anyone from any platform can use it), we've integrated the Relay with the WCF programming model in the form of a "meta" channel / binding, that developers can use to abstract all the connectivity goo from their applications. Check it out here . Also check out DavidWor's relay blog (congrats David! :-)) The Security Token Service we rolled out is the perfect complement to the Infocard identity system we are shipping with WCF and Vista. The federated security model that Infocard is based on the idea that a service (or website) requires a set of claims to authorize a request. A user logged into a Windows domain, for example, has a set of claims that the Kerberos domain controller can vouch for on her behalf. But of course if you're trying to authorize a user across security domains, you really need a more neutral way of specifying claims. An STS is essentially a "claims converter" - you give it one set of claims and it gives you back a set of claims that you understand, and can use to authorize the user. One cool thing about the STS we just rolled out is that it effectively does that mapping between the claims in an Infocard (that you create) and a Windows Live ID. A service or site that wants to support Infocard as a way for the user to specify their identity would normally need to roll out an STS on their own. With the Live Labs STS service, you just need to register your site or service with our cloud STS, and when someone tries to use the service with their Infocard, our STS will do the claims conversion and authorize the user. Check it out here , and the blog as well. Congrats Hervey ! Read More...
|
-
...alongside Vista Beta2. Get it here . Unlike the Jan CTP, which was only go-live for Indigo and WF, this release is a go-live release for all three technologies (WCF, WPF, and WF). More info here . One more major milestone (RC1) shipping later this summer, and then we're done! Read More...
|
-
Today we submitted WS-Policy to the W3C. Yeah, with the recent flurry of WS-* spec submissions, this may seem to be rather boring news, but nevertheless it's nice to reach this milestone - the security, reliable messaging, and transaction specs all contain policy assertions and it's great to have the policy framework for processing those assertions locked down. This submission is also broadly supported - in addition to the 6 authoring companies, there are 13 others who co-submitted this spec with us. Congratulations to Jeff, Asir, Alex, Dan, and the rest of the Indigo metadata crew! Read More...
|
-
These bits are what we internally call "RC0" and include most of the OM changes that we planned on making post Jan CTP (the Go-Live release). The bits are not as baked quality-wise as the Go-Live release (they were cut right after about a month of DCR's were coded into the product) but they look alot closer to the final product. Pointers below... WinFX Runtime Components: > http://www.microsoft.com/downloads/details.aspx?FamilyId=F51C4D96-9AEA-474F-86D3-172BFA3B828B&displaylang=en > > Windows SDK: > http://www.microsoft.com/downloads/details.aspx?FamilyId=9BE1FC7F-0542-47F1-88DD-61E3EF88C402&displaylang=en > > Microsoft Visual Studio Code Name "Orcas" Community Technology Preview - Development Tools for WinFX® (aka Fidalgo): http://www.microsoft.com/downloads/details.aspx?FamilyId=AD0CE56E-D7B6-44BC-910D-E91F3E370477&displaylang=en > > VS Extensions for WorkFlow: http://www.microsoft.com/downloads/details.aspx?FamilyId=A2151993-991D-4F58-A707-5883FF4C1DC2&displaylang=en > > WinFX RC February CTP "Readme": http://msdn.microsoft.com/windowsvista/support/relnotes/winfxfebctp/default.aspx > > > Ed Pinto was kind enough to post a b reaking change list from the Jan CTP ("beta2" to the Feb CTP "RC0"). (BTW, Just to confuse y'all, we will release what we call "RC0" as part of the Vista Beta2 release in a couple of months). > Read More...
|
-
Today is a special day for us - by now this is old news, but here's my rejoinder: today we posted the Go-Live releases of WCF and WF. We have a click-through license (reminescent of VS.NET 2005 beta2) that allows folks to put apps that use the January WCF and WF build into production. Some information about the genealogy of the bits: late last year we spent about a month baking the quality and stress of what we called the "beta2 branch" of WCF. That set of bits was snapped late last year and got rolled up into the January WinFX CTP (which contains the WF Go-Live bits and a high-qualilty WPF release as well). Stated otherwise, the WCF bits in the WinFX Jan CTP and in the Go-Live release are identical - except for the supplemental Go-Live license. We did it this way so that developers who use multiple parts of WinFX (e.g. Avalon and Indigo together) can build apps using the WinFX CTP, and if the service part of the app is ready for deployment, companies can install the WCF Go-Live bits on their production servers. (Of course, a WCF "client-side" app is also licensed for production use). If you haven't yet started writing your connected app with WCF, there's no better time than now! Read More...
|
-
Our new WCF community site is live! Check it out here . We are especially excited about the "samples gallery" - the idea is to create a repository of sample code, channels, behaviors, and other goodies, to help Indigo developers get bootstrapped and add capabilities to their arsenal. My Indster app is posted up there (to set the low water mark for contributions :-)), but all the other samples are much more interesting and higher quality... check out the chunking channel, the WSE2 soap.tcp channel, and the POX encoder for some examples of cool goodies! Read More...
|
-
The most excellent Ed Pinto justed posted the definitive list of breaking changes on his blog . Hopefully this will help folks who have been trying to port code to our newest CTP. Ed also provided a document that contains the exhaustive list of breaking changes - actually 3 docs that are zipped together - Beta1 to PDC, PDC to Nov CTP, and Beta1 to Nov CTP. Enjoy! WCF Beta1 to Nov CTP Breaking Changes Detail.zip (568.11 KB) Going forward, we're hoping to have breaking change lists come out roughly at the same time as CTP's are posted. The upcoming WinFX Dec CTP doesn't have anything new as far as Indigo bits, but the Feb CTP is slated to have most of the final changes we're making to the product before we lock it down for good... Read More...
|
|
|
|