java 枚举类组合在一起_Java，.NET，但为什么在一起？

java 枚举类组合在一起

十二年前，Sun微系统公司大张旗鼓地宣布了一种新的编程语言和环境，用于使网页更具动态性和“活力”。 当然，现在，Java编程语言是一种无处不在的工具，它不仅用于将Web页面带入更具动态性的环境中，还用于创建和填充这些页面（通过Servlet和JSP），从而提供事务处理平台业务逻辑（企业Java Bean或EJB），访问消息传递系统（Java消息服务或JMS），访问关系数据库（JDBC）甚至访问大型机（Java Connector API）。 这个故事很难结束。 通过开放源代码的努力和项目，围绕Java的社区每天都在变得更加强大，即使“官方” Java平台通过Java Community Process继续构建，发展和增强自身。

六年前，微软大张旗鼓地宣布了一套适用于各种编程情况的新编程语言和环境。 此后，.NET出现了两个版本，一个是主要版本，其中涉及对运行时的重大更改以及用于对其进行编程的三种最受欢迎​​的语言（C＃，C ++和Visual Basic），以及大量的客户端和服务器新功能。层：事务支持（System.Transactions），泛型（适用于C＃和Visual Basic），目录服务，管理（WMI）等。 这个故事很难结束。 即使Microsoft计划在其下一个版本（Vista附带的NetFX 3.0）中采用新技术，但新兴的社区仍在不断发展，它通过开源和商业化的新项目和构想来增强.NET环境。

多年以来，关于这两种环境的讨论很多，其中许多对一侧或另一侧都具有强烈的煽动性，几乎没有一种非常有用。 毕竟，“我的语言胜于您的语言”，“我的平台比您的平台运行得更快”或“你们很烂”之类的陈述可能是在鸡尾酒会和会议面板上讨论的有趣话题，但它们很难进行有意义的软件开发有意义的讨论。 甚至经过政治，姿态和挑战，试图进行有意义的Java和.NET合作讨论时，典型的对话也转移到高级流行语，例如“ Web服务”，“企业服务总线”或“服务-面向建筑”，几乎没有什么可展示的。 即使这样，一旦经过高层讨论并进入低层细节，讨论的对象通常是SOAP和WSDL和WS-协议，或者通过消息交换数据，或者将JVM托管在CLR内，反之亦然。 。

换句话说，用通俗的措辞来解释：“您继续谈论了如何做，却从未真正谈论过为什么应该这样做。”

从历史上看，关于Java / .NET互操作性的讨论一直被归于体系结构的落后者，在“仅在需要时”的主题下发生互操作性，这仅是因为特定公司同时拥有.NET和Java系统需要与之对话。另一个。 但是，在讨论中没有讨论任何超出此范围的动机，这就是为什么开发人员可能希望一起使用Java和.NET，即使他们不必这样做也是如此。

从表面上看，这是一个危险的主题。 任何关于一个平台可能比另一个平台“更好”的建议都可能引起对偏爱或无知的指责，即使不是对另一个平台“不能”做某事的暗示的直言不讳地表示愤慨。 （这甚至忽略了首先要弄清楚“更好”的含义的基本问题。）与其轻描淡写或设法避免它，不如直面它：这样的指责或批评不容忽视-实际上，它们应该受到欢迎，这是应在何时何地以及如何做出此类决定的更大讨论的一部分。 话虽如此，打开讨论，检查想法并允许读者形成自己的批评意见仍然很重要。

在有关Java / .NET互操作性的系列文章的第一篇中，这正是我们要做的。

* * *

在考虑Java和.NET两者都做得很好时，有几种值得进一步探讨的场景：

Office客户端，J2EE服务器

不论好坏，Microsoft Office都是计算机历史上有史以来发行的（即使不是最流行的）（也就是说，它安装在更多计算机上）软件平台之一。 在交付的第二个十年中，Office还代表了一个强大的平台，用户可以从中输入，操作和查看来自各种不同来源的数据。 鉴于目前这些用户感兴趣的大量数据都位于支持J2EE的企业服务器中，因此寻找将这些数据引入Office平台以便于更轻松地操作和检查的方法是一个很好的案例。 更加有趣的是，通过进程外通信工具来检查Office平台如何利用已经在Spring或其他轻量级Java容器中编写的现有业务逻辑。

