hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
이탈리아의 전쟁 범죄 제2차 세계 대전
이탈리아 유대인에 대한 억압은 1938년 베니토 무솔리니의 파시스트 정권에 의해 인종 분리 법률이 제정되면서 시작되었다. 이는 1943년 9월 독일군이 이탈리아를 점령하고 괴뢰 국가인 이탈리아 사회공화국 (RSI)을 수립하면서 바뀌었고, 즉시 그곳에서 발견된 유대인을 박해하고 추방하기 시작했다.
1943년 11월, RSI의 파시스트 당국은 베로나 의회에서 이탈리아 유대인을 "적국인"으로 선언하고 유대인에 대한 기소 및 체포에 적극적으로 참여하기 시작했다. 처음에는 이탈리아 항복 후 이탈리아 경찰은 독일 당국의 요청이 있을 때만 유대인 검거를 도왔다. 유대인을 외국인, 전시에는 적으로 선언한 베로나 선언과 함께 상황이 바뀌었다. 1943년 11월 30일 RSI 내무부 장관 귀도 부파리니 귀디가 발표한 경찰 명령 제5호는 이탈리아 경찰에게 유대인을 체포하고 그들의 재산을 몰수하도록 명령했다.
이탈리아에서 홀로코스트 기간 동안 체포된 모든 유대인 중 약 절반은 1944년 이탈리아 경찰에 의해 체포되었다.
1943년 9월 이전 이탈리아에 거주하던 약 44,500명의 유대인 중 7,680명은 홀로코스트 기간 동안 살해되었고(대부분 아우슈비츠에서), 거의 37,000명은 생존했다.
다음은 전쟁 행위에 연루된 이탈리아의 고위 군인 또는 기타 관리들의 목록이다. 여기에는 전쟁법의 중대한 위반으로 기소된 하급 장교도 포함된다. 특정 인물이 목록에 포함되었다고 해서 해당 인물이 사법 재판소에서 전쟁 범죄자로 인정되었다는 의미는 아니다. 관련 섹션에서 언급되었듯이, 영국 정부의 외교 활동과 후속적인 일반 사면으로 인해 법정에 회부된 사건은 극히 드물다.
목록에 포함되는 기준은 신뢰할 수 있는 문서화된 출처의 존재이다.
피에트로 말레티: 이탈리아의 에티오피아 점령 기간 중, 1937년 5월 18일에서 22일 사이에 말레티의 지휘를 받는 이탈리아 및 리비아 군대는 데브레 리바노스 수도원에서 수도승 297명과 수도원에서 봉사하는 평신도 23명, 그리고 수도원의 수호성인을 기념하기 위해 온 많은 순례자들을 포함하여 1700명에서 2100명의 사람들을 학살했다. 말레티는 1940년 전사했다.
마리오 로아타: 1941년–1943년, 류블랴나주의 22개월 동안 로아타는 전체 인구의 7.5%에 해당하는 25,000명의 사람들을 강제 이주시켰다. 유럽에서 가장 과감한 작전 중 하나였던 이 작전은 랍 섬, 고나르스, 모니고(트레비소), 레니치 단지아리, 키에사누오바 등지에 이탈리아 강제 수용소를 가득 채웠다. 생존자들은 전쟁 후 이탈리아 국가로부터 아무런 보상도 받지 못했다. 그는 류블랴나 주 주둔 제2이탈리아군 사령관으로서 억류 외에도 즉결처형, 인질 잡기, 주택과 마을 불태우기를 명령했으며, 이로 인해 전쟁 후 유고슬라비아 정부는 그를 전쟁 범죄로 인도하려 했으나 실패했다. 그는 "이에는 이가 아니라, 이에는 머리다" ("Non dente per dente, ma testa per dente")라고 말한 것으로 인용되었고, 로보티는 1942년에 "충분히 죽이지 못한다!" ("Non si ammazza abbastanza!")라고 말한 것으로 인용되었다. "1942년 3월 1일, 그는 (로아타) '3C'라는 제목의 팜플렛을 그의 지휘관들에게 배포했는데, 이는 군사 개혁과 즉결 처형, 인질 잡기, 보복, 억류, 주택 및 마을 불태우기를 통해 슬라브 인구를 침묵시키기 위한 가혹한 조치를 명시하고 있었다. 그의 계산에 따르면, 군사적 필요성은 선택의 여지가 없었고, 법은 형식적인 준수만을 요구했다. 로아타의 무자비한 파르티잔 봉기 진압은 세르비아인과 유대인 모두를 이탈리아 동맹국인 독일과 크로아티아의 박해로부터 구한 사실로 완화되지 않았다. 그의 감시 아래, 제2군의 유고슬라비아 인구에 대한 폭력 기록은 독일군에 필적했다. 민간인에 대한 선전포고와 다름없는 로아타의 '3C' 팜플렛은 그를 전쟁 범죄에 연루시켰다." 로아타의 병사 중 한 명은 1942년 7월 1일 집에 편지를 써서 "우리는 무고한 사람들을 가리지 않고 위에서 아래까지 모든 것을 파괴했습니다. 우리는 매일 밤 온 가족을 때려죽이거나 총살했습니다"라고 썼다. 무솔리니 정부의 외무장관 갈레아초 치아노가 이탈리아군이 모든 슬로베니아인을 죽이기를 원했던 파시스트 당 사무총장과의 회의를 묘사하며 언급했듯이: (...) 나는 그들(슬로베니아인)이 백만 명에 달한다고 감히 말했습니다. 그는 단호하게 답했습니다. 상관없습니다. 우리는 아스카리 (잔혹함으로 악명 높은 에리트레아 보조 병력)를 본받아 그들을 전멸시켜야 합니다.
이탈로 시모니티는 이탈리아 사회공화국의 제4 몬테로사 알프스 사단 대위로, 1945년 미국인 포로 처형에 연루되어 처형되었다. 그는 미군에 의해 처형된 유일한 이탈리아 전범이었다. 시모니티의 부하 베네데토 필론은 종신형을 선고받았다. 그는 나중에 이탈리아 구금 시설로 이송되었지만, 1951년 1월 법무장관 아틸리오 피치오니의 사면으로 석방되었다.
유고슬라비아와 그리스가 전쟁 범죄로 수배한 인물들의 CROWCASS 목록에는 여러 이탈리아인들의 이름이 올라 있다.
이탈리아의 전쟁 범죄 출처
H. 제임스 버그윈 (2004): "General Roatta's war against the partisans in Yugoslavia: 1942", Journal of Modern Italian Studies, 9월 vol. 9, no. 3, pp. 314–329(16) doi:10.1080/1354571042000254746
아파치 코쿤
아파치 코쿤(Apache Cocoon)은 보통 코쿤으로 약칭되며, 파이프, 관심사 분리, 컴포넌트 기반 웹 개발 개념을 중심으로 구축된 웹 프레임워크이다. 이 프레임워크는 XML 및 XSLT 퍼블리싱에 중점을 두며, 자바 프로그래밍 언어를 사용하여 구축되었다. 코쿤의 XML 사용은 HTML 및 PDF와 같은 퍼블리싱 형식의 호환성을 향상시키기 위한 것이다. 콘텐츠 관리 시스템인 Apache Lenya와 Daisy는 이 프레임워크 위에 구축되었다. 코쿤은 또한 데이터 웨어하우스 ETL 도구 또는 시스템 간에 데이터를 전송하는 미들웨어로도 일반적으로 사용된다.
아파치 코쿤 사이트맵
아파치 코쿤은 사이트맵을 사용하여 사용자가 코쿤 소프트웨어의 다양한 구성 요소를 제어할 수 있도록 하며, 코쿤이 파이프라인이라고 부르는 클라이언트-서버 상호 작용을 정의한다.
아파치 코쿤 구성 요소
코쿤 내의 구성 요소들은 기능별로 그룹화된다.
매처는 URL 또는 쿠키와 같은 사용자 요청을 와일드카드 또는 정규 표현식 패턴과 일치시키는 데 사용된다. 각 사용자 요청은 일치하는 것이 발견될 때까지 사이트맵의 매처에 대해 테스트된다. 특정 요청에 대한 응답은 매처 내에서 지정된다.
제너레이터는 추가 처리를 위한 데이터 스트림을 생성한다. 이 스트림은 기존 XML 문서에서 생성될 수 있으며, 디렉터리 구조나 이미지 데이터와 같이 서버의 무언가를 나타내기 위해 처음부터 XML을 생성할 수 있는 제너레이터도 있다.
제너레이터의 한 유형은 XML 서버 페이지(XSP)이며, 요청 시 동적 콘텐츠를 생성하는 방법을 지정하는 태그 기반 지시문을 포함하는 XML 문서이다. 코쿤 처리 시, 이 지시문들은 생성된 콘텐츠로 대체되어 결과적으로 증강된 XML 문서가 추가 처리(일반적으로 XSLT 변환)될 수 있도록 한다. XSP는 코쿤 생산자, 일반적으로 자바 클래스로 변환되지만, 자바 기반 프로세서가 존재하는 모든 스크립팅 언어도 사용될 수 있다.
아파치 코쿤 구성 요소
지시문은 내장("XSP") 또는 사용자 정의 처리 태그일 수 있으며, 둘 다 로직 시트에 정의된다. 태그는 태그(XML 노드로 표현됨)가 다른 XML 노드 또는 자바와 같은 절차적 코드로 변환되는 방법을 설명하는 XSLT 템플릿을 사용하여 정의된다. 태그는 절차적 논리를 포함하고, 표현식을 대체하며, 웹 서버 환경에서 정보를 검색하고, 기타 작업을 수행하는 데 사용된다.
XSP는 최신 코쿤 릴리스에서는 더 이상 사용되지 않는다.
트랜스포머는 데이터 스트림을 가져와 어떤 방식으로든 변경한다. 가장 일반적인 변환은 XSLT를 사용하여 하나의 XML 형식을 다른 형식으로 변경하는 것이다. 그러나 다른 형태의 데이터(SQL 명령 등)를 가져오는 트랜스포머도 있다.
시리얼라이저는 XML 이벤트 스트림을 클라이언트에 반환될 수 있는 바이트 시퀀스(예: HTML)로 변환한다. 일부 시리얼라이저는 HTML, XHTML, PDF, RTF, SVG, WML 및 플레인 텍스트 등 다양한 형식으로 데이터를 전송할 수 있다.
아파치 코쿤 구성 요소
셀렉터는 Switch 문과 동일한 기능을 제공한다. 요청의 특정 요소를 선택하고 사용할 올바른 파이프라인 부분을 선택할 수 있다.
뷰는 주로 테스트에 사용된다. 뷰는 파이프라인의 종료 지점이다. 이 시점까지 생성된 XML-스트림을 출력할 수 있다. 따라서 애플리케이션이 올바르게 작동하는지 확인할 수 있다.
콘텐츠를 파싱하지 않고(XML 처리 없음) 게시한다. 이미지 등에 사용된다.
액션은 일부 비즈니스 로직을 실행하거나 새로운 콘텐츠 생성을 관리하는 자바 클래스이다.
아파치 코쿤 파이프라인
파이프라인은 주어진 요청에 대해 다양한 코쿤 구성 요소가 상호 작용하여 응답을 생성하는 방법을 지정하는 데 사용된다. 일반적인 파이프라인은 제너레이터, 그 뒤에 0개 이상의 트랜스포머, 마지막으로 시리얼라이저로 구성된다.
아파치 태피스트리
아파치 태피스트리(Apache Tapestry)는 오픈 소스 컴포넌트 지향 자바 웹 프레임워크로 개념적으로는 자바서버 페이스와 아파치 위켓과 유사하다. 태피스트리는 하워드 루이스 십이 만들었으며, 2006년 아파치 소프트웨어 재단에 의해 최상위 프로젝트로 채택되었다.
태피스트리는 단순성, 사용 편의성 및 개발자 생산성을 강조한다. 거의 모든 XML 구성을 제거하여 설정보다 관례 패러다임을 따른다. 태피스트리는 웹 페이지의 각 사용자 인터페이스 컴포넌트(객체)와 해당 자바 클래스 간의 강력한 바인딩을 통해 웹 개발에 모듈식 접근 방식을 사용한다. 이 컴포넌트 기반 아키텍처는 웹오브젝트에서 많은 아이디어를 차용했다.
아파치 태피스트리 주요 기능
라이브 클래스 리로딩
태피스트리는 자바 페이지 클래스, 컴포넌트 클래스, 서비스 구현 클래스, HTML 템플릿 및 컴포넌트 속성 파일의 변경 사항을 파일 시스템에서 모니터링하고, 재시작 없이 실행 중인 애플리케이션에 변경 사항을 핫스왑한다. 이는 코드 저장-보기 피드백 주기를 매우 짧게 제공하여 개발자 생산성을 크게 향상시킨다고 주장된다.
컴포넌트 기반
페이지는 작은 중첩 가능한 컴포넌트로 구성될 수 있으며, 각 컴포넌트는 템플릿과 컴포넌트 클래스를 가진다. 사용자 지정 컴포넌트는 구성하기에 사소한 것으로 알려져 있다.
설정보다 관례
태피스트리는 애플리케이션을 구성하기 위해 XML 대신 명명 규칙과 어노테이션을 사용한다.
아파치 태피스트리 주요 기능
HTTPSession의 절약적 사용
HTTPSession을 최소한으로 사용하여, 태피스트리는 클러스터링된 세션 복제 환경에서 고효율적으로 설계되었다.
Post/Redirect/Get
대부분의 양식 제출은 Post/Redirect/Get (PRG) 패턴을 따르며, 이는 다중 양식 제출 오류를 줄이고 URL을 더 친근하게 만들고 북마크 가능하게 하며, 브라우저의 뒤로가기 및 새로고침 버튼이 정상적으로 작동하도록 한다.
제어의 역전(IoC)
태피스트리는 구글 주스와 유사하지만, 태피스트리 동작의 거의 모든 측면을 구성하고 교체할 수 있도록 설계된 경량 제어의 역전 계층 위에 구축되었다.
아파치 태피스트리 헬로 월드 예제
최소한의 템플릿 태피스트리 애플리케이션은 세 개의 파일만 필요하다:
HelloWorld.tml
/helloworld 페이지용 (X)HTML 템플릿. 태피스트리 템플릿은 잘 형성된 (X)HTML 마크업을 포함할 수 있다.
HelloWorld.java
템플릿과 연결된 페이지 클래스. 여기서는 템플릿이 접근할 수 있는 *username* 속성만 제공한다.
web.xml
태피스트리를 서블릿 필터로 설치하는 서블릿 애플리케이션 배포 설명자.
아파치 태피스트리 클래스 변환
태피스트리는 런타임에 페이지 및 컴포넌트 클래스를 변환하기 위해 바이트코드 조작을 사용한다. 이 접근 방식은 페이지 및 컴포넌트 클래스를 간단한 POJO로 작성할 수 있게 하며, 몇 가지 명명 규칙과 어노테이션이 클래스 로드 시간에 상당한 추가 동작을 유발할 수 있다. 태피스트리 버전 5.0, 5.1 및 5.2는 자바시스트 바이트코드 조작 라이브러리를 사용했다. 이후 버전에서는 자바시스트를 ObjectWeb ASM을 기반으로 하는 Plastic이라는 새로운 바이트코드 조작 계층으로 대체했다.
아파치 태피스트리 클라이언트 측 지원
태피스트리 5 버전 5.3까지는 프로토타입과 script.aculo.us 자바스크립트 프레임워크를 태피스트리 특정 라이브러리와 함께 번들로 제공하여 Ajax 작업을 일급 시민으로 지원했다. 프로토타입/스크립타큘러스 대신 또는 추가로 jQuery를 통합하기 위한 서드 파티 모듈을 사용할 수 있다.
버전 5.4부터 태피스트리는 기본 제공 컴포넌트의 프로토타입 의존성을 제거하는 새로운 자바스크립트 계층을 포함하여, jQuery 또는 다른 자바스크립트 프레임워크를 플러그인할 수 있게 한다.
버전 5.4는 또한 RequireJS 모듈 로딩 시스템을 사용하는 자바스크립트 모듈 지원을 도입했다.
아파치 태피스트리 핵심 원칙
태피스트리 프로젝트 문서는 2008년 버전 5부터 모든 태피스트리 개발 결정을 지배하는 네 가지 "원칙"을 언급한다:
아파치 태피스트리 비판
태피스트리는 주요 버전 간의 하위 호환성이 부족하다는 비판을 받아왔으며, 특히 버전 4에서 버전 5로의 전환에서 기존 애플리케이션을 위한 깔끔한 마이그레이션 경로가 없었다는 점이 지적되었다. 프로젝트 팀원들은 이를 과거 태피스트리 사용자들에게 큰 문제였음을 인정했으며, 하위 호환성은 태피스트리가 앞으로 나아갈 주요 설계 목표가 되었다. 버전 5 개발 초기부터 하위 호환성은 태피스트리의 네 가지 새로운 "핵심 원칙" 중 하나로T 지정되었고, 나머지 세 가지 중 두 가지는 하위 호환성을 희생하지 않고 프레임워크의 진화를 가능하게 하기 위함이었다. 프로젝트 팀원들은 5.0 이후의 모든 태피스트리 릴리스가 높은 하위 호환성을 가졌다고 주장한다.
태피스트리 5에 대한 초기 비판은 문서 부족을 언급하기도 했다. 프로젝트 팀원들은 이제 완전히 개정되고 업데이트된 사용자 가이드 및 기타 문서를 통해 이러한 단점이 크게 해소되었다고 주장한다.
아파치 태피스트리 비판
버전 5.0부터 태피스트리는 프로토타입 및 스크립타큘러스 자바스크립트 라이브러리를 번들로 제공했다. 하워드 루이스 십에 따르면, 2008-2009년경에는 이들이 합리적인 선택이었다. 그러나 이후 프로토타입의 인기는 하락했고, jQuery의 인기는 급증했다. 이에 대응하여 태피스트리 커뮤니티는 프로토타입 외에 또는 대신 jQuery를 사용할 수 있도록 하는 모듈을 개발했다. 한편, 현재 버전의 태피스트리인 5.4는 프로토타입에 대한 의존성을 완전히 제거하고, jQuery 또는 프로토타입(또는 잠재적으로 다른 자바스크립트 프레임워크)을 플러그인할 수 있는 호환성 계층으로 대체했다.
아파치 태피스트리 다른 프레임워크와의 관계
하워드 루이스 십에 따르면, 태피스트리는 당시에 오브젝티브-C로 작성되었고 비공개 소스였던 웹오브젝트에서 발견된 일반적인 개념과 접근 방식을 자바로 구현하려는 시도로 처음 고안되었다.
아파치 위켓의 창시자 조나단 로크에 따르면, 아파치 위켓은 초기 버전의 태피스트리의 복잡성에 대한 대응으로 개발되었다고 한다.
자바서버 페이스의 기본 뷰 기술인 페이스릿은 "산업 표준인 자바서버 페이스를 기반으로 하는 태피스트리 같은 프레임워크"의 필요성을 채우려는 시도로, 초기 버전의 태피스트리에서 영감을 받았다고 알려져 있다.
크루티 전투
틀:Campaignbox Ukrainian-Soviet War
크루티 전투(우크라이나어: Бій під Крутами 비이 피드 크루타미[*])는 1918년 1월 29일 또는 30일에 우크라이나 키이우 북동쪽 약 130 킬로미터 (81 mi) 떨어진 체르니히우주 니진 라욘 팜야트네 마을 (당시에는 체르니히우 주의 니진 포비트의 일부) 근처 크루티 기차역에서 일어났다.
크루티 전투 전투 서열
우크라이나군 (D. 노센코)
러시아군 (미하일 무라비요프)
크루티 전투 전투
미하일 무라비요프가 지휘하는 약 4,000명의 볼셰비키군이 키이우로 진격하자, F. 팀첸코 대위가 처음 지휘하던 바흐마치 수비대의 작은 우크라이나 부대 400명 (그 중 약 300명은 학생)은 바흐마치에서 니진으로 향하는 중간의 작은 철도역인 크루티로 후퇴했다. 이 작은 부대는 주로 시치 소총수 학생 대대(쿠린), 흐멜니츠키 사관생도 학교의 부대, 그리고 자유 코자크 중대로 구성되었다.
공격 직전 팀첸코는 D. 노센코로 교체되었다. 팀첸코는 현지에 주둔하던 셰브첸코 연대(800명)를 우크라이나 편으로 끌어들이기 위해 니진으로 떠났다. 1918년 1월 30일, 셰브첸코 연대가 소비에트 정권 편에 서면서 크루티의 우크라이나 수비대는 서둘러 철수할 수밖에 없었다. 5시간 동안 지속된 전투에서 400명 중 절반 이상이 사망했다. 소비에트 역사학에서는 이 전투를 1918년 1월 29일로 잘못 기록했으며 플리스키 (역)에서의 충돌과 혼동되었다.
크루티 전투 전투
크루티 수비대를 지원하기 위해 서둘러 오던 시몬 페틀류라의 하이다마카 키시(300명)는 다르니차 철도 노동자들의 사보타주로 지연되어 근처 보브리크 역에서 멈췄다. 그들은 결국 같은 날 발생한 볼셰비키 아르세날 봉기로 인해 키이우로 돌아갔다.
1918년 3월 중앙 라다가 수도로 돌아온 후, 학생들 중 18명은 키이우 중심부의 아스콜트 무덤에 재안장되었다. 장례식에서 당시 우크라이나 인민공화국의 대통령이던 미하일로 흐루셰우스키는 전투에 참전한 400명의 학생 모두를 영웅이라고 칭했다. 시인 파블로 티치나는 학생들의 영웅적인 죽음에 대해 "30인에게 바치는 추모"를 썼다.
우크라이나 인민 공화국이 붕괴된 후, 학생들의 시신은 키이우의 루키야니우스케 묘지로 옮겨졌다.
크루티 전투 우크라이나 유산
이 전투의 진실은 소비에트 정부에 의해 숨겨졌다. 최근에야 크루티 전투 80주년을 기념하기 위해 아스콜트 무덤에 기념비가 세워졌고, 기념 흐리우냐 동전이 발행되었다. 2006년에는 역사적인 전투 장소에 크루티 영웅 기념비가 세워졌다. 이 전투는 매년 1월 29일 또는 그 무렵에 기념된다.
우크라이나 청년들은 러시아 니콜라이 무라비요프 중장의 볼셰비키군이 키이우로 진격하는 것을 막기 위해 목숨을 바쳤습니다.— 전 대통령 빅토르 유셴코가 전투 91주년에 학생들을 묘사하며
젊은이들은 스파르타 병사들처럼 외세 침략자들과의 싸움에서 조국을 위해 죽었습니다. 그것은 그들의 희생과 조국에 대한 이타적인 사랑의 모범이었습니다.

