The fact of the matter is that many inter- and intra-enterprise problem domains don't need service-level access (Web services) to applications; information exchange is good enough, if not desirable. Moreover, most organizations don't have application integration strategies. These organizations need to get their own houses under control first, determine their integration requirements, create a plan, and then select the correct approach to application integration and matching technology. Simply jumping to Web services without understanding the business requirements could be disastrous, or worse, could cause the organization to miss strategic opportunities.
Those organizations that require Web services have a need to access both information and application services that exist in local and remote information systems. Typically, these problem domains have the following characteristics:
* There are redundant application services that exist at two or more systems.
* There is a need to create a new application that satisfies a business need, but is also able to leverage aggregated application services from remote systems.
* The information residing within the source or target system is of significantly less value when decoupled from the services.
Dig Deeper on Service orchestration
Related Q&A from David Linthicum
David Linthicum explains what advanced business application programming (ABAP)/4 means. Continue Reading
David Linthicum defines Service Component Architecture (SCA) and Service Data Objects (SDO) and explains how to best build these components to enable... Continue Reading
David Linthicum explains how it is possible that Apache Tomcat is both a Web server and an application server. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.