2006年8月发行的《 MSDN杂志》（可从http://msdn.microsoft.com/msdnmag/issues/06/08/default.aspx在线获得）刊登了几篇有关Office开发的文章（因此，强烈建议将其作为背景材料）对于不熟悉Office程序功能的任何人），并在文章“使用Office作为开发平台时您需要了解的知识”中，图表显示了Office平台功能的完整列表。 一个小节没有完整地重申该列表，而是巧妙地列出了Office的一些可扩展点，这些点在Java平台上很好地发挥了作用：

• 外部自动化 。 得益于COM Automation的强大功能以及现在的逻辑继承者，Visual Studio Tools for Office（VSTO），Office-Word，Excel，Outlook等的主要组件都可以由外部API“驱动”，因此可以从通用编程语言中创建文档。 鉴于Excel强大的图表和计算功能，或者Word的编辑和拼写检查功能，考虑一下Java应用程序在托管环境中可以对这两个应用程序（服务器上的Web应用程序可以驱动Word创建客户邮件或在服务器上）做些有趣的事情。通过J2EE服务器填充某些数据元素的打印报告文本，方式与Velocity引擎填充模板以显示为HTML的方式相同，例如，或通过Eclipse Rich Client Platform托管在客户端上。已经托管COM自动化组件。 （实际上，Eclipse可以在已经安装了Office的Windows机器上开箱即用地创建新的Word文档。）如果用户只需要查看Word文档而不是编写它们（如Microsoft所创建的那样），则此功能特别强大。可以使用免费的Word查看器-Java Web应用程序可以创建Word文档，然后通过HTTP传送它，以比HTML提供的格式更丰富的格式在Web上进行查看。
• 
  
  
• 加载项 。 Office还能够托管“加载项”，即“插入”以在Office内部运行的软件组件，通常可以通过菜单栏或上下文菜单使它们可用。 .NET组件可以将自己注册为Excel电子表格加载项，并使用某种形式的Java连接（Web服务，专有远程处理工具包甚至是进程内托管）与Java业务组件联系以进行验证，数据检索或存储。 。 例如，许多公司都将Excel用作发票和/或记帐解决方案，因此可以将Java组件用作进出公司在企业服务器上运行的，基于Java的较大记帐程序包的简便方法，该程序包可通过以下方式访问EJB会话Bean内的Java连接器。
• 
  
  
• Excel用户定义函数 。 Excel长期以来一直具有从其计算引擎中“调用”用户定义的功能的能力，尽管从历史上看，这些功能必须以非托管（原始C ++）代码编写，这会给应用程序带来危险的不稳定。 创建一个Excel用户定义函数，该函数是对应用程序服务器中定义的现有业务逻辑的一个简单包装，例如在Excel电子表格模板中调用库存检查以生成采购订单，这为Excel提供了大多数人所缺乏的强大的“在线”体验Excel用户。
• 
  
  
• 智能标签。 这是Microsoft赋予该功能的名称，其中在文档感兴趣的内容旁边会出现一个包含下拉箭头的小框。 智能标记通常包含配置或自定义Office文档中特定元素的机会。 例如，当Word自动更正它认为是输入错误的内容时，将鼠标悬停在已更正的单词上会弹出一个智能标记，允许用户在选择列表中放下选择列表并“撤消”更正，这不是一个实际的错误。 智能标签是插件的一种形式，因此可以用作另一种视觉帮助，以帮助用户静默地弥合客户端与企业服务器之间的鸿沟。

Office还为使用这些编程元素编写/部署的组件和文档提供了一些部署支持，因此在许多情况下，更新这些组件内部的功能就像在共享下载服务器上发布内容一样容易。 显然，使用Office的主要考虑因素将是Office的许可成本，但是幸运的是，大多数业务环境已经部署了Office，即使不是全部，也可以大大降低成本。

Spring或J2EE容器中的Windows Workflow

Windows Workflow是Microsoft作为“ NetFX 3.0”版本的一部分发布的新框架，该框架将随Windows Vista一起提供。 工作流旨在提供一种核心业务流程功能的方法，该功能可以是小规模的（例如，网站中页面之间的交互），也可以是大规模的（例如，提交保险索赔的主要处理步骤）-由非开发人员创建，查看，跟踪和编辑。 工作流开发人员（无论是传统的.NET开发人员还是领域专家）都使用类似于流程图的环境来设计工作流，这些工作流由代表流程中每个逻辑步骤的活动组成。 该环境通常可以从Visual Studio中获得，但也可以从自定义应用程序中托管，因此使公司能够将Workflow Designer置于完全不在传统“程序员”工具集之外的环境中。 然后，以XML格式或代码形式表示的结果工作流设计工件由工作流编译器编译为常规.NET类，并由WorkflowRuntime处理，该工作流可在各种环境中托管，包括ASP.NET，控制台应用程序或GUI应用程序。 工作流可以是顺序的，也可以由外部状态更改来驱动，甚至跨很长时间也是如此。

