SOA 에 관한 자료들을 찾아봤다. 흥미로운 주제가 아닐 수 없다.
이전에는 CODE, OBJECT, COMPONENT 등을 재사용(reuse)하는데에 관심을 쏟았다면,
이제는 더 나아가 Sevice 를 재사용하겠다니...
1990년대 후반(주:1996년 4월 가트너에서 표준 인터페이스 방식으로 시작)에 태어났지만,
요즘 SOA에 대한 관심이 늘어나고 있는 이유 중 하나는,
Web2.0 이 타 기업의 서비스를 이용하여 자신의 서비스를 이뤄내는 방식(주:MashUp)이 성공할 수 있음을 증명했기 때문이 아닐까 한다.
이슈가 되었고, 기업에서도 많은 관심을 가지고 추진을 하기 시작했지만..
아직 제대로 되지 않는 이유는 뭘까..
어떤 문제점이 있길래.. 무엇이 해결되어야 할까...
What is SOA?
SOA is a design for linking business and computational resources (principally organizations, applications and data) on demand to achieve the desired results for service consumers (which can be end users or other services). - wikipedia
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. - OASIS(주: Organization for the Advancement of Structured Information Standards)
Criticisms of SOA
Some criticisms of SOA are based on the assumption that SOA is just another term for Web Services. For example, some critics claim SOA results in the addition of XML layers introducing XML parsing and composition. In the absence of native or binary forms of Remote Procedure Call (RPC) applications could
run slower and require
more processing power, increasing costs. Most implementations do incur these overheads, but SOA can be implemented using technologies (for example, Java Business Integration (JBI)) which do not depend on remote procedure calls or translation through XML. However, there are emerging and open-source XML parsing technolgies, such as VTD-XML, and various XML-compatible binary formats (
http://vtd-xml.sf.net/persistence.html) that promise to significantly improve the SOA performance.
Stateful services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. The drawback of this constraint is that it could reduce the overall scalability of the service provider because it might need to remember the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult.
Another concern is that
WS-* standards and products are still evolving (e.g., transaction, security), and SOA can thus introduce new risks unless properly managed and estimated with additional budget and contingency for additional Proof of Concept work.
An informal survey by Network Computing placed SOA as the most despised buzzword (November 2006).
Some critics feel SOA is merely an obvious evolution of currently well-deployed architectures (open interfaces, etc).
A SOA being an architecture is the first stage of representing the system components that interconnect for the benefit of the business. At this level a SOA is just an evolution of an existing architecture and business functions. SOAs are normally associated with interconnecting back end transactional systems that are accessed via web services.
The real issue with any IT "architecture" is how one defines the information management model and operations around it that deal with information privacy, reflect the business's products and services, enable services to be delivered to the customers, allow for self care, preferences and entitlements and at the same time embrace identity management and agility. On this last point, system modification (agility) is a critical issue which is normally omitted from IT system design. Many systems, including SOAs, hard code the operations, goods and services of the organisation thus restricting their online service and business agility in the global market place.
Adopting SOAs is therefore just the first (diagrammatic) step in defining a real business system. The next step in the design process is the definition of a Service Delivery Platform (SDP) and its implementation. It is in the SDP design phase where one defines the business information models, identity management, products, content, devices, and the end user service characteristics, as well as how agile the system is so that it can deal with the evolution of the business and its customers.
SOA and web service protocols
* XML - a markup language for describing data in message payloads in a document format
* HTTP (or HTTPS) - request/response protocol between clients and servers used to transfer or convey information
* SOAP - a protocol for exchanging XML-based messages over a computer network, normally using HTTP
* XACML - a markup language for expressing access control rules and policies.
* Web Services Description Language (WSDL) - XML-based service description that describes the public interface, protocol bindings and message formats required to interact with a web service
* Universal Description, Discovery, and Integration (UDDI) - An XML-based registry to publish service descriptions (WSDL) and allow their discovery
Links
총명님
공부도 하고/깊이있는 것
Service Oriented Architecture,
SOA
yozmnAPI-TT.zip
올만의 tinyos 포스팅이군요.ㅎ
좋은 자료네요. 퍼갈께요.