|
|
Browse by Tags
All Tags » Indigo AKA WCF;Web Services/XML (RSS)
Sorry, but there are no more tags available to filter with.
-
The MySpace developer API's launched today . Their API's are all RESTful, and they built them using WCF's REST features that we just shipped in .NET 3.5. MySpace will be talking about their experience at MIX08 , so if you're going, you should check out the talk.. Read More...
|
-
I promised a blog entry on the role metadata plays in the interop issues our customers are running into... The role of metadata in a distributed system is fairly controversial and the subject of some debate. While SOAP isn't coupled to either the RPC or the message passing style of payload semantics, the way WSDL and XSD are used in platforms like J2EE and .NET tends to push you towards RPC. In a typed language, the conventional wisdom is that generating a proxy for me based on some kind of description of the service will make it easier for me to call that service using my familiar language semantics. While the programming model is attractive, the underlying difference in type systems between platforms/languages are responsible for most of the interop issues we see in practice. James Clark wrote a nice blog entry that makes similar observations. When you're programming in a dynamic language (and may of the languages of the Web, like Javascript, PHP, Python, Ruby, all fit into that category), the idea of creating proxies for a remote service using a static processor isn't exactly useful :-) Those languages all have good text processing facilities and creating a parameterized message from an example / instance is very straightforward. This is where the .NET and Java platform's reliance on extruding metadata that will be processed by a proxy generator (and will supposedly hide all the complexity) becomes an issue - one might argue that an over-reliance on this mindset has, in practice, made it harder for dynamic languages to consume those kinds of services. We need to do better here - for example, in ASP.NET AJAX, we produce dynamic javascript proxies that can be called from your javascript code. That's much more useful, especially since in the AJAX scenario, the client-side code (javascript) and the service are inherently tightly coupled since the javascript is all generated by the server. More generally, having the service publish an instance document as part of its "help page" would go a long way towards making it easier for platforms that don't rely on static proxy generation to be able to call WCF services more easily. Also, there are benefits even for typed languages - being message-centric reduces coupling between the client and the server, and for the .NET platform we have XLinq and the VB9 XML features, which give you a decent programming model over XML messages. While this isn't currently in the Orcas plans, it's high on our list for future enhancements.. Read More...
|
-
With WCF now supporting "REST"-style services, some bloggers have pronounced the death of SOAP and WS-*. Wouldn't it be nice if we actually had that level of influence :-) truth is we see alot of requests for both SOAP and REST - that's why we support both in Orcas. Stepping back, there's an old saying at Microsoft - "applications drive platforms". It was true with Office and Windows, and it's true today in the distributed systems space. There are many "platforms" for software integration in today's world: Queuing systems like MSMQ, MQSeries, JMS "ESB"s like Tibco or BizTalk Server Adapter-oriented EAI suites like you find in BizTalk, SeeBeyond, WebMethods Web services (SOAP, WS-*) The Web itself (often known as "REST") Each of these exist for a reason - there are applications for which they are well-suited. With WCF, we realized early on that there won't be one true protocol or integration technology. We designed WCF by looking at all the integration technologies we had at the time - .NET Remoting, MSMQ, COM+/Enterprise Services, BizTalk, ASMX/WSE - and creating an architecture where we could have a single programming model that enabled you to achieve all of those scenarios. That's not to say that we replaced all the underlying technologies - in many cases we just made sure that we could "plumb" existing technologies under that single programming model. So we have an MSMQ binding, a SOAP/WS-* binding, all of the BTS adapters are now being written as WCF channels, and in Orcas we're adding the "Web" binding. We believe that's a pretty unique proposition in the platform world - and the key value is that no matter what the scenario, we have a single set of API's in the .NET Framework that will let you achieve it. Moreover, adopting WCF gives you a nice measure of future-proofing - any new integration technologies that emerge can be supported as a WCF binding. That, in essence, is the core value proposition of WCF. In my entry about our Orcas "Web" features, I've already (indirectly) discussed some of the apps that will drive WCF adoption on the Web: ASP.NET AJAX pages and Silverlight apps are backed by WCF services support for JSON, RSS, and ATOM looks to be attractive to folks who are using Web protocols and formats for building services on the Web the new programming model constructs that support Web semantics ([WebGet] / [WebInvoke] and UriTemplates) make WCF a good choice for building REST services on the .NET platform It's also worth articulating the types Read More...
|
-
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...
|
-
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...
|
|
|
|