크루티 영웅들의 기념일은 우리 조국보다 자신들의 생명을 더 사랑했던 사람들을 기리는 날일 뿐만 아니라, 현대 정치인들에게 조국과 국민의 운명에 대한 그들의 책임을 다시금 상기시키는 날이기도 합니다.— 전 총리 율리야 티모셴코가 전투를 묘사하며
크루티 전투 우크라이나 유산
크루티 근처에서 키이우 사관생도와 학생들은 우크라이나 정치 국가의 선구자가 되었습니다. 그들은 다른 민족적 뿌리를 가졌음에도 불구하고, 우리 우크라이나 국가를 위해 하나 되어 싸웠습니다. 우크라이나 인민 공화국의 건국이 우크라이나 국가의 기반이 되었듯이, 크루티 전사들의 영웅주의는 지난 20세기 우크라이나인들의 자유를 위한 해방 투쟁의 시작이자 상징이 되었습니다.
— 전 대통령 빅토르 유셴코가 전투 91주년에
2022년 3월 1일, 우크라이나군은 2022년 러시아의 우크라이나 침공 당시 러시아군의 공격으로부터 크루티 주변 지역을 성공적으로 방어했으며, 러시아군은 약 200명의 병력을 잃었다. 전투에 앞서 러시아 군인들은 크루티 영웅 기념비 근처에서 사진을 찍고 기념비에 총격을 가했다.
아스콜트 묘지에
그들은 묻혔네,
30명의 순교자-우크라이나인들,
영광스러운 젊은이들...

