问题标签 [enterprise]

我正在寻找这种企业集成模式的实现

http://msdn.microsoft.com/en-us/library/ms978583.aspx

以更一般的方式解释

http://www.eaipatterns.com/Messaging.html

Delphi 是否存在“消息总线”（或消息队列）模式的开源实现？

有很多基于 Java/Ruby/Python/PHP 等的Web 应用程序框架。我热衷于发现、比较和对比各个框架独有的功能。

您认为哪个框架功能有用，为什么了解它很重要？

例如

• Stripes：FlashScope - Flash 范围很有用，因为它允许临时使用会话来存储两个请求之间的信息。将信息作为 URL 参数放入或实施自定义逻辑以在使用后删除参数的替代方法。
  http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/controller/FlashScope.html

您能否将每个帖子限制为一个功能。

概括：

• 条纹 - 闪光范围
• Django - 模板中的 JSON 化变量
• Symfony - 模型生成。后端管理生成
• Grails - GORM 形式的强大 ORM
• Seaside - 没有关系数据库，只是代码 OO
• 西纳特拉 - 极简主义
• Spring Web Flow - 流和视图范围

我正在构建一个基于许多属性搜索人的工具。这些属性的值分散在多个系统中。

例如，dateOfBirth 作为系统 ABC 的一部分存储在 SQL Server 数据库中。该人的销售区域分配存储在一些可怕的遗留数据库中。其他属性存储在只能通过 XML Web 服务访问的系统中。

更糟糕的是，遗留数据库和 Web 服务可能真的很慢。

在所有这些系统中实施搜索时，我应该考虑哪些策略和技巧？

注意：虽然我发布了一个答案，但我不相信它是一个很好的答案。除非没有其他人提供更好的见解，否则我不打算接受我自己的答案。

我被要求部署或开发一个企业（内联网）搜索引擎，它可以索引几个内部服务器的所有网页，并有一个搜索门户来显示所有相关内容，就像谷歌正在做的事情，但对于内联网。

任何建议如何快速开发或部署？听说过微软FAST产品，不知道是不是这个用途？

提前谢谢，乔治

我遇到了 DRY 原则（不要重复自己）和最小化围绕 Rete 规则引擎的依赖关系的问题。

大型 IT 组织中的规则引擎往往是企业级的（注意大写的“E”——这是一项严肃的业务）。所有规则都必须表达一次，既好又干，并集中在一个昂贵的规则引擎中。组维护规则引擎并且是规则集的保持者。

当该 IT 组织是美国保险公司的一部分时，往往会有很多规则。有适用于所有州和产品的规则，但每个州倾向于针对不同的产品制定自己的法律，因此规则需要反映这些怪癖。类别很多：精算、承保，甚至用于从第 3 方机构订购信用和机动车辆报告。

从设计的角度来看，我遇到的问题是集中规则和处理当然是好的和干燥的，但是有成本：

1. 额外的网络跃点以访问位于中心的规则服务并返回结果；
2. 如果规则引擎被暴露为 SOAP Web 服务，则额外的复杂性 - 消费者必须打包 SOAP 请求并将响应 OXM 回他们自己的域；
3. 维护规则引擎的企业组、设置和维护规则的业务以及使用规则的开发人员之间的附加接口；
4. 额外的复杂性——有时数据驱动的解决方案可能就足够了。
5. 额外的依赖——无法控制自己规则的组件不得不担心规则引擎的外部依赖，以进行测试、部署、发布等。

许多其他企业技术（例如，B2B 网关、ESB 等）都会出现这些问题。

相同的企业组也将 SOA 吹捧为基本原则。但我对正确服务设计的理解是，它们应该平铺业务空间，并且是幂等的、独立的和孤立的。如果服务的规则在其他地方维护，服务如何独立和隔离？

我想在简单性方面犯错，认为如果规则可以被证明仅适用于孤立的情况，那么消除依赖关系应该优先于集中化。我不确定这个争论是否会赢得胜利。

所以我的问题是：

1. 您对集中化与独立性的争论有何看法？
2. 您对规则引擎等企业工具有何经验？
3. 我怎样才能使孤立的论点更有力？
4. 如果我的观点不正确，你会提出什么论据来支持中心化？

