Archives / 2004 / November
  • [Interop] How to Apply the Basic Profile (Web Service practices)

    Got this URL on a Microsoft seminar. Seems to contain some pretty good recommendations and best practices. Especially the chapter about "How to Apply the Basic Profile":

    This chapter details some best practice recommendations. These recommendations explain how to use Microsoft® Visual Studio® .NET to create Web services and Web service clients that conform to the Basic Profile. Some recommendations are general guidelines while others apply to particular directives in the Basic Profile. If a recommendation does apply to particular directives, their numbers are listed in square brackets after the recommendation (for example, [R1120]).

    The whole thingy is available as a pdf file too.

  • MVC in ASP.NET

    I agree with Eric that the way the Model-View-Controller (MVC) pattern is described at the .NET architecture center is not really spot-on. I've always looked at the (typed) DataSets as the model.

    Not that it matters much but it's fun to discuss common patterns like this :)

  • Unable to load DLL (oci.dll)

    It's been written in several places, but lots of people still seem to get this error when deploying ASP.NET apps that use Oracle on win2k3. It's all about permission to the oracle client directories. Make sure Everyone or the ASPNET account got read and execute access to the oracle client directories, especially the bin dir and where you keep your tnsnames.ora file.

    You may have to reboot the server to make it work properly. Sometimes it works straight off with a restart of the web app, but I've had to reboot the server once to make it work.

    If you add the rights to the top "oracle" or "ora92" directory or similar, make sure the rights gets applied to the lower directories. Windows 2003 can be a bit tricky with that.

  • "What are the best practices for J2EE?"

    I'm reading the comments-battle between IBM and Microsoft regarding the IBM WebSphere/J2EE versus Microsoft .NET "Productivity, Performance, Reliability and Manageability Analysis" performed by The Middleware Company not long ago. I have long experience from both large and small J2EE and .NET projects, and some of the comments from Microsoft are quite funny and I must say spot on. Like this one:

    IBM comment: We believe that if J2EE development best practices had been used, the developer productivity would have exceeded that of Visual Studio.NET. The performance and manageability of the WebSphere J2EE application also would have exceeded the published numbers.

    Microsoft comment: The tricky question here is what are the best practices for J2EE? In several cases, the  WebSphere team was using best practices documented by Sun, and yet IBM claims that they were not best practices. This confusion is typical in the J2EE programming model, and is the source of a programmer productivity tax. One thing these studies have shown over and over again is that with J2EE, often times the huge number of architectural choices, with no clear guidance on the tradeoffs between them, leads to failed implementations and loss of productivity. This study and IBM’s response proves that even the J2EE vendors themselves do not agree on how to build a J2EE application. for example, use EJBs or no EJBs? Use stateless session beans or entity beans? Use JDO vs. entity beans? Use POJOs with embedded JDBC? Use a straight servlet architecture instead? Use a third party framework (eg. Struts) or not? The choices are complicated, and many customers find out late in the game they have made the wrong choice. A choice that  works well in one application server, may not work well in another.