Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Build, protect and deploy apps across any platform and mobile device
Automate decision processes with a no-code business rules engine
A complete cloud platform for an app or your entire digital business
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
The use of a common data model in SOA has been recommended in definitive posts - from the viewpoints of integration and of governance. The common model architecture facilitates integration by providing a common ground for data transformation, and supports governance by bridging the business and implementation views of enterprise information. When a common model is properly used, these principles generally apply regardless of the runtime environment. But a common model supports several quite different styles of integration. We could look at those integration styles as a kind of spectrum, with extremes at each end and a blend in between.
One end of the integration style spectrum is represented by what I call the common interface style. OSS/J and MTOSI are examples of this style in the communications sector, and there are comparable examples in other sectors. The common interface style promotes a universal, standard interface between applications. It requires that all participating applications use the standard interface, reducing some common integration problems and costs. The level of adoption of standardized interfaces varies among domains and among application vendors. A common model can be used to implement adapters over non-compliant applications in order to conform to the standard interface. Although the common model and its mappings may resemble a hub and spoke model at design time, the runtime view of this style typically requires that the adapters be highly distributed.
In contrast to the common interface style, the other end of the spectrum is what I call the data integration layer style. Several OSS transformation projects are examples of this style. It starts with each application as-is, and adapts their existing interfaces to a set of "canonical" interfaces based on a common data model that supports mapping between all participating applications. It also adapts canonical interfaces back into application-specific ones. This allows process management infrastructure to intercept and redirect canonical requests, providing access to business process that would otherwise have been hidden in (and locked into) the "wiring" between applications. For this style, in contrast to the hub and spoke design view, the runtime view depends largely on the location of the mapping services, but it usually inserts process management between requesters and responders.
Other integration projects fall somewhere between the ends of the integration style spectrum, with a mix of adapters, canonical interfaces, and direct translation between applications. It will be interesting to see how these and other styles evolve, as SOA best practices and SOA-supporting technology improve.
View all posts from John Wilmes on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.