SOA Solutions are most often hybrid solutions. Yes, they focus on a set of services; but they often do not soley rely on services for the realization of the functionality that needs to be in place for the business.
SOA solutions tend to rely on a combination of architectural styles and implementation and realization constructs to craft the underpinnings of an SOA solution. The SOMA method utilizes a combination of approaches to Service Identification. This includes 6 perspectives: top-down business process driven, business policy and rule-driven approaches, bottom up legacy integration, bottom-up legacy transformation (intrusive changes to rip out legacy modules and expose them via access points), information as a service typically used to consolidate multiple backend data stores and resolve inconsistencies in the access, rules and synchronization of the data stores and lastly the message-driven approach which seeks to integrate systems using a service interface.
Among the approaches above, although some are more established than others, information as a service affords a unique perspective in solving challenges relating to information. For example, data access interfaces and their underlying data access logic might need to be externalized judiciously if multiple channels are seeking to access and manipulate data from potentially multiple access points. The need for consolidation, synchronization and management of the data along with the need to have a coherent set of policies be applied to the data calls for the information service “entry point” to SOA.
Service-oriented modeling and architecture (SOMA) has become the industry de facto standard for SOA Methods. Introduced by IBM in Jan 2005, released recently as RUP/SOMA 2.4, it covers the identification, specification, realization and implementation of services, components, flows (processes), information and composition.
SOMA uses Information Analysis, Modeling and Planning during identification, an Information Specification during design and a number of artifacts during Realization and Implementation including considerations for Enterprise Information, Master Data Management, Conceptual, Logical and Physical Data Models.[Read More]
BPM, APIs & Service-oriented Architecture: Insights and Best Practices
From archive: February 2007 X
Ali_Arsanjani 120000D8QB 3,547 Views
[b]S[/b]ervice. Refers to how we use a service interface as a contract to decouple or loosely-couple a service provider from their prospective service consumers. Providers publish services, prefereably and increasingly in registries or service repositories (where they can be better governed). Consumers are looking for capabilities / functionality along with a set of non-functional requirements or service level agreements (SLA) that they want to be able to declaratively specify.
Services allow a business to expose its main operations to a well defined set of partners, clients and world at large, without giving direct access to its underlying IT systems, butthrough the surrogate of a web service.
The structure of an SOA, introduces services at an architectural level (a layer dedicated to services in the architecture).In object-oriented programming we tried to separate interfaces from implementation. IN SOA, we have carried that programming practice up to the architectural level and now have a layer dedicated to enforce that programming best-practice at a design level.
[b]O[/b]riented. The orientation is not object-orientation or component-orientation, but rather, service-orientation. This orientation is a tendency towards using services above the other options; not to exclude those options. Thus, when we apply the service litmus tests to the portfolio of candidate services we will end up with a smaller set of services and a number of other capabilities that still need to be implemented using some technology: legacy, package or custom, even if it is not a web services implementation.
[b]A[/b]rchitecture. SOA is a style of architecture and relies on the sound principles of software architecture, including the fact that it is merely one style, to be combined with other styles to form hybrid solutions to handle complex projects and real-world situations. Booch talks about bringing the 'A' back into SOA. I would say that as we overcome the hype of the acronym, we turn our attention to each letter and take action on what it signifies; including the A part for Architecture.[Read More]