鉴于WorkflowRuntime在托管环境和上下文方面设计得很灵活，因此一个直接的想法是以某种联合方式使用Workflow和Spring（或另一个J2EE容器）-WorkflowRuntime托管Spring容器并创建自定义Activity调用Spring Beans来执行某些业务功能，或者通过将WorkflowRuntime托管在Spring Bean内来执行工作流，以响应传入的Spring应答的远程调用。 特别是在后一种情况下，最终用户可以使用直观的环境来设计业务流程，但仍可以在传统的企业服务器环境中运行。 类似地，工作流狂热者已经在描述如何使用工作流以一种与Struts动作映射文件不同的方式来构造ASP.NET应用程序中Web页面的导航。 将工作流托管在servlet容器内部以执行相同操作将是一种等效方法，并且再次提供对当前被XML语法遮盖的servlet / JSP页面之间的“流”的可见性。

Windows Presentation Foundation客户端到Java服务

最后但并非最不重要的一点是，一起使用.NET和Java可能会成为最有说服力的案例：使用新的Windows Presentation Foundation技术，可以提供由功能强大的Java服务提供的数据模型之上的功能丰富的UI（ Spring，EJB或其组合）。 WPF基于XAML的声明式编程模型与最近的以前的基于代码的UI编程模型形成了鲜明的对比，并且在许多方面，它使创建复杂的用户界面比Swing或SWT可以更轻松地进行。 而且，由于XAML是基于文本的格式，因此像今天HTML一样，动态生成XAML并将其下载到客户端层以执行也变得可行。

规范场景将使WPF前端通过Windows Communication Foundation（WCF）与Java后端进行对话，WCF是Microsoft的新通信管道，它将其所有分布式通信编程模型统一为一个框架。 除了支持许多最新的WS- *规范之外，WCF还提供了丰富的可扩展性模型，可通过多种方式进行通信，包括通过REST格式（有时称为Plain Old XML或POX），甚至可能使用其他传输方式进行通信。 UDP之类的媒体。 Sun的Tango项目使该方法更加可行，该项目将与WCF的无缝集成作为特定的设计目标。

* * *

不用说，这个清单几乎不是Java和.NET之间可能的互操作性方案的总和； 实际上，为了使本文的长度易于管理，我们巧妙地忽略了其他几种可能性：

• 使用Eclipse Rich Client Platform作为客户端，可以托管自定义RCP视图，该视图通过DCOM与.NET / COM +服务组件或WCF服务进行对话。
• 使用Swing客户端和/或JavaWebStart通过Windows Server 2003计算机上承载的Excel计算引擎创建可移植，可下载，零部署的客户端应用程序解决方案。
• 使用DirectX在SWT应用程序内部提供本机3D效果（包括声音）。
• 使用Microsoft Speech Server向Swing或J2EE应用程序提供交互式语音识别（IVR）“前端”。

依此类推，依此类推，依此类推。

听起来这一切都是牵强附会且不合理的耸人听闻，这种情况是在营销人员的脑海中冒出来的，他们手上的时间太多了，感觉还不够。 当Java具有公式引擎时，为什么还要打扰Excel？ 当使用JAX-WS时，为什么还要对WCF感到烦恼，而当使用Java3D时，为什么还要对WPF感到烦恼呢？ 为了避免被指责偏or或公然的Marketecture，让我们坦白而明确：.NET可以做的几乎任何事情，Java也可以做到，反之亦然。 但我们也要特别诚实地对待一个事实：这两个平台都有其非常出色的特定领域。 对于愿意搁置政治教条以支持开放讨论的开发商，发挥各自的优势可以带来一些强大的好处。 或者，用相当宽松的话引用卡尔·马克思的话：“从每个平台，根据其功能，到每个项目，根据其需求。”

翻译自: https://www.infoq.com/articles/java-dotnet-integration-intro/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

java 枚举类组合在一起