Surprise. WSE 2.0 is released. Everyone saw this announcement coming, but it's nice to get it out and move on. Rebecca is onstage right now, doing a demo on WSE and the new Office Information Bridge Framework with Ballmer.
惊喜WSE 2.0已发布。 每个人都看到了这个宣布，但是很高兴将其发布并继续前进。 丽贝卡(Rebecca )目前正在舞台上，与鲍尔默(Balmer)合作进行WSE和新的Office Information Bridge框架演示。
Wizzy Thoughts
烦躁的想法
The release of WSE (for me) brings up a number of different questions around Web Services on the .NET Framework.
WSE的发布(对我而言)围绕.NET Framework上的Web服务提出了许多不同的问题。
It's great that these standards are being followed so closely and that Microsoft is so quick to support the WS*.* specs. However, how long will we have WSE to use while we wait for Indigo and the rest of the specs? Is it something that will be supported for the next five years?
非常高兴能严格遵守这些标准，并且Microsoft能够如此Swift地支持WS *。*规范。 但是，在等待Indigo和其余规范时，我们将使用WSE多长时间？ 未来五年会支持吗？
It's great that these standards are being followed so closely and that Microsoft is so quick to support the WS*.* specs. However, how long will we have WSE to use while we wait for Indigo and the rest of the specs? Is it something that will be supported for the next five years?Question: Would you go live in production with WSE 2.0? Or, would you find an out-of-band solution for security? (Certs, IP-SEC, Networks)My Personal Answer (today): I would use WSE when required for Interop but with caution. Question: Is WSE the COM-Interop of Web Services (an interim bridging technology that will ALWAYS be with us, but interim none the less) and is that a bad thing?My Personal Answer (today): Kinda feels like it! I've been thinking more and more about simpler solutions. When you don't need routing and intermediaries, why not go move to a more REST-ful solution? They are certainly easy to write, but there's not a lot of "framework" around it. Perhaps that's a good thing, but while I could write a REST-ful proxy generator, it'd be nice to see formalized support for simpler architectures. If you know me, you know I'm ALL about Web Services, but at the same time, the more I read the WS*.* specs and talk to Joe Programmer, I worry that we're freaking him out.
非常高兴能严格遵守这些标准，并且Microsoft能够如此Swift地支持WS *。*规范。 但是，在等待Indigo和其余规范时，我们将使用WSE多长时间？ 未来五年会支持吗？ 问：您将使用WSE 2.0投入生产吗？ 还是您会找到一种带外安全解决方案？ (证书，IP-SEC，网络) 我的个人回答(今天) ：Interop需要时，我会使用WSE，但要谨慎。 问题：WSE是Web服务的COM-Interop(一种过渡桥接技术，将永远伴随着我们，但仍然是过渡技术)，这是一件坏事吗？ 我的个人回答(今天) ：Kinda感觉就像这样！ 我一直在思考更简单的解决方案。 当您不需要路由和中介时，为什么不转到采用更具REST功能的解决方案呢？ 它们当然很容易编写，但是周围没有很多“框架”。 也许这是一件好事，但是尽管我可以编写一个REST-ful代理生成器，但很高兴看到对更简单的体系结构的正式支持。 如果您了解我，就知道我对Web服务一无所知，但是与此同时，我越是阅读WS *。*规范并与Joe Programmer交谈，我担心我们会吓到他了。
It's great that these standards are being followed so closely and that Microsoft is so quick to support the WS*.* specs. However, how long will we have WSE to use while we wait for Indigo and the rest of the specs? Is it something that will be supported for the next five years?Question: Would you go live in production with WSE 2.0? Or, would you find an out-of-band solution for security? (Certs, IP-SEC, Networks)My Personal Answer (today): I would use WSE when required for Interop but with caution. Question: Is WSE the COM-Interop of Web Services (an interim bridging technology that will ALWAYS be with us, but interim none the less) and is that a bad thing?My Personal Answer (today): Kinda feels like it! I've been thinking more and more about simpler solutions. When you don't need routing and intermediaries, why not go move to a more REST-ful solution? They are certainly easy to write, but there's not a lot of "framework" around it. Perhaps that's a good thing, but while I could write a REST-ful proxy generator, it'd be nice to see formalized support for simpler architectures. If you know me, you know I'm ALL about Web Services, but at the same time, the more I read the WS*.* specs and talk to Joe Programmer, I worry that we're freaking him out. Question: The Basic Profile is great, but are the other specs getting too complicated?My Personal Answer (today): Kinda feels like it! WS-Security will be more useful when there is a more support on the Java side. As far as WS-Policy, it seems that Dynamic Policy is where the money's at and it's a bummer WSE doesn't support it.
如此严格地遵循这些标准以及Microsoft如此Swift地支持WS *。*规范真是太好了。 但是，在等待Indigo和其余规范时，我们将使用WSE多长时间？ 未来五年会支持吗？ 问：您将使用WSE 2.0投入生产吗？ 还是您会找到一种带外安全解决方案？ (证书，IP-SEC，网络) 我的个人回答(今天) ：Interop需要时，我会使用WSE，但要谨慎。 问题：WSE是Web服务的COM-Interop(一种过渡桥接技术，将永远伴随着我们，但仍然是过渡技术)，这是一件坏事吗？ 我的个人回答(今天) ：Kinda感觉就像这样！ 我一直在思考更简单的解决方案。 当您不需要路由和中介时，为什么不转到采用更具REST功能的解决方案呢？ 它们当然很容易编写，但是周围没有很多“框架”。 也许这是一件好事，但是尽管我可以编写一个REST-ful代理生成器，但很高兴看到对简单架构的正式支持。 如果您了解我，就知道我对Web服务一无所知，但是与此同时，我越是阅读WS *。*规范并与Joe Programmer交谈，我担心我们会吓到他了。 问题：基本配置文件很棒，但是其他规格变得太复杂了吗？ 我的个人回答(今天) ：Kinda感觉就像这样！ 当Java方面有更多支持时，WS-Security将更加有用。 就WS-Policy而言，动态策略似乎是金钱所在，WSE不支持它。
What are your answers?
你的答案是什么？
新的.NET工具与现有的开源工具 (New .NET Tools vs. Existing Open Source Tools)
Now Prashant is showing the Visual Studio Team System (Whitehorse). It includes Unit Testing and Code Coverage support. The Code Coverage stuff is pretty sexy; it highlights the code that wasn't tested in Red and the tested code in Green. I need to learn more about theis new Unit Testing before I feel good about it.
现在，Prashant正在展示Visual Studio Team System(怀特霍斯)。 它包括单元测试和代码覆盖率支持。 代码覆盖率的东西很性感。 它突出显示了未经红色测试的代码和未经测试的绿色代码。 在对新的单元测试感到满意之前，我需要学习更多。
It's easy to justify using NUnit when there are no Unit Testing tools included with Visual Studio. When VSS came out (actually when it was purchased from OneTree) Microsoft was bringing Source Control to the masses. While lots of folks don't use an SCC at all, many folks use VSS simply because it's free. However, often folks have to suffer with VSS for a few years before they justify a change over to CVS or something else. I'm going to dig into this Unit testing stuff to see how to relates to NUnit (which we use with much happiness) and the up-and-coming MBUnit. There's a lot of interesting stuff going on. I don't know if these qualify as "smackdowns," but it sure seems like a few wheels are being re-invented. I need to get my thoughts straight and think about:
当Visual Studio不包含单元测试工具时，使用NUnit进行证明很容易。 当VSS出现时(实际上是从OneTree购买时)，Microsoft将源代码管理带到了大众手中。 尽管许多人根本不使用SCC，但许多人之所以使用VSS仅仅是因为它是免费的。 但是，通常人们必须经历VSS几年的痛苦之后，才能证明改用CVS或其他方式是合理的。 我将深入研究这个单元测试的内容，以了解如何与NUnit(我们非常高兴地使用它)和即将出现的MBUnit相关联。 发生了很多有趣的事情。 我不知道这些是否符合“击倒”的标准，但是肯定好像是在重新发明一些轮子。 我需要直截了当地思考：
- MSBuild vs. NAnt MSBuild与NAnt
- Team System Test vs. NUnit and NUnitAddin 团队系统测试与NUnit和NUnitAddin
- Team System Coverage vs. nCover, etc. 团队系统覆盖率与nCover等
As an aside, wouldn't it be nice to include Lutz's Reflector with VS.NET?
顺便说一句，将Lutz的Reflector包含在VS.NET中不是很好吗？
翻译自: https://www.hanselman.com/blog/teched-2004-keynote-and-the-wizzy-release-and-more-innovation
90
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
