Saturday, May 30, 2009

SOA!!!

Some Notes ( An abstract from Wiki ):

SOA depends on data and services that are described using some implementation of metadata that should meet the following two criteria:

  1. the metadata should come in a form that software systems can use to configure dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity
  2. the metadata should come in a form that system designers can understand and manage with a reasonable expenditure of cost and effort

SOA as an architecture relies on service-orientation as its fundamental design principle[6]. If a service presents a simple interface that abstracts away its underlying complexity, users can access independent services without knowledge of the service's platform implementation[7].

SOA relies on services exposing their functionality via interfaces that other applications and services can read to understand how to utilize those services.


Designers can implement SOA using a wide range of technologies, including SOAP, REST, RPC, DCOM, CORBA, Web Services or WCF(Microsoft's implementation of Webservice forms a part of WCF). SOA can be implemented using one or more of these protocols and, for example, might use a file-system mechanism to communicate data conforming to a defined interface-specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.


SOA enables the creation of applications that are built by combining loosely coupled and interoperable services. These services inter-operate based on a formal definition (or contract, e. g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service.


SOA-based systems can therefore function independently of development technologies and platforms (such as Java, .NET etc). Services written in C# running on .NET platforms and services written in Java running on Java EE platforms, for example, can both be consumed by a common composite application (or client). Applications running on either platform can also consume services running on the other as Web services that facilitates reuse. Managed environments can also wrap COBOL legacy systems and present them as software services. This has extended the useful life of many core legacy systems indefinitely, no matter what language they originally used.


Benefits:

- This style of architecture promotes reuse at the macro (service) level rather than micro (classes) level. It can also simplify interconnection to – and usage of – existing IT (legacy) assets.

- An indirect benefit of SOA is dramatically simplified testing. Services are autonomous, stateless, with fully documented interfaces, and separate from the cross-cutting concerns of the implementation.





No comments:

Post a Comment