อยากรู้เรื่อง สถาปัตยกรรม SOA
ตอบ: อยากรู้เรื่อง สถาปัตยกรรม SOA
Service Oriented Architecture(SOA) is an evolution of distributed computing and modular programming. SOA provides a modularity of logic that can be presented as a service for a client (client as in client-server architecture) and at the same time function as a client for other services. Relative to earlier attempts to promote software reuse via modularity of functions or classes, SOA's atomic level objects are 100 to 1,000 times larger, and are associated by an application designer or engineer using orchestration. In the process of orchestration, relatively large chucks of software functionality (services) are associated in a non-hierarchical arrangement (in contrast to a class's hierarchies) by a software engineer or process engineer using a special software tool which contains an exhaustive list of all of the services and their characteristics currently available.
Underlying and enabling all of this is metadata which is sufficient to describe not only the characteristics of these services, but the data that drives them. XML has been used extensively in SOA to create data which is wrapped in a nearly exhaustive description container. Analogously, the services themselves are typically described by WSDL, and communications protocols by SOAP. Whether these description languages are the best possible for the job, and whether they will remain the favorites going forward, is at present an open question. What is certain is that SOA is utterly dependent on data and services that are described using some implementation of metadata which meets two criteria. The metadata must be in a form which software systems can consume to dynamically configure to maintain coherence and integrity, and in a form which system designers can understand and use to manage that metadata.
The goal of SOA then is to allow fairly large chunks of functionality to be strung together to form ad-hoc applications which are built almost entirely from existing software services. The larger the chunks the fewer the interface points required to implement any given set of functionality. This is at odds with very large chunks of functionality which are not granular enough to be easily reused. Since each interface brings with it some amount of processing overhead, there is a performance consideration in choosing the granularity of services. The great promise of SOA though, is that in this world, the marginal cost of creating the nth application is zero, as all of the software required already exists to satisfy the requirements of other applications. Only orchestration is required to produce a new application.
SOA services are loosely coupled, in contrast, for example, to the functions a linker binds together to form an executable, a DLL, or an assembly. SOA services also run in "safe" wrappers such as the .NET environment, which manages memory allocation and reclamation, allows ad-hoc and late binding, and some degree of indeterminate data typing.
It is important to note that increasingly there are third party software companies which offer software services for a fee. Going forward, many SOA systems may be composed of services, only some of which were created in-house. This has the potential to spread costs over many customers, and customer uses, and promotes standardization both in and across industries. The travel industry in particular now has a well-defined and documented set of services, and the data they consume sufficient to allow any reasonably competent software engineer to create travel agency software using entirely off the shelf software services. Other industries, such as the finance industry, are also making significant progress in this direction.
There is no widely agreed upon definition of SOA other than its literal translation. It is an architecture that relies on service-orientation as its fundamental design principle. In an SOA environment independent services can be accessed without knowledge of their underlying platform implementation. These concepts can be applied to business, software and other types of producer/consumer systems.
มาจาก WIKIPEDIA สารานุกรมออนไลน์ ครับ
เริ่มต้นหาจาก กูเกิ้ลก่อน ซึ่งมีคำอธิบายหลายอย่าง แต่เห็นผู้ถามเจาะจงเรื่องการออกแบบ เลยคิดว่าคำอธิบายนี้นาจะตรง ซึ่งการออกแบบในที่นี้(สถาปัตยกรรม)ไม่ใช่เป็นเรื่องโครงสร้างอาคาร แต่เป็นแนวคิดในการออกแบบโปรแกรมการใช้งานครับ