Inne ciekawe linki:
- Oficjalne zapowiedzi VS 2010 oraz .Net Framewok 4.0 - najwyższy poziom tego pakietu to Team Suite. Ogromna zmiana - MS lansował model tworzenia aplikacji w oparciu w DSL (fizyczny poziom projektowania), teraz będzie wspierał UML (logiczny poziom projektowania) co się ma odbić w nowej wersji narzędzi "OSLO". O swej determinacji do przejścia na UML świadczy fakt wstąpienia MS do Object Management Group (OMG) - http://adtmag.com/news/article.aspx?editorialsid=10246
- Ciekawy protokoł GSS istnieje jego implementacja w Java - http://www.ietf.org/rfc/rfc2853.txt - ma dwie implemetacje:
- The Simple Public-Key GSS-API Mechanism [SPKM]
- The Kerberos Version 5 GSS-API Mechanism [KERBV5]
It was surprising enough when four years ago, Microsoft made an historic decision to ditch its own Web services architecture attempts and go with the flow. Today, it announced its next version of Windows will go with a different flow.
For the last four years, one of the most prominent signs of Microsoft's change of thinking with regard to the division of labor in programming, has been its embrace of Simple Object Access Protocol (now just called SOAP, after too much deliberation over the acronym) in Windows Communication Foundation (WCF). It was Web standards organizations, not Microsoft, that initially drove the widespread adoption of so-called WS-* services that use SOAP, but Windows' embrace of SOAP later cemented the standard as a fixture of Web development.
Initially, WS-* support was to be the hallmark of Microsoft's next-generation operating system back when it was still code-named "Longhorn," but later it was retrofitted to later editions of Windows XP, as well as to the .NET Framework.
But now that the tide of developer sentiment has recently shifted toward a new Web services model, that trades SOAP's platform independence for a more simplistic transaction structure called Representational State Transfer (REST), Microsoft is saying that it will be building what it's calling a "unified XAML model" into the next editions of both WCF and .NET. Those components will premiere in Windows 7, and beta testing will begin later this month.
As .NET Framework product manager Steven Martin described on his blog this afternoon, "As developers are broadly adopting the use of web services to build applications (using a spectrum of both advanced WS-* services as well as lighter weight RESTful services), they are reusing services that can live disparately across their enterprises, or on the Web. The best part of composite applications is that they can improve productivity and efficiency on the dev side and give more power to end users for accessing and managing data that's most critical to the business. As a result of the growing popularity of composite apps, developers require new levels of sophistication for building distributed, long-running, and workflow-centric applications."
That's the crux of Microsoft's marketing message explaining the move toward the REST model. But a white paper also released by Microsoft today takes that language somewhat deeper, going so far as to call into question the viability of the very aspects the company had cited as recently as months earlier as its reasons for embracing SOAP in the first place.
"Composite apps present new challenges around scalability, performance and reliability," reads Microsoft's latest "Overview" white paper on its new "RESTful" technology, code-named "Dublin" (DOCX available here). "The tried and true strategies for optimizing traditional applications do not satisfy in the more complex environment of composite applications. To address these requirements, composite applications must adopt more sophisticated application architectures -- including managing of highly asynchronous transactions, automation of long-running durable workflows, coordination of processes across very heterogeneous environments and seamless interoperability across platforms using standards. Increasingly, customers are turning to workflow-centric and 'declarative' approaches of defining application logic to help manage this complexity."
On the day that Microsoft first announced its WS-* technology adoption publicly, its product managers cited as its reasons for doing so what they called the "four pillars:" scalability, performance, availability, and reliability. (Marketers since that time have merged the final two items into one.) This February 2007 study by WCF program manager Saurabh Gupta graphically demonstrated the superior performance, scalability, and availability of WS-* Web services over the technologies that Microsoft had previously employed prior to embracing WS-* and SOAP, including ASP.NET Web Services (ASMX) and the Web Services Enhancements (WSE) add-on to Visual Studio 2005.
"To summarize the results, WCF is 25%-50% faster than ASP.NET Web Services, and approximately 25% faster than .NET Remoting," reads Gupta's conclusions. "Comparison with .NET Enterprise Service is load dependant, as in one case WCF is nearly 100% faster but in another scenario it is nearly 25% slower. For WSE 2.0/3.0 implementations, migrating them to WCF will obviously provide the most significant performance gains of almost 4x." Earlier in the study, Gupta warned that the chief limiting factor in any SOA system is the implementation of that service, rather than the underlying technology.
Whether a REST implementation will be significantly more scalable or perform better than a similar SOAP implementation may yet be proven by similar tests. Perhaps we'll see some of those tests during Microsoft's PDC in Los Angeles at the end of the month.
What's the difference between REST and SOAP, really? The two implementations of Web services architecture are actually completely different; they may accomplish much the same results, but they go about their jobs in entirely separate ways.
With SOAP, each Web service has its own URL, and a request made of that URL is submitted as a message in an XML enclosure. Each request uses an instruction that's part of the namespace of the service, which is itself explained through an XML scheme called Web Services Description Language (WSDL). So a Web client passes a message to the service, using the lexicon outlined by WSDL and enclosed in a SOAP envelope. The service then responds with results that are enclosed in a very symmetrical fashion, so that the queried element and the response tend to match up.
The key benefits of SOAP are that it is transport-agnostic (just because it uses HTTP now doesn't mean it has to in ten or fifteen years' time), and that it's easy to associate a Web service with an appropriate URL. That makes directories of Web services easier to assemble.
REST is actually a bit simpler to explain, especially to someone who hasn't grown too accustomed to SOAP. Unlike SOAP, REST relies entirely on HTTP. But because of that, its request language is already known; there are only four "verbs" in REST which translate directly to the GET, POST, PUT, and DELETE. So the need for WSDL on the request side is completely thwarted.
With REST, the item of data the client requests -- not the Web service itself -- is the target of the URL. For example, the field where a customer's surname would appear in a database may be the URL, whereas in SOAP, the URL refers to the service to which a request for that surname would be placed in an envelope. The server responds with a message in an XML envelope that pairs both the item that was requested and its response, which makes it easier for an auditing application to account for data transactions.
Is REST necessarily an easier way to go? It is if you're developing applications using a new concept called the model view controller scheme. These are the "composite" applications to which Microsoft's marketing literature refers; they involve three separate components which may be programmed in completely different languages, and may be running on separate processors. The model component sets up the data that's the subject of an application, whereas the view component prepares a meaningful relationship of that data for a human reader. This tends to translate well to systems where JavaScript or dynamic language code can do the modeling, and HTML can set up the view. The controller may be a server application that maintains the active state and integrity of the database.
It's an extremely sensible way to think of a network application, and it may be much easier to develop such a system because the three aspects of maintaining it can be delegated to separate development teams. But it almost mandates that the "what" of the application -- the part which the model component is setting up, and the view is preparing to lay out -- have a discrete name, without relying upon some Web service to give it a name later on during the transaction process. That's where the REST model may be a better fit.
Last November, Microsoft unveiled something called the ASP.NET Model View Controller Framework at a developer's conference in Las Vegas. There, one of the company's non-employee MVPs, author Dino Esposito, noted what he perceived to be the new framework's key benefit.
Summing up that benefit for his blog, Esposito wrote, "It uses a REST-like approach to ASP.NET Web development. It implements each request to the Web server as an HTTP call to something that can be logically described as a 'remote service endpoint.' The target URL contains all that is needed to identify the controller that will process the request up to generating the response -- whatever response format you need. I see more REST than MVC in this model. And, more importantly, REST is a more appropriate pattern to describe what pages created with the MVC framework actually do."
That's a sentiment Microsoft evidently took to heart. As Corporate Vice President Scott Guthrie wrote in describing his team's MVC implementation, "It includes a very powerful URL mapping component that enables you to build applications with clean URLs. URLs do not need to have extensions within them, and are designed to easily support SEO and REST-friendly naming patterns. For example, I could easily map the /products/edit/4 URL to the 'Edit' action of the ProductsController class in my project...or map the /Blogs/scottgu/10-10-2007/SomeTopic/ URL to a 'DisplayPost' action of a BlogEngineController class."
PDC in Los Angeles is a little over four weeks away, and BetaNews will be there to see how the first public betas of .NET 4.0 with REST perform in comparison to their predecessors.
Wklejono z <http://www.betanews.com/article/NET_Framework_40_to_become_less_SOAPcentric_embrace_REST/1222895836/2>
