Service-Oriented Architecture (SOA) is a hot topic among analysts, CIOs, and technology marketers, but the path from high-level architectural principles to programming a functioning, real-world service isn't always clear, especially since, in the end, you still need to create a clean user interface that's as flexible as the services it consumes.
Why SOA?
The concepts underlying SOA aren't a major divergence from standard design principles like abstraction, encapsulation, and reuse. To put it simply, SOA is a software architecture in which application functionality is encapsulated as independent services. These services are in many cases Web Services but can also be services derived from various technology types. Clients in different applications or business processes can then consume these services. More important, an SOA is designed to decouple the implementation of a software service from the interfaces that call that service. This lets clients of a service rely on a consistent interface regardless of the implementation technology of the service.
Instead of building big monolithic applications, developers can build more agile services that can be deployed and reused across an organization for different applications and processes. This allows for better reuse of software functionality, as well as for increased flexibility because developers can evolve the implementation of a service without necessarily affecting the clients of that service.
To this end, the main requirement of an SOA is that the interface to the services is decoupled from the implementation. This separation provides the central benefit to SOA, both from a programmatic perspective and a financial one. Existing systems, both legacy and modern, internal to the company and external, can be exposed and consumed as services, simplifying the task of development.
more...
--
h.o.s.a.m.r.e.d
Be OpeN Mind
--
http://hosamred.blogspot.com
No comments:
Post a Comment