在大型 Java/.Net Enterprise 项目中，是否每个开发人员都需要在其类路径/本地开发环境中拥有所有组件/库/依赖项才能构建它？

还是将它们分成更小的部分，可以单独构建（这样它们就不需要引用所有依赖项）？

换句话说：如果他们想运行整个应用程序，他们需要所有组件；但如果他们只运行应用程序的一个子集，他们将只需要相应的组件子集。

大型企业项目通常采用第一种方式还是第二种方式组织？

一个可能的组织是，如果您正在处理整个项目的一个模块，该模块是自包含的，但被其他模块引用（换句话说，依赖树中的叶节点）。

另一个组织是，如果您动态加载您使用的类，您可以在类路径中不包含任何类的情况下进行构建。要运行它，您的类路径只需要访问您实际加载的那些（可能有许多其他组成项目的不同部分，您不加载）。

这些是理论上的可能性；但是企业项目的标准做法是什么，在……好吧，在实践中？

我已将其扩展为包括 .Net，因为我认为那里会出现同样的问题（DLL 地狱？）

我有一个相当开放的一般问题（即“取决于平台、应用程序类型等”），但我正在寻找一般准则作为答案。

什么时候设计应用程序以实现连续运行（100% 正常运行时间）与计划的每日关闭/重启？

显然，Web 应用程序需要一直处于运行状态，因此假设我们正在讨论一个内部企业应用程序，例如会计系统或仅在工作日工作时间活跃使用的 B2B 系统。

我听到的每个论点如下：

Pro 100% Uptime：“一旦你的应用程序运行起来，最好保持它运行，因为当你关闭它时它可能不会重新启动。”

Pro Daily 重启：“一个连续运行了 3 年的应用程序可能有一天会宕机，没有人知道如何让它重新上线。”

其他考虑因素是内存增长、性能、维护需求等。这是一个编程问题，因为您所做的选择会影响您的技术设计。例如，如果您知道应用程序将每天关闭/重新启动，则无需每天编写某些批处理作业和清除状态。

想法？

我一直在探索和开发一个 Python 应用程序，用于商业银行领域的关键任务工作。

银行在选择新应用程序时非常保守。

我需要真正的稳定性证明和其他人使用。

看过 Python 网站，但现在我希望这群人能告诉我更多。

到目前为止，我还没有下一阶段需要的开发银行合作伙伴，所以我正在收集证明和宣传信息。所有帮助和评论表示赞赏。

尽管我搜索了很多，但我无法找到一套用于修补生产企业 Java 系统的最佳实践。我什至听说有人把它描述为一种黑色艺术。

所以，我的问题是，是否有为生产系统提供补丁的已定义最佳实践？这些是什么？对任何此类做法的参考将不胜感激。

谢谢，史蒂夫

我们之前讨论过SSO。考虑到最近的新发展，我想重新加强与定义要求的对话。

在过去的一周里，我一直在进行市场调查，以寻找以下关键问题的答案：

该项目应该是：

要求

• Web 应用程序的 SSO 解决方案。
• 集成到现有开发的产品中。
• 具有基于策略的密码安全性（长度、复杂性、持续时间和 co）
• 可以使用 Web 界面管理安全策略。
• 可定制的用户界面（密码提示和 co. 屏幕）。
• 高度可用 (99.9%)
• 可扩展。
• 在红帽 Linux 上运行。

很高兴有

• 包含用户组和角色。
• 用 Java 编写。
• 自由软件（开源）解决方案。

到目前为止，没有一个解决方案是“杀手级选择”，这让我认为我将使用几个项目（OWASP、AcegiSecurity + X??）因此进行了讨论。

我们是提供前端和后端应用程序套件的 ISV。前端被分成几个模块，这些模块应该作为自治单元，从客户端的角度来看，他使用“应用程序”——这导致了这个重新分级 SSO 的讨论。

我希望人们分享他们关于适当解决方案的经验和想法。

一些解决方案很有趣

• 中国科学院
• Sun OpenSSO 企业版
• JBoss 身份 IDM
• 约索
• Tivoli Access Manager for Enterprise Single Sign-On

或者更笼统地说这个列表

谢谢你，马克西姆。