May 2003 - Posts
I had some discussions with Clemens and customers last week at the newtelligence TornadoCamp.NET. And as you may guess the main point just was COM+ and Enterprise Services and the available techniques for distributed architectures (BTW, I did not know that you could install and run Windows NT 4.0 Option pack on a Windows 98 or ME machine and thus have mtx.exe by your side ...).
Through the last years I have designes & programmed quite a few applications on the server side with the help of MTS and then COM+ 1.0. I must admit that the idea of such an 'application server' has always been fascinating me (not to speak about the copy&paste actions from the Java guys with the diverse features found in MTS and COM+). While I never was fully confident with the runtime itself - e.g. performance in mission critical scenarios - I also admired how easy it was to use complex things just by enabling a checkbox. Now with .NET Enterprise Services things get even cooler: use the wonderfully easy attribute based programming in .NET and begin to think with COM+ starting from the first line of code. Indeed, I am giving a lot of talks and classes just around COM+ and Enterprise Services becuase of my professional background.
But what I never explicitly came across was to properly think about when which 'distributed technology' (read: DCOM, Remoting, COM+, Web Services) might be the best choice. For me the situation was clear: take DCOM only in COM-enabled applications; Remoting between any .NET enabled applications; and XML Web Services for cross platform interoperability. And COM+ is only leveraged in typical application server scenarios for server-side business logic. Sounds familiar? I have the dumb feeling we have to rethink some bits ... forget about this very bad naming disaster: COM+, puh! MTS, huh? Component Services just gets it right, without Enterprise Services being top-notch.
To be honest: I have never thought too much about COM+'s client side capabilities just by leveraging its features through a library application (don't invent your own process model again and again) ... it is available on every Windows 2000, Windows XP and of course Windows Server 2003 box.
As Clemens now might say: "He is beginning to see the light .." - well, I have seen the light for quite a long time now, but this light was not as bright as it seems now! If I only had the time to fly to Dallas and listen to his DEV357: Building Distributed .NET Applications talk - or are you doing it also in Barcelona, Clemens?
Just for the sake of completeness, my feelings were only confirmed by reading this article on MSDN:
.NET Enterprise Services and COM+ 1.5 Architecture
Been out of the BPEL et. al. thing for a while now as I currently have to do some things I have to do (== work for a living :-)).
But Tomas is currently playing with Collaxa's Beta 9 and is quite confident up to now.
To add, there are three very interesting slide decks on BPEL from three gods at Collaxa's Take weblog.
... if I only had more time for all this very exciting stuff ...
John Bristowe did it: his first article is in print. Congrats! And of course it is all about XML Web Services - WS-Security & WSE in particular.
The fact that SOAP messages are represented in XML raises a number of concerns when transmitting sensitive data across the wire. While existing transport protocols like SSL/TLS can address some of these concerns, they do not provide a solution that will work beyond a point-to-point scenario. It is important to remember that SOAP messages can be routed through one or more intermediaries and over one or more different transports. Given the nature of SOAP, an end-to-end solution that can be expressed at the message level and that is independent of the underlying transport protocol is needed. Enter WS-Security.
O'Reilly has released the third article of a small series on XML Web Services Security, now all about SAML and Single-Sign-On:
In this article I discuss XML-based authentication and the sharing of authentication information across different applications, known as Single Sign-On (SSO). The Security Assertions Markup Language (SAML, often pronounced "sam-ull") from OASIS helps reach this goal by wrapping authentication information in an XML format.
Amazon has just released a new version of its Amazon Web Services Package (now 3.0).
The new features include - besides the shopping cart integration:
- Additional Power Searches
- Enabling Honor System with Quick Click
- Keyword Searches
- Marketplace Searches
- Mobile Access to AWS
- Price Range Searches
- Using Amazon Chat
- ... and a few others ...
To be honest, for me it is not very surprising that the appropriate working groups in the OASIS and W3C now seem to find a way to go together in the Web Services choreography/orchestration war. After the foundation of the Web Services Business Process Execution Language (WSBPEL) Technical Committee at OASIS and the good news last week that Sun and Oracle tend to join this committee, my feelings about the bright future of XML Web Services' success in the enterprise and beyond came back ... :-)
And in my opinion this is the only way: try together and let the best market share decide ;-)
Chris Sells has chosen the sessions for the Applied XML Conference.
Not only were there 4x the number of sessions submitted that could be accepted, but the quality bar was so high that it was almost impossible to narrow them down. The good news for attendees is that the ones we picked are going to rock.
The seating for Applied XML is limited and all previous DevCons have sold out, so you may want to grab your seat now. And once you’ve done that, please spread the word! The more XML and web services zealots in one place, the better!
All I can say: definitely book this conference, it will be worth it! The guys speaking there really rock ...
Sure, we all love ASP.NET 1.1. Scott, Rob, and team really rock! But have you ever looked at what HTTP headers ASP.NET returns? Well, I will show you:
[...]
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
[...]
Oops! In my opinion this is just a little bit too much - just think about some nice and neat attacks based on this information. Now the ASP.NET related expert would answer: "He guy, this is no problem. There is a switch for configuring the HTTP runtime in machine.config! Just use the appropriate attribute to turn this off.". OK, here is the attribute switch:
enableVersionHeader="[true|false]" -
outputs X-AspNet-Version header with each request
But again, this will only eliminate X-AspNet-Version, X-Powered-By still remains. To make a long story short: Christoph Wille found some time (I kindly asked him :-)) to write a small IIS ISAPI filter which kills this last header. Take it and have fun - freedom and peace for everyone ...
Here is the second part of Simon Guest's (in corporation with Christopher St. John) article on Web Services Security interoperability between Java and .NET - this time leveraging the fabulous Java GLUE toolkit:
Web Services Enhancements 1.0 and Java Interoperability, Part 2
The same points apply here as for the first installment :-) I promise there is quite a lot still come here ...
I came across two new articles on MSDN. Well, I must say they both are very informative and partly give new insights for me (mostly the first one).
Fritz Onion: ASP.NET Pipeline - Use Threads and Build Asynchronous Handlers in Your Server-Side Web Code
Fortunately for developers, threading in ASP.NET is a lot easier than it was in ASP. In this article, the author takes a look at threading in the ASP.NET HTTP pipeline, and explains how threads are managed efficiently without the involvement of the developer. The article considers how the common language runtime threadpool is used by ASP.NET to service requests, looks at the pooling mechanisms used for handlers, modules, and applications, and covers both IIS 5.0 and IIS 6.0 and how they differ in their approach to request processing and thread allocation. Finally, how and when to use asynchronous handlers is discussed for developers who still need to use threads in their own applications.
Aaron Skonnard: How ASP.NET Web Services Work
See how Microsoft ASP.NET Web services methods (WebMethods) provide a high-productivity approach to building Web services. WebMethods can expose traditional Microsoft .NET methods as Web service operations that support HTTP, XML, XML Schema, SOAP, and WSDL. The WebMethod (.asmx) handler automatically dispatches incoming SOAP messages to the appropriate method and automatically serializes the incoming XML elements into corresponding .NET objects.
More Posts
Next page »