首页> 外文会议>Proceedings of the 2nd workshop on Middleware for service oriented computing >Flexible matching and ranking of web service advertisements
【24h】

Flexible matching and ranking of web service advertisements

机译:Web服务广告的灵活匹配和排名

获取原文
获取原文并翻译 | 示例

摘要

Service Oriented Computing (SOC) is a computing paradigm broadly pushed by vendors, utilizing services to support the rapid development of distributed applications in heterogeneous environments. The visionary promise of SOC is a world of cooperating services being loosely coupled to flexibly create dynamic business processes and agile applications that may span organizations and computing platforms and can nevertheless adapt quickly and autonomously to changes of requirements or context. >Consequently, the subject of Service Oriented Computing is vast and enormously complex, spanning many concepts and technologies that find their origins in diverse disciplines like Workflow Management Systems, Component Based Computing, "classical" Web applications, and Enterprise Application Integration (EAI) including Message Oriented Middleware. In addition, there is a strong need to merge technology with an understanding of business processes and organizational structures, a combination of recognizing an enterprise's pain points and the potential solutions that can be applied to correct them. >Middleware, on the other hand, is defined by the ObjectWeb consortium as the software layer in a distributed computing system that lies between the operating system and the applications on each site of the system. Middleware is the enabling technology of system and enterprise application integration (EAI) and therefore it clearly and evidently plays a key role for SOC. >While the immediate need of middleware support for Service Oriented Architectures (SOA) is evident, current approaches and solutions mostly fall short by primarily providing support for the EAI aspect of SOC only and do not sufficiently address composition support, service management and monitoring. Moreover, quality properties (in particular dependability and security) need to be addressed not only by interfacing and communication standards, but also in terms of integrated middleware support. But what makes these issues so different in a SOA setting? Why - for instance - is traditional middleware support for transaction processing different to transaction processing in SOA, reflecting different types of atomicity needs? One answer lies in the administrative heterogeneity, the loose coupling between coarsegrained operations and long-running interactions, high dynamicity, and the required flexibility during run-time. Recently, massive-scale and mobility were added to the challenges for Middleware for SOC. >However, loose coupling is not always the best approach to solve a particular problem. In order to temporarily allow for a stronger (traditional) form of coupling (like group membership agreement or atomic transaction), the middleware also has to provide explicit and configurable means to change between different strengths of coupling and various communication paradigms. This will enable servicebased applications to take the best from both worlds by dynamically adjusting the interactions between the composed services. >Thehighly dynamic modularity and need for flexible integration of services (e.g. Web service implementations) may require new middleware architectures, protocols, and services. These considerations also lead to the question to what extent service-orientation at the middleware layer itself is beneficial (or not). Recently emerging "Middleware as service" offerings, from providers like Amazon or from the open source community, support this trend towards "infrastructure services" that can be purchased and consumed over the Internet. However, this model may not be suitable for all kinds of middleware functions, including those addressing dependability (availability, reliability, integrity, safety, maintainability). Providing end-to-end properties and addressing cross-cutting concerns in a crossorganizational SOA is a particular challenge and the limits and benefits thereof have still to be investigated.
机译:面向服务的计算(SOC)是供应商广泛推动的计算范例,利用服务来支持异构环境中分布式应用程序的快速开发。 SOC的远见卓识是协作服务的世界,这些服务松散地耦合在一起,可以灵活地创建动态业务流程和敏捷应用程序,这些应用程序和应用程序可能跨越组织和计算平台,但是仍然可以快速,自主地适应需求或上下文的变化。

因此,面向服务的计算主题是巨大而极其复杂的,涵盖了许多概念和技术,这些概念和技术起源于不同的学科,例如工作流管理系统,基于组件的计算,“经典” Web应用程序和企业应用程序集成(EAI),包括面向消息的中间件。此外,迫切需要将技术与对业务流程和组织结构的理解相结合,同时要认识到企业的痛点和可以用来纠正它们的潜在解决方案。

中间件,另一方面,由ObjectWeb联盟定义为分布式计算系统中的软件层,该层位于操作系统和系统每个站点上的应用程序之间。中间件是系统和企业应用程序集成(EAI)的使能技术,因此,它显然在SOC中扮演着重要角色。

显而易见,中间件对面向服务的体系结构(SOA)的迫切需求是显而易见的。 ,当前的方法和解决方案主要通过仅主要为SOC的EAI方面提供支持而不能充分解决组成支持,服务管理和监视问题。此外,不仅需要通过接口和通信标准来解决质量属性(尤其是可靠性和安全性),还需要在集成中间件支持方面解决质量属性。但是,什么使这些问题在SOA设置中如此不同?例如,为什么传统的中间件对事务处理的支持不同于SOA中的事务处理,从而反映了不同类型的原子性需求?一个答案是管理异质性,粗粒度操作与长时间运行的交互之间的松散耦合,高动态性以及运行时所需的灵活性。近年来,大规模和移动性已成为SOC中间件的挑战。

但是,松耦合并不总是解决特定问题的最佳方法。为了暂时允许更强(传统)的耦合形式(例如组成员身份协议或原子事务),中间件还必须提供显式且可配置的方式,以在耦合的不同强度和各种通信范式之间进行转换。通过动态调整组成的服务之间的交互,这将使基于服务的应用程序能够从两个方面中受益匪浅。

高度动态的模块化和对服务的灵活集成(例如Web服务实现)的需求可能需要新的中间件体系结构,协议和服务。这些考虑因素还引发了一个问题,即中间件层本身的服务导向在什么程度上是有益的(或没有益处)。来自诸如亚马逊之类的提供商或来自开源社区的最近出现的“中间件即服务”产品支持这种向“基础设施服务”发展的趋势,这种趋势可以通过Internet购买和消费。但是,该模型可能不适用于所有类型的中间件功能,包括那些解决可靠性(可用性,可靠性,完整性,安全性,可维护性)的功能。在跨组织的SOA中提供端到端的属性并解决跨领域的问题是一个特殊的挑战,其局限性和益处尚待研究。

著录项

相似文献

  • 外文文献
  • 中文文献
  • 专利
获取原文

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号