Comparing Business Semantics and SOA
SOA is often used for modern applications integration, as a more progressive alternative to files exchange. Each application provides a set of web-services, having certain methods, that may be invoked by other applications to send of request some particular data.
SOA offers data exchange in realtime mode, which is really exciting. Also it helps to isolate a developer from other system's internal storage structure and logic (not clearly so, in fact, because a set of available methods, their in-out parameters are often dependent of data structure). Careful planning and implementing SOA services is critical for successful integration. And, yes, it implies custom programming.
SOA implementations are not free of certain drawbacks. For example, if some service is down, it may be very complex to reciver data consistency after downtime. Changing data structure in the underlying database may result web service failures, and necessity to repair it involving developer. In case if two or more applications may be a source of data of some type (for example, customers registration), web services implementation is facing uneasy problems. It is particularly hard to use web-services in complex environments, where there may be hundrds and thousands of services. This requires some monitoring and management software.
Business Semantics has serious advantages comparing to SOA:
- It does not require programming, usually. Instead of writing services, we only need to set up connectors (client modules), using web administration console.
- Business Semantics has a built-in recovery tools, which allows to restore data consistency after downtime.
- Failures are rare, due to independence of transferred data and information structure of particular applications.
- Business Semantics is a centralized structure, in contrast with web services conglomerates. We have a centralized monitoring and management tools.