Articles
1. Introduction
Over the last four decades, software architectures have attempted to deal with increasing levels of software complexity. As the level of complexity continues to evolve, traditional architectures do not seem to be capable of dealing with the current problems. While traditional needs of IT organizations persist, the need to both respond quickly to new requirements of the business and continually reduce the IT cost, and the ability to absorb and integrate new business partners and new customer sets become more in demand. The industry has gone through multiple computing architectures designed to allow fully distributed processing, programming languages designed to run on any platform, greatly reducing implementation schedules, and a myriad of connectivity products designed to allow better and faster integration of applications. Service Oriented Architecture (SOA) is being advocated in the industry as the next evolutionary step in software architecture to help IT organizations meet their ever more complex set of challenges. [2]
The existence of Web services technologies has stimulated the discussion of Services Oriented Architecture (SOA), which has been advocated for more than a decade now, ever since CORBA extended the promise of integrating applications on disparate heterogeneous platforms. Problems of integrating those applications arise, often because of so many different (and non-CORBA-compliant) object models. Architects and engineers alike became so bogged down in solving technology problems, constantly in search for a more robust architecture that would allow simple, fast, and secure/seamless integration of systems and applications was lost. Meanwhile, the distributing computing model opens the way of cross-platform and cross-programming language interoperability. SOAP is a great distribution computing solution because it achieves interoperability through open standards at the specification level as well as the implementation level.
Meanwhile, basic business needs such as lowering costs, reducing cycle times, integration across the enterprise, B2B and B2C integration, greater ROI, creating an adaptive and responsive business model demands better solutions. "Point solutions" won't work as desired solutions for the lack of a consistent architectural framework within which applications can be rapidly developed, integrated, and reused. Thus an architectural framework must be developed to allow the assembly of components and services for the rapid, and even dynamic, delivery of solutions; an architectural view unconstrained by technology.
COMMENTS
To other viewers: this is a bit of a long read, but definitely worth it! Some very helpful info here.
��� Mark Adams, Fri, 17 Mar 2017 08:18:26 UTC