在考虑建模软件系统时,此类模型总有许多入口点,有许多可使用的表示法,并且当然有许多方法可以使用,这些情况很普遍。 在大多数情况下,这些入口点是由于必须解决的技术或业务领域方面的特定问题而产生的。
这些问题非常重要,足以充当起点,因为了解它们以及它们之间的交互对于实现成功是至关重要的。
我们曾经观察到在开发面向服务的解决方案时有少数此类问题;下图将这几大问题表示为特定的设计任务。
虽然这些问题中的每一个都可以充当服务设计的起点,并且针对某个特定的服务类对每种方法进行了很好的优化,但很有可能大型项目在确定和设计服务时会结合使用多种方法。
关于更多信息,请参阅活动:现有资产分析,其中展示了一组支持这些方法的详细技术。
在此方法中,重点就集中在服务领域。通过诸如领域工程或面向对象的分析和设计等技术,能够很深入地了解抽象领域模型的开发。 此方法的重点一般就是为消息模式产生可复用性高的模型。 服务设计通常是辅助活动,虽然它有时候是并行执行的。
例如,在电子数据交换(EDI)中,不存在任何真正的服务接口概念,这是因为 EDI 系统通常具有一个单独的消息全局收件箱和发件箱。
传统的“商家到商家”场合(通过 EDI 标准化表示)就是此类方法的一个示例。 在此情况下,设计活动的重点是开发特定行业或其他范围中达成一致,并且被视作具有代表性的消息类模式的消息模式,例如 ACORD、SWIFT 和 RosettaNet
等行业标准(请参阅任务:消息设计)。
在此方法中,设计人员关心的是将业务或应用程序期望的功能显现为一个或一组服务。 在此情况下,我们不必了解哪些服务客户机选择处理我们的服务,但我们了解这些客户机期望的交互种类。 因此,消息应当是次要的,它们是为响应操作的需求而开发的。
诸如 Amazon 和 eBay 等公司提供的 Web Service API
就是此方法的示例。此类服务接口不在客户机上放置业务流程。在大多数情况下,它们甚至不在客户机上施加所需的接口,但是它们以一种明确且直观的方法向第三方开发人员显现相应的服务供应商的操作。
如上所述,通过了解参与者的需要、服务的外部客户机以及提供支持这些需要的操作(例如浏览目录)、向购物车添加商品、检出等,以服务为中心的建模通常很适合于用例驱动的方法。
在协作设计中,重点在于两个或更多服务的协作;这就是一个由服务组成的流程视图,与软件开发活动相比,它与更传统的业务建模相关。 在此方法中,服务被视为协作中的履行角色,因此服务规范是为跨一个或多个协作的角色定义的一组职责。
那些参与开发 RosettaNet Partner Interchange Processes(PIPs)或 OAGIS 标准的人员认可此类方法,虽然在这些情况下并未充分进行协作。 在与业务流程设计有关的事务或业务集成活动中(其中 IT
系统的组件显现为服务),此类方法很常见。
在此情况下,通常可从协作直接派生服务规范,但是此方法似乎不太注重消息内容,这导致需要一种混合方法才能顾及完整性。
策略是一个含义广泛的术语,此处表示可视为非功能需求的语句或约束。 从此模型的角度,必须认识到我们不希望模型中含有关于技术信息的详细语句,而是根据这些需求更实际地捕获系统的用途。
例如,我们可能知道某个消息必须保密传输,因为其中包含了客户的个人详细信息;我们希望捕获的是该消息应当保密的意图,而不是捕获需要使用 AES 128 位加密法对规范的 XML 数据集进行数据加密,同时使用 X.509
证书进行公用密钥加密这一意图,这主要是因为基本上不会有人知道其含义,更不用说能够以此抽象级别在模型中指定它(请参阅任务:确定安全性模式)。
下图展示了策略与服务模型元素的关联。请注意,虽然下面所确定的规范组件是我们感兴趣的主要领域,但策略信息也可以与除此之外的其他信息相关联。
关于对安全策略建模的更多信息,请参阅白皮书《面向服务的体系结构中的建模安全问题》。
|