웹 서비스 리소스 프레임워크
Web Services Resource Framework |
WSRF(Web Services Resource Framework)는 OASIS가 발행한 웹 서비스 사양 제품군이다.주요 공헌자는 글로부스 얼라이언스와 IBM이다.
웹 서비스 자체는 명목상 상태 비저장이다. 즉, 호출 사이의 데이터는 보존하지 않는다.이것은 웹 서비스로 할 수 있는 것들을 제한한다.
WSRF 이전에는 웹 서비스 사양 제품군에서 원격 리소스와의 상태 저장 상호작용을 처리하는 방법을 명시적으로 정의한 표준은 없었다.이것은 웹 서비스가 주의깊을 수 없다는 것을 의미하지는 않는다.필요한 경우 웹 서비스는 데이터베이스에서 읽거나 쿠키 또는 WS-Session을 통해 세션 상태를 사용할 수 있다.
WSRF는 웹 서비스가 상태 저장 상호 작용을 구현하기 위해 사용할 수 있는 일련의 작업을 제공한다. 웹 서비스 클라이언트는 데이터를 저장하고 검색할 수 있는 리소스 서비스와 통신한다.클라이언트가 웹 서비스와 대화할 때, 그들은 요청 내에서 사용되어야 하는 특정 자원의 식별자를 포함하며, WS-Addressing Endpoint 참조에 캡슐화한다.이것은 간단한 URI 주소일 수도 있고, 또는 문제의 특정 자원을 식별하거나 심지어 완전히 설명하는 데 도움이 되는 복잡한 XML 내용일 수도 있다.
명시적 리소스 참조의 개념과 함께 리소스 속성을 가져오거나 설정하기 위한 표준화된 웹 서비스 작업 세트가 제공된다.이것들은 그 방법과 함께 개체의 구성원 변수를 가지는 것과 다소 유사한 방식으로 자원 상태를 읽고 쓰는 데 사용될 수 있다.이러한 모델의 주요 수혜자는 관리 툴로서, 자원에 대한 다른 지식이 없어도 자원을 열거하고 볼 수 있다.이것이 WSDM의 기본이다.
WSRF 관련 문제
WSRF는 논란이 없는 것은 아니다.가장 기본적인 것은 아키텍처: 상태와 운영이 있는 분산형 객체가 원격 자원을 가장 잘 나타내는 방법인가?분산 객체 패턴의 XML에 대한 거의 포트로 되어 있는데, 그 중 CORBA와 DCOM이 그 예다.WSRF 리소스는 여러 클라이언트가 리소스 참조를 가지고 있고 WSRF 규격 자체는 격리 및 가용성과 같은 우려를 다루지 않는 상태 저장 실체일 수 있으며, 이러한 문제를 다루기 위한 웹 서비스 규격의 복합적 성격을 지연시킨다.많은 WSRF 스택은 낮은 가용성으로, 일반적으로 C++ 및 Java에서는 (일부 지속성 메커니즘을 통해 데이터베이스에 바인딩된 스택을 제외하고) 로컬 개체 인스턴스에 WSRF 리소스 참조에서 1:1을 매핑함으로써 이러한 우려를 피하기 위해 나타난다.그러나 지속성, 클러스터링 및 리소스의 고가용성을 지원하는 WSRF의 구현(예: WebSphere Application Server)이 있다.
네트워크의 분산 객체 뷰로, WSRF는 또한 모든 것이 자원이지만, 제한적이고 표준화된 운영 세트를 통해 모든 조치가 활성화되는 네트워크의 REST 모델과 싸운다.어떤 면에서는, 두 모델이 모두 맨 끝에 상태 있는 자원을 가지고 있기 때문에, 순수 SOAP와 REST보다 더 가깝다.그러나, HTTP에 구현된 REST는 URL이 자원을 다루는데 필요한 모든 것이라고 가정한다. 즉, WS-Addressing ReferenceParameter의 복잡성은 필요하지 않다.재생 가능한 임대를 통해 원격 콘텐츠의 수명을 관리하자는 발상이 특히 비판의 대상이 되고 있다.REST 커뮤니티의 아키텍처와 관련된 다른 문제는 WS-Notification에서 설명한 콜백/알림이 방화벽을 통과하지 않는다는 것이다.REST 설계가 RSS 및 Atom(표준) 피드와 같이 폴링을 선호하는 이유다.WSRF는 SOAP가 REST 커뮤니티에 더 잘 받아들여지도록 하기 위해 아무것도 하지 않았다.
WSRF의 도입은 또한 WS-* 세계에 분열을 야기했다.2004년 2월 열린 그리드 서비스 인프라의 후속으로 글로벌 그리드 포럼 행사에서 처음으로 세계에 발표되었다.주류 WS-I 아키텍처와의 제한된 호환성은 영국 그리드 커뮤니티의 반대를 야기했다.[1]Global Grid Forum은 결국 개방형 그리드 서비스 아키텍처를 위해 WSRF 프로필에서 WSRF에 대한 의존성을 분리했다.WSDM은 WSDM에 기술된 관리 가능한 리소스와 상호작용하기 위한 수단으로 WSRF 프로토콜을 사용하기도 했다.그러나 WS-* 세계는 관리 가능한 자원을 기술하는 수단으로 WS-Transfer에 의존하는 Microsoft, Sun 및 기타 사람들이 WS-Management를 추구하는 웹 서비스 관리를 위한 단일 표준으로 통합되지 않았다.
구성 요소 사양
- WS-Resource는 WS-Resource를 자원과 자원에 접근할 수 있는 웹 서비스의 구성으로 정의한다.
- WS-ResourceProperties는 표준 방식으로 읽고 조작할 수 있는 WS-Resource와 일련의 입력된 값을 연결하기 위한 인터페이스를 설명한다.
- WS-ResourceLifetime은 WS-Resource의 수명을 관리하기 위한 인터페이스를 설명한다.
- WS-BaseFaults는 풍부한 SOAPFault를 위한 확장 가능한 메커니즘을 설명한다.
- WS-ServiceGroup은 WS-Resource 모음에서 작동하기 위한 인터페이스를 설명한다.
또한 WS-Notification은 어떤 일이 일어나고 있는지에 대한 정보를 다른 웹 서비스에 푸시하는 방법을 알려준다.
구현
WSRF 자원의 기본 속성 get/set 의미론 구현은 비교적 간단하다.SOAP 스택 자체가 SOAPFault 결함을 높이는 것을 선호하기 때문에 가장 어려운 문제는 규격에 따라 고장을 WSRF Base Faults로 반환하는 것일 수 있다.리소스 수명을 관리하는 것이 더 어렵지만, 이는 가장 테스트하기 어려운 WS-Notification과 마찬가지로 선택 사항이다.
- Globus Toolkit 버전 4는 WSRF의 Java 및 C 구현을 포함하고 있으며, 많은 다른 Globus 도구가 WSRF를 중심으로 재구성되었다.
- WebSphere Application Server 버전 6.1은 단순 WSRF 엔드포인트와 클러스터링된 고가용성 WSRF 엔드포인트를 모두 지원하는 WSRF 환경을 제공한다.
- 아파치 재단은 WSRF, WS-Notification, WSDM 규격의 자바 기반의 구현인 뮤즈 2.0 프로젝트를 가지고 있다.
- WSRF::Lite는 엔드포인트 참조의 주소 요소를 독점적으로 사용함으로써 URI를 통해 WS-리소스를 식별할 수 있도록 하는 퍼럴 기반 구현이다.또한 WSRF::Lite는 HTTP 동사를 WSRF 연산에 매핑하여 REST 아키텍처 스타일로 WS-Resources를 사용할 수 있도록 한다.
- WSRF.NET은 .NET는 버지니아 대학의 연구팀의 WSRF 사양에 관한 프로젝트를 기반으로 한다.
- 유니코어의 최신 버전 6.0은 WS-ResourceLifetime을 포함한 WSRF 1.2 표준의 자바 구현과 WS-Notification의 부분 구현을 기반으로 구축되었다.
참고 항목
참조
- ^ Malcolm Atkinson, David DeRoure, Alistair Dunlop, Geoffrey Fox, Peter Henderson, Tony Hey, Norman Paton, Steven Newhouse, Savas Parastatidis, Anne Trefethen, Paul Watson, and Jim Webber (2004-07-31). "Web Service Grids: An Evolutionary Approach" (PDF). UK e-Science Technical Report Series.
{{cite web}}: CS1 maint: 작성자 매개변수 사용(링크)
