My business processes need to tap into resources, and each activity requires the invocation of IT functionality; I want that functionality to be available in a flexible, replaceable way.
Top-down
Tool-based MDA
I want to define a model (business model) and then let my tools generate the detail for me.
Top-down
Wrap legacy
I have existing systems I have been investing heaviliy on, but they are not resilient. I want new functionality added quickly, but these systems are partitioned. They are silos where functions are locked into them.
Bottom-up
Componentize legacy
Decompose the monolithic legacy systems into modules using compiler-based tools.
Bottom-up
Data-driven
Provide access to information using services without having to expose schemas or implementation decisions on the provider side.
Data-focused
Message-driven
"Just want to have these systems integrate, communicate, over standard, non-proprietary protocols."
Service-Oriented Integration of Applications and Systems
Hard-coded (not a pattern, but a point in time state)
Point in time; low risk; low-changing, high-performance systems
Distributed; multi-point of access
Point-to-point exposure
Expose existing functionality rapidly; unlock value fast; access embedded functionality
Wrap a legacy function and make it callable through Web services
Service adaptor
Consumer needs access to functionality that is not service-enabled ( access to a legacy system through a service invocation, for example -- a Web service)
Access a service using its proxy if you do not have direct access to the service provider?s service description and are unable to directly invoke the service
Service proxy
Provides consumers with an SOA interface
Provide flexibility in the choice of the service provider
Remote service strategy
Provides flexibility in changing service providers based on quality of service or functionality considerations. This opens up possibilities in expediting mergers and acquisitions and flexible alteration of the provider when you consolidate application portfolios.
Eliminate redundant functionality; refactor and consolidate or, in some cases, replace existing systems
Single point of access
Provides one access point to a number of potential variants in functionality. A service strategy often requires a single point of access.
One project or LOB at a time, yet relies on others for some functions not yet exposed as services
Virtual provider
Non-existent providers; ramp up service critical mass
Single point of access
Service integrator
Routing, transformation
General enterprise integration approach
Enterprise service bus
Mediation; routing; transformation, policies, rules, events; inside the organization or between partners in ecosystem/value-net
The Nirvana of SOA; dynamic reconfiguration through context-aware services relying on business domain specific capabilities
Integrated service ecosystem
Provides dynamic configuration capabilities to a set of semantically interrelated industry specific business partners that leverage and recombine the ecosystem capabilities to provide greater value to themselves and the ecosystem as a whole
Often an initial challenge is the concrete determination of the value proposition for using SOA within a project, line of business, or organization. This has to do with flexibility and the ability to alter the actual service provider who implements a service once their quality of service dwindles or they fail to provide the required functionality. This flexibility, which is the primary value of SOA, is overcome by understanding the steps in achieving flexibility through a remote service strategy. There are two more challenges that we describe and overcome with the use of patterns presented here.
SOA is a journey of gradual, small transformations that increasingly decouple service descriptions from service implementations offered by multiple service providers. The solutions below are descriptions of how these issues have been recurrently solved and may serve as a pattern to help you on your next project. Like any other pattern, these must also be adapted to fit the context and the forces that shape your individual problem space: the tradeoffs and considerations of your project, whether organizational or technical, make a difference, and you can determine if you need to skip a step from one pattern to another or to partially implement the pattern
The purely object-oriented strategy pattern primarily relies on inheritance-based polymorphism to create a family of interchangeable algorithms that are swapped out based on context. Rather than have an object hierarchy, in an SOA context, we need to be able to change the service provider with minimal or no impact on the consumer?s perception of the service, thus varying the actual implementer of the service description. The implementer may, in most cases, be a provider of a remote unit of functionality, somewhere in the internal network or Internet. Therefore, for example, a service provider for a VerifyAddress service in an OrderEntry application may need to be changed because our quality of service needs have changed due to higher transaction volumes or security constraints. Or, the provider has decided to charge twice the amount for the same basic service, which we have relied on, in the past. Now, we would like to have the flexibility of changing service providers with IT and Business impunity, which means minimal changes to IT systems and no impact on the business or customer experience in their online shopping experience.
SOA 的一个抽象观点将它描qCؓ与业务过E结合在一L合成服务的部分分层架构??3 呈现了这U类型的架构?
服务和组Z间的关系是,企业U的lgQ大_度的企业或者业务线lgQ实现该服务q且负责提供它们的功能和l持它们的服务质量。通过l合q些公开的服务到合成的应用程序,可以支持业务过E流。综合的架构通过使用 Enterprise Service BusQESBQ支持这些服务、组件和程的\由、中介和转化。ؓ了服务质量和非功能性的需求,必须监视和管理已l部|的服务?/p>
]]>(?您的 SOA 合ƈ成三l的整合中心以提高速度和可靠?http://www.shnenglu.com/tanxiuguang123/archive/2006/04/24/6172.htmlTory Tory Mon, 24 Apr 2006 06:37:00 GMThttp://www.shnenglu.com/tanxiuguang123/archive/2006/04/24/6172.htmlhttp://www.shnenglu.com/tanxiuguang123/comments/6172.htmlhttp://www.shnenglu.com/tanxiuguang123/archive/2006/04/24/6172.html#Feedback0http://www.shnenglu.com/tanxiuguang123/comments/commentRss/6172.htmlhttp://www.shnenglu.com/tanxiuguang123/services/trackbacks/6172.html在本文中Q我谈论如何将 Web 服务及非 Web 服务的多?SOA 合ƈ成三l的整合中心来连接各U后端企业主机系l,包括Q?/p>
在三l中心中合ƈ SOA 需要预先规划来讄开发和׃n?SOA 的数目限制。您应当同业务分析师开发组交流有关各种合ƈ问题的信息。您发现解军_q题会使您开发三l中心的工作变得非常Ҏ。您可以开发在中心可复用和׃n?SOA。分析师发现解册问题会他们的设计和分析三维I间的中心的工作变得非常Ҏ。他们可以确定在不会D中心负L前提下哪个主机系l可以连接到中心?/p>
上面列出的所有集成方式在M企业中都有一定程度的体现Q尽在某些情况下它们可能是化的Q或者没有明地q行定义Q因而,在着手设计新的体pȝ构框架时Q您必须全面的考虑它们。特定的 IT 环境可能只有很少的数据源cdQ因此,消息集成可能会很单。同样地Q应用程序连接的作用域可能也很有限。虽然如此,如果希望框架能够随着企业的成长和变化成功地l得以保持,则框架中的集成功能仍然必ȝ服务提供Q而不是由特定的应用程序来完成?/p>