아스콜트 묘지에
우크라이나의 꽃! —
피 묻은 길을 따라
우리가 세상으로 나아갈 길.

누가 감히 일어나려 했는가
배신자의 손?
해는 피어나고, 바람은 불고
그리고 드니프로강은...

누구를 향해 카인이 죄를 지었는가?
오, 주여, 그들을 벌하소서!
그들이 사랑했던 모든 것 위에
그것은 그들의 사랑하는 땅이었네.

그들은 새 언약에서 죽었네
성도들의 영광과 함께.
아스콜트 묘지에
그들은 묻혔네.— 파블로 티치나, 1918 (자유 번역)
아파치 위켓
아파치 위켓(Apache Wicket)은 보통 위켓이라고 불리며, 자바 프로그래밍 언어를 위한 컴포넌트 기반 웹 프레임워크로, 개념적으로 자카르타 페이스 및 태피스트리와 유사하다. 이 프레임워크는 조너선 로크가 2004년 4월에 처음 작성했다. 버전 1.0은 2005년 6월에 출시되었다. 2007년 6월에는 아파치 최상위 프로젝트로 승격되었다.
아파치 위켓 원리
기존의 모델-뷰-컨트롤러 (MVC) 프레임워크는 전체 요청과 전체 페이지 단위로 작동한다. 각 요청 주기에서 들어오는 요청은 컨트롤러 객체의 메서드에 매핑되며, 이 메서드는 일반적으로 모델에서 데이터를 가져와 특수 템플릿 마크업으로 작성된 뷰를 채움으로써 나가는 응답 전체를 생성한다. 이는 애플리케이션의 흐름을 단순하고 명확하게 유지하지만, 컨트롤러에서의 코드 재사용을 어렵게 만들 수 있다.
반면, 위켓은 상태 유지 GUI 프레임워크(예: 스윙)를 면밀히 본떠 만들어졌다. 위켓 애플리케이션은 컴포넌트 트리로 구성되어 있으며, 스윙 컴포넌트가 마우스 및 키 입력 이벤트에 반응하는 것과 동일한 방식으로 리스너 델리게이트를 사용하여 링크 및 폼에 대한 HTTP 요청에 반응한다. 위켓은 컴포넌트 기반 프레임워크로 분류된다.
아파치 위켓 설계
위켓은 템플릿을 위해 순수 XHTML을 사용한다(이는 프레젠테이션과 비즈니스 로직의 명확한 분리를 강제하며, 템플릿을 일반적인 위지위그 디자인 도구로 편집할 수 있게 한다). 각 컴포넌트는 XHTML의 이름 지정된 요소에 바인딩되며, 최종 출력에서 해당 요소를 렌더링하는 역할을 담당한다. 페이지는 단순히 최상위 컨테이너 컴포넌트이며, 정확히 하나의 XHTML 템플릿과 짝을 이룬다. 특별한 태그를 사용하여 개별 컴포넌트 그룹을 패널이라는 단일 컴포넌트로 추상화할 수 있으며, 이 패널은 해당 페이지, 다른 페이지 또는 다른 패널에서도 통째로 재사용할 수 있다.
각 컴포넌트는 자체 모델에 의해 지원되며, 이는 컴포넌트의 상태를 나타낸다. 프레임워크는 컴포넌트가 모델과 어떻게 상호 작용하는지 알지 못하며, 모델은 요청 간에 자동으로 직렬화되고 지속되는 불투명한 객체로 처리된다. 그러나 더 복잡한 모델은 분리 가능하게 만들어져 각 요청 주기 시작 및 끝에서 자체 저장 및 복원을 처리하는 훅을 제공할 수 있다. 위켓은 특정 객체 지속성 또는 ORM 계층을 강제하지 않으므로, 애플리케이션은 종종 하이버네이트 객체, EJB 또는 POJO의 조합을 모델로 사용한다.
아파치 위켓 설계
위켓에서는 모든 서버 측 상태가 자동으로 관리된다. HttpSession 객체나 유사한 래퍼를 직접 사용하여 상태를 저장해서는 안 된다. 대신 상태는 컴포넌트와 연결된다. 각 서버 측 페이지 컴포넌트는 상태 유지 컴포넌트의 중첩된 계층 구조를 가지며, 각 컴포넌트의 모델은 결국 POJO(Plain Old Java Object)이다.
위켓은 단순함을 지향한다. 위켓에는 배워야 할 설정 파일이 없다. 위켓은 컴포넌트 구조에 대한 일관된 접근 방식을 가진 단순한 클래스 라이브러리이다.
아파치 위켓 예시
네 개의 파일로 구성된 헬로 월드 위켓 애플리케이션:
HelloWorld.html
XHTML 템플릿.
HelloWorld.java
템플릿에 바인딩될 페이지 컴포넌트. 이 컴포넌트는 다시 자식 컴포넌트(이름이 "message"인 Label 컴포넌트)를 바인딩한다.
HelloWorldApplication.java
홈페이지 요청을 HelloWorld 페이지 컴포넌트로 라우팅하는 주 애플리케이션 클래스.
web.xml
서블릿 애플리케이션 배포 기술자, 위켓을 서블릿의 기본 핸들러로 설치하고 시작 시 HelloWorldApplication이 인스턴스화되도록 구성한다.
아파치 위켓 구성요소
폼, 링크, 리피터 등과 같은 기본 구성요소가 내장되어 있다.
FuelPHP
FuelPHP는 PHP로 작성된 오픈 소스 웹 애플리케이션 프레임워크로, HMVC 패턴을 구현한다.
FuelPHP 역사
FuelPHP 프로젝트는 2010년 10월에 시작되었으며, 주요 기여자로는 해로 버턴, 젤머르 슈뢰더, 댄 호리건, 필립 스터전, 프랭크 드 용어가 있다. 2013년 11월에 스티브 웨스트가 개발팀에 합류했다. 필립 스터전과 댄 호리건은 코드이그나이터 프레임워크에 기여한 바 있다.
FuelPHP의 첫 번째 버전(FuelPHP 1.0)은 Fuel이라는 깃허브 저장소에서 개발되었다. 두 번째 버전(FuelPHP 2.0) 개발을 위해 FuelPHP라는 또 다른 깃허브 저장소가 생성되었다.
FuelPHP 프로젝트 지침
프로젝트 지침은 다른 프레임워크의 최고의 아이디어를 기반으로 프레임워크를 구축하는 것이다. 프레임워크는 강력한 기능을 제공해야 하고, 작업하기 쉬워야 하며, 커뮤니티 개발자의 지향을 고려한 가벼운 코드베이스를 가져야 한다.
자이언 캐니언
자이언 협곡(Zion Canyon, 리틀 자이언, 무쿤투윕, 무-룬'-투-윕, 스트레이트 캐년이라고도 불리며, 위프는 파이우트어로 협곡을 뜻한다)은 미국 유타주 남서부에 위치한 깊고 좁은 협곡으로, 노스포크 버진강이 침식하여 형성되었다. 거의 전체 협곡이 자이언 국립공원 서부에 위치한다.
자이언 캐니언 설명
협곡의 시작은 보통 거의 3,000 피트 (910 m) 깊이의 수직 벽으로 둘러싸인 자연 원형극장인 시나와바 사원으로 정의된다. 그러나 협곡은 훨씬 더 상류에서 시작하여 내로우를 거쳐 약 16 마일 (26 km) 남쪽으로 뻗어 시나와바 사원에 도달한다. 이 사원에서는 봄철 해빙기나 폭우 후 노스포크의 계절 지류가 높은 폭포를 이루며 떨어진다. 이후 협곡은 국립공원을 가로질러 남서쪽으로 뻗어 나가며, 일부 구간은 2,000 피트 (610 m) 깊이에 이른다. 협곡 가장자리는 사막이 지배적이지만, 협곡 바닥은 숲과 노스포크 버진강의 물을 공급받는 하안지대를 지탱한다. 협곡은 파인 크릭 협곡과 합류하여 국립공원을 벗어나 스프링데일 마을을 지나 구불구불 이어진다. 협곡의 끝은 버진강과 만나는 지점으로, 강이 궁극적으로 흘러들어가는 미드호에서 북동쪽으로 약 100 마일 (160 km) 떨어져 있다.
자이언 캐니언 설명
자이언 캐년 도로와 자이언-마운트 카멜 고속도로는 협곡을 가로지르는 두 개의 주요 도로이다. 자이언 캐년 도로는 시나와바 사원에서 끝나며, 이곳에서 리버사이드 워크 트레일은 강을 따라 상류로 이어져 자이언 내로우의 하류 끝에 도달한다. 더 상류의 하이킹 트레일은 내로우로 내려가며, 이곳의 협곡 바닥은 평균 20 피트 (6.1 m) 너비이다. 수위가 충분히 낮을 때 내로우에서의 하이킹이 허용되지만, 폭우 후 돌발홍수가 빠르게 발생할 수 있다. 자이언 협곡 배수 지역의 많은 곳은 흙 덮개가 거의 없거나 전혀 없어, 매우 짧지만 강한 폭풍우 유출을 야기한다. 반면에 주요 자이언 협곡의 대부분 바닥은 거의 1,000 피트 (300 m) 너비이며, 강이 퇴적한 퇴적물로 풍부하다. 협곡 내 강의 지류로는 딥, 콜로브, 구스, 파인, 오크 크릭 등이 있다.
자이언 캐니언 지질 및 역사
지질학적으로 자이언 협곡은 나바호 사암 콜로라도고원의 일부로, 처음 융기했을 때 많은 균열과 틈이 있었으며, 그중 하나가 노스포크 버진강에 의해 잘려 자이언 협곡이 되었다. 강은 협곡을 침식하는 가장 큰 힘이었는데, 주로 돌발홍수에 의해 이루어졌고, 강물의 평균 유량은 매우 적다. 이러한 상대적으로 빠른 침식은 많은 계절 지류에 매달린 계곡을 남겼다. 일부 가장 큰 지류는 계곡 바닥과 거의 동일한 고도까지 침식되었다.
침식은 계속해서 협곡 벽을 깎아내어 자연 아치와 기타 암석 지형을 만들어낸다. 버진강이 아직 침식할 수 있는 수직 기반암이 1,000 피트 (300 m) 더 남아있다고 여겨진다. 협곡 벽의 균열에 얼음이 끼어드는 현상으로 자주 발생하는 중력 사면 이동은 계곡을 넓히는 또 다른 힘이다. 나바호 사암층은 쉽게 침식되며 매우 다공성인 것으로 알려져 있다. 협곡 전체에 걸쳐 불안정한 지질이 만연하며, 가끔씩 발생하는 산사태는 협곡에 임시 호수를 형성했는데, 가장 최근의 호수는 약 4,000년 전이었다. 협곡의 깊이가 극심하기 때문에 주변 지하수의 공급을 받는 많은 샘이 있어 협곡의 물이 연중 내내 흐를 수 있다.
자이언 캐니언 지질 및 역사
몰몬교도들은 1850년대 후반 버진강 하류 지역에서 이주했다. 몰몬교 정착민 중 한 명인 아이작 베허닌이 협곡에 이름을 붙인 것으로 알려져 있다. 협곡을 감상하던 베허닌은 "사람은 인공적인 교회에서만큼이나 이 위대한 대성당들 사이에서도 하나님을 숭배할 수 있습니다. 이곳은 시온입니다"라고 말했다고 전해지지만, 또 다른 표현도 보고되었다. 시온이라는 용어는 성경 전반에 걸쳐 자주 발견되며, 문자적 장소와 비유적 장소 모두를 지칭할 수 있다. 많은 기독교인들에게 시온은 하나님께서 평화, 안전, 안식을 위해 정하신 장소를 의미한다.
탐험가 존 웨슬리 파월은 협곡의 원주민 이름이라고 알려진 무쿤투윕이라는 이름을 붙인 것으로 알려져 있다. 1909년에 협곡은 처음으로 국립기념물로 지정되었고, 1919년에는 국립공원으로 선포되었다. 파인 크릭 협곡과 하류 자이언 협곡을 가로지르는 자이언-마운트 카멜 고속도로는 1930년에 처음 개통되었다.
와이메아 캐니언 주립공원
와이메아 캐니언은 태평양의 그랜드 캐니언으로도 알려져 있으며, 미국 하와이 제도의 카우아이 서쪽에 위치한 큰 협곡으로, 길이는 약 ten 마일 (16 km), 깊이는 최대 3,000 피트 (910 m)에 달한다. 와이메아는 하와이어로 "붉은 물"을 의미하며, 협곡의 붉은 흙의 침식을 나타낸다. 이 협곡은 지구상에서 가장 습한 곳 중 하나인 섬의 중앙 봉우리인 와이알레알레산의 극심한 강우량으로 인해 형성된 와이메아강의 깊은 침식으로 만들어졌다.
와이메아 캐니언 주립공원 지질학
이 협곡은 솔레아이트와 후기 순상 칼크-알칼리성 용암으로 이루어진 협곡 현무암에 새겨져 있다. 협곡의 용암은 섬의 초기 역사에서 발생한 대규모 단층 형성 및 붕괴의 증거를 제공한다. 협곡의 서쪽은 모두 얇고 서쪽으로 경사진 나팔리층의 용암으로 이루어져 있다. 이와 대조적으로 동쪽은 매우 두껍고 평평한 올로켈레층과 마카웰리층의 용암으로 이루어져 있다. 이 두 부분은 섬의 상당 부분이 큰 붕괴로 인해 아래로 이동한 거대한 단층에 의해 분리되어 있다.
이 협곡은 꾸준한 침식 과정뿐만 아니라 카우아이를 형성한 화산의 격변적인 붕괴로 인해 형성되었기 때문에 독특한 지질학적 역사를 가지고 있다.
다른 하와이 섬들과 마찬가지로 카우아이도 해저에서 솟아오른 거대한 화산의 정상이다. 약 5백만 년 전으로 거슬러 올라가는 용암 흐름을 가진 카우아이는 대형 하와이 섬 중 가장 오래된 섬이다. 약 4백만 년 전, 카우아이가 거의 지속적으로 분출하는 동안 섬의 일부가 붕괴되었다. 이 붕괴로 인해 함몰부가 형성되었고, 그 후 용암 흐름으로 채워졌다.
와이메아 캐니언 주립공원 지질학
그 이후로 와이알레알레산 경사면의 빗물이 붕괴된 가장자리를 따라 와이메아 협곡을 침식시켰다. 협곡의 동쪽에는 함몰부에 고인 두꺼운 용암 흐름으로 이루어진 절벽이 있다. 시간이 지남에 따라 노출된 현무암은 원래의 검은색에서 밝은 빨간색으로 풍화되었다.
와이메아 캐니언 주립공원 지리
와이메아 캐니언 주립공원은 1,866 ac (7.55 km2)에 걸쳐 있으며 섬의 인기 있는 관광 명소이다. 이곳은 수많은 하이킹 코스가 있는 야생 지역을 제공한다. 이 공원은 18마일 길이의 하와이 주도 550번 도로를 통해 와이메아에서 접근할 수 있으며, 이 도로는 코케에 주립공원까지 이어진다. 그 지점에서 카우아이 서쪽으로 짧은 거리에 있는 니하우 섬은 고속도로에서 선명하게 보인다.
IBM 웹스피어 애플리케이션 서버
IBM 웹스피어 애플리케이션 서버(IBM WebSphere Application Server, WAS)는 웹 애플리케이션 서버의 역할을 수행하는 소프트웨어 제품이다. 더 구체적으로 말해, 자바 기반의 웹 애플리케이션을 호스팅하는 소프트웨어 프레임워크이자 미들웨어이다. 이는 IBM의 웹스피어 소프트웨어 제품군 내의 주력 제품이다. 이 제품은 도널드 F. 퍼거슨에 의해 처음 만들어졌으며, 그는 후에 델의 소프트웨어 최고기술책임자(CTO)가 되었다. 첫 번째 버전은 1998년에 출시되었다. 이 프로젝트는 도미노 고 웹 서버로 시작한 IBM HTTP 서버 팀의 파생 프로젝트였다.
IBM 웹스피어 애플리케이션 서버 아키텍처
IBM 웹스피어 애플리케이션 서버(WAS)는 자바 EE, XML, 웹 서비스와 같은 개방형 표준을 사용하여 구축되었다. 이는 윈도우, AIX, 리눅스, 솔라리스, IBM i 및 z/OS 플랫폼에서 실행된다. 버전 6.1부터 현재 버전 9.0에 이르기까지 개방형 표준 사양은 모든 플랫폼에서 정렬되고 공통적으로 사용된다. 플랫폼 활용은 개방형 표준 사양 이하에서 이루어진다.
이는 아파치 HTTP 서버, 넷스케이프 엔터프라이즈 서버, 마이크로소프트 인터넷 정보 서비스(IIS), i5/OS용 IBM HTTP 서버, z/OS용 IBM HTTP 서버, AIX/리눅스/마이크로소프트 윈도우/솔라리스용 IBM HTTP 서버를 포함한 여러 웹 서버와 함께 작동한다. 기본 관리 포트로 9060번 포트를, 기본 웹사이트 게시 포트로 9080번 포트를 사용한다.
IBM 웹스피어 애플리케이션 서버 아키텍처
"전통적인"(리버티 변형과 대비되는) IBM 웹스피어 애플리케이션 서버 플랫폼은 여러 운영 체제 인스턴스에 설치될 수 있는 분산 컴퓨팅 플랫폼으로 설계되었으며, 이를 총칭하여 웹스피어 셀이라고 한다. 모든 인스턴스 관리는 셀 내의 관리 노드인 배치 관리자를 통해 수행할 수 있으며, 애플리케이션 배포(롤링 업데이트 기능 포함)는 셀 노드의 하위 집합으로 푸시될 수 있다. 전체 셀의 구성 정보(노드 수, 각 노드에 배포된 애플리케이션, 애플리케이션 구성 방법, 세션 관리 및 기타 리소스 세부 정보 등)는 셀 전체의 모든 노드에 분산된 XML 구성 파일에 추적된다. 제품 수명 기간 동안 이러한 구성 세부 정보의 구현은 파일에서 데이터베이스 기반(약 V3.5)으로, 다시 파일(약 V5)로 변경되었다.
IBM 웹스피어 애플리케이션 서버 아키텍처
분산 설치를 고려하고, 전체 셀 관리에 로컬 효과(예: 배포, 로깅 구성 등) 관리가 필요하다는 점을 고려할 때, 전반적인 효과는 WAS 보안이 제대로 구성되지 않으면 로컬 보안을 종종 무시할 수 있다는 것이었다. 예를 들어, 초기 관리 콘솔 버전에서는 원격 노드에 로그 파일의 위치를 지정하는 옵션이 있었다. 이는 해당 원격 노드의 임의 파일에 읽기/쓰기를 하는 데 사용될 수 있었다. 이러한 이유로, 애플리케이션 서버/노드 에이전트 프로세스를 루트 권한으로 실행하는 것은 권장되지 않았으며, V6부터 보안 구성은 기본적으로 보안 상태로 설정되었다(이것이 원하는 기능을 활성화하기 위해 기본값을 수동으로 변경해야 함을 의미하더라도). 원래 셀의 모든 노드는 관리 및 애플리케이션 보안을 위해 단일 도메인에 있었다. 그러나 V6.1부터는 여러 보안 도메인이 있을 수 있으며 관리 및 애플리케이션 보안은 분리될 수 있다.
많은 IBM 제품(예: IBM InfoSphere DataStage)은 IBM 웹스피어 애플리케이션 서버를 인프라의 기본 플랫폼으로 사용한다.
IBM 웹스피어 애플리케이션 서버 버전 역사
IBM은 IBM 웹스피어 애플리케이션 서버의 여러 버전과 에디션을 출시했다.
첫 번째 베타 버전에서 WebSphere는 Servlet Express라고 불렸다.
일반적으로 소프트웨어 산업에서 x.1 및 x.5 버전 체계가 마이너 릴리스를 나타내는 경향이 있지만, WebSphere v6.1 및 v5.1은 WebSphere v8.5 및 v3.5와 마찬가지로 주요 릴리스이다.
IBM 웹스피어 애플리케이션 서버 버전 역사
WebSphere Liberty는 WebSphere Application Server V8.5에 도입되었으며, 원래 WebSphere Liberty Profile이라고 불렸고, 나머지 WAS와 동일한 버전 번호 체계를 사용했다. 2016년 IBM은 단일 지원 스트림에서 Liberty의 지속적인 제공으로의 전환을 반영하기 위해 Liberty에 대한 새로운 픽스 팩 번호 체계를 도입했다. V8.5.5.9 이후 Liberty 번호 체계는 Liberty 픽스 팩 릴리스의 연도와 분기를 반영하여 16.0.0.2부터 재설정되었다. WebSphere Liberty의 공통 레벨은 WebSphere Application Server 버전 8.5와 버전 9.0의 일부로 배포된다. Liberty 지속적 제공 모델은 새로운 기능과 특징을 더 자주 제공할 수 있도록 도입되었다.
IBM 웹스피어 애플리케이션 서버 버전 역사
WebSphere Application Server V9.0은 자바 EE 7과 자바 SE 8을 추가한다. 이를 통해 WAS Application Server 전통 버전은 2015년부터 WebSphere Liberty가 제공했던 자바 EE와 동일한 수준으로 향상되었다. 이는 WAS가 온프레미스 제공과 IBM 클라우드의 서비스로서의 웹스피어를 통해 동시에 제공된 첫 번째 릴리스였다.
IBM 웹스피어 애플리케이션 서버 버전 역사
WebSphere Liberty는 새로운 클라우드 네이티브 애플리케이션의 초점으로 점점 더 중요해지고 있으며, Liberty 16.0.0.2는 WAS 버전 9.0.0.0에 포함된 Liberty 버전이다. Liberty 16.0.0.3은 표준 자바 EE 기술을 사용하여 클라우드 네이티브 애플리케이션 개발을 단순화하는 새로운 MicroProfile 프로그래밍 모델에 대한 지원을 추가한다. WebSphere Liberty에 대한 유연한 접근은 도커 이미지 및 Cloud Foundry 빌드팩과 같은 추가 배포를 통해 제공된다. 2017년 9월 IBM은 Liberty의 지속적인 개발을 Open Liberty라는 새로운 오픈 소스 프로젝트로 이전했다. Open Liberty는 WebSphere Application Server의 Liberty 런타임의 소스이다. Open Liberty의 배포는 OpenLiberty.io 커뮤니티에서 지원한다. IBM은 WebSphere Application Server를 통해 Liberty에 대한 상업적 지원을 제공한다.
IBM 웹스피어 애플리케이션 서버 버전 역사
IBM 웹스피어 애플리케이션 서버 V8.5.5에는 자바 SE 8, V8.5.5.6부터 완전한 자바 EE 7 준수, 웹스피어의 지능형 관리 기능 등 Liberty 프로파일에 대한 중요한 개선 사항이 포함되어 있다. WebSphere Liberty의 자바 EE 지원은 기능 세트 구성을 통해 활성화되며, WAS의 각 에디션에서 다른 라이브러리 기능 세트를 사용할 수 있다. WAS Liberty Core 에디션에는 자바 EE WebProfile에 필요한 Liberty 기능이 포함되어 있으며, WAS의 다른 모든 에디션은 전체 자바 EE 7에 대한 Liberty 기능을 추가한다. WAS Network Deployment 에디션은 지능형 관리를 위한 Liberty 기능을 추가한다. 이 외에도 WAS z/OS 에디션은 z/OS 플랫폼 기능을 활성화하기 위한 Liberty 기능을 추가한다.
IBM 웹스피어 애플리케이션 서버 버전 역사
IBM 웹스피어 애플리케이션 서버 V8.5는 V8.0과 동일한 자바 EE 6 및 자바 SE 6 (기본값)을 제공하며, 또한 자바 SE 7에서 실행되도록 구성할 수 있다. V8.5의 주요 새로운 기능은 WebSphere Application Server의 Liberty 프로파일과 지능형 관리 기능이다.
IBM 웹스피어 애플리케이션 서버 버전 역사
IBM 웹스피어 애플리케이션 서버의 Liberty 프로파일은 서버의 모든 상업용 에디션에 포함되어 있으며, 웹, 모바일 및 OSGi 애플리케이션을 위한 경량 서버 프로파일을 제공한다. 이 릴리스에서 Liberty 프로파일은 개발 및 프로덕션 사용을 위한 웹스피어 애플리케이션 서버의 전체 프로파일의 기능적 하위 집합으로, 설치 크기가 50MB 미만이고, 시작 시간이 약 3초이며, 개발자 생산성을 높이는 데 도움이 되는 개발 아티팩트로 취급될 수 있는 새로운 XML 기반 서버 구성을 제공한다. 서버 기능은 서버 구성에 정의된 기능 세트를 통해 작동하며, 기능은 OSGi 서비스의 내부 사용을 통해 동적으로 추가 및 제거된다. 애플리케이션을 개발부터 프로덕션까지 파이프라인을 통해 패키지된 서버로 이동시키는 새로운 모델이 제공되며, 이는 압축 해제 배포를 위한 서버, 서버 구성 및 애플리케이션의 완전한 아카이브이다. 중앙 관리 설치는 WebSphere Application Server Network Deployment 에디션의 작업 관리자 구성 요소를 통해 선택적으로 사용할 수 있다.
IBM 웹스피어 애플리케이션 서버 버전 역사
지능형 관리 기능은 WebSphere Application Server의 Network Deployment 및 z/OS 에디션에 추가되었다. 이는 이전에 별도의 WebSphere Virtual Enterprise (WVE) 제품에서 제공되었던 운영 기능, 즉 애플리케이션 에디션, 서버 상태 관리, 동적 클러스터링 및 지능형 라우팅을 통합한다.
Compute Grid 또한 WebSphere Application Server의 Network Deployment 및 z/OS 에디션에 포함되어 있다. 이전에는 Java 배치 워크로드의 스케줄링 및 관리를 위한 별도 유료 WebSphere XD Compute Grid 기능이었다.
이 버전은 2008년 9월 9일에 출시되었다. 자바 EE 5를 준수하는 애플리케이션 서버이다.
IBM 웹스피어 애플리케이션 서버 버전 7에서 도입된 주요 기능은 다음과 같다:
IBM 웹스피어 애플리케이션 서버 버전 역사
WebSphere Application Server V7의 일반 출시와 WebSphere Application Server V8 (2011년) 사이에는 V7 설치에 선택적으로 추가되는 기능 팩 형태로 여러 추가 기능이 제공되었다. 기능 팩 콘텐츠는 주 릴리스 콘텐츠와 동일한 품질과 지원을 제공하며, 기능 팩의 목적은 다음 주요 릴리스 이전에 새로운 혁신을 제공하는 것이다. WebSphere Application Server V7에 제공된 기능 팩은 다음과 같다:
이 버전은 2006년 6월 30일에 출시되었다. 2012년 9월 11일, IBM은 V6.1의 서비스 종료일을 1년 연장하여 2013년 9월 30일로 정하고, 새로운 버전 간 마이그레이션 인센티브와 지원을 발표했다. 이는 자바 EE 1.4를 준수하는 애플리케이션 서버이며 다음 기능을 포함한다:
EJB 3.0 기술 지원과 일부 웹 서비스 표준 지원은 각각 EJB 기능 팩과 웹 서비스 기능 팩을 통해 제공되었다. 이 기능 팩의 기능은 버전 7의 주 제품에 통합되었다. 웹 서비스 기능 팩의 기능은 다음과 같다.
IBM 웹스피어 애플리케이션 서버 버전 역사
이전에 WebSphere Application Server V5.0 Enterprise Edition에서 발견되었던 많은 프로그래밍 모델 확장이 엔터프라이즈에서 익스프레스 및 기본으로 옮겨졌다. 이러한 API에는 애플리케이션 프로파일, 시작 빈, 스케줄러 및 비동기 빈이 포함되었다.
이제 "WebSphere Platform Messaging"이라고 불리는 JMS 엔진은 100% 자바 언어로 재작성되었으며 기능이 크게 향상되었다. (WebSphere MQ는 여전히 JMS 공급자로 지원되며 WebSphere Platform Messaging과 상호 운용된다.)
클러스터링은 고가용성 관리자를 사용하도록 재작성되었다. 이는 WebSphere 환경의 모든 단일 인스턴스를 관리하며 해당 단일 인스턴스에 대한 핫 복구를 제공할 수 있다.
WebSphere는 공유 파일 시스템을 사용하여 트랜잭션 로그를 저장할 수 있도록 수정되었으며, 이는 해당 공유 파일 시스템이 마운트된 모든 클러스터 멤버가 외부 HA 소프트웨어 없이 의심스러운 XA 트랜잭션을 핫 복구할 수 있음을 의미했다.