IBM 웹스피어 애플리케이션 서버(IBM WebSphere Application Server, WAS)는 웹 애플리케이션 서버의 역할을 수행하는 소프트웨어 제품이다. 더 구체적으로 말해, 자바 기반의 웹 애플리케이션을 호스팅하는 소프트웨어 프레임워크이자 미들웨어이다. 이는 IBM의 웹스피어 소프트웨어 제품군 내의 주력 제품이다. 이 제품은 도널드 F. 퍼거슨에 의해 처음 만들어졌으며, 그는 후에 델의 소프트웨어 최고기술책임자(CTO)가 되었다. 첫 번째 버전은 1998년에 출시되었다. 이 프로젝트는 도미노 고 웹 서버로 시작한 IBM HTTP 서버 팀의 파생 프로젝트였다.
아키텍처
IBM 웹스피어 애플리케이션 서버(WAS)는 자바 EE, XML, 웹 서비스와 같은 개방형 표준을 사용하여 구축되었다. 이는 윈도우, AIX, 리눅스, 솔라리스, IBM i 및 z/OS 플랫폼에서 실행된다. 버전 6.1부터 현재 버전 9.0에 이르기까지 개방형 표준 사양은 모든 플랫폼에서 정렬되고 공통적으로 사용된다. 플랫폼 활용은 개방형 표준 사양 이하에서 이루어진다.
"전통적인"(리버티 변형과 대비되는) IBM 웹스피어 애플리케이션 서버 플랫폼은 여러 운영 체제 인스턴스에 설치될 수 있는 분산 컴퓨팅 플랫폼으로 설계되었으며, 이를 총칭하여 웹스피어 셀이라고 한다. 모든 인스턴스 관리는 셀 내의 관리 노드인 배치 관리자를 통해 수행할 수 있으며, 애플리케이션 배포(롤링 업데이트 기능 포함)는 셀 노드의 하위 집합으로 푸시될 수 있다. 전체 셀의 구성 정보(노드 수, 각 노드에 배포된 애플리케이션, 애플리케이션 구성 방법, 세션 관리 및 기타 리소스 세부 정보 등)는 셀 전체의 모든 노드에 분산된 XML 구성 파일에 추적된다. 제품 수명 기간 동안 이러한 구성 세부 정보의 구현은 파일에서 데이터베이스 기반(약 V3.5)으로, 다시 파일(약 V5)로 변경되었다.
분산 설치를 고려하고, 전체 셀 관리에 로컬 효과(예: 배포, 로깅 구성 등) 관리가 필요하다는 점을 고려할 때, 전반적인 효과는 WAS 보안이 제대로 구성되지 않으면 로컬 보안을 종종 무시할 수 있다는 것이었다. 예를 들어, 초기 관리 콘솔 버전에서는 원격 노드에 로그 파일의 위치를 지정하는 옵션이 있었다. 이는 해당 원격 노드의 임의 파일에 읽기/쓰기를 하는 데 사용될 수 있었다. 이러한 이유로, 애플리케이션 서버/노드 에이전트 프로세스를 루트 권한으로 실행하는 것은 권장되지 않았으며, V6부터 보안 구성은 기본적으로 보안 상태로 설정되었다(이것이 원하는 기능을 활성화하기 위해 기본값을 수동으로 변경해야 함을 의미하더라도). 원래 셀의 모든 노드는 관리 및 애플리케이션 보안을 위해 단일 도메인에 있었다. 그러나 V6.1부터는 여러 보안 도메인이 있을 수 있으며 관리 및 애플리케이션 보안은 분리될 수 있다.
첫 번째 베타 버전에서 WebSphere는 Servlet Express라고 불렸다.[16]
일반적으로 소프트웨어 산업에서 x.1 및 x.5 버전 체계가 마이너 릴리스를 나타내는 경향이 있지만, WebSphere v6.1 및 v5.1은 WebSphere v8.5 및 v3.5와 마찬가지로 주요 릴리스이다.[17]
웹스피어 리버티 버전
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 지속적 제공 모델은 새로운 기능과 특징을 더 자주 제공할 수 있도록 도입되었다.[18]
버전 9.0
WebSphere Application Server V9.0[19]은 자바 EE 7과 자바 SE 8을 추가한다. 이를 통해 WAS Application Server 전통 버전은 2015년부터 WebSphere Liberty가 제공했던 자바 EE와 동일한 수준으로 향상되었다. 이는 WAS가 온프레미스 제공과 IBM 클라우드의 서비스로서의 웹스피어를 통해 동시에 제공된 첫 번째 릴리스였다.[20]
WebSphere Liberty는 새로운 클라우드 네이티브 애플리케이션의 초점으로 점점 더 중요해지고 있으며, Liberty 16.0.0.2는 WAS 버전 9.0.0.0에 포함된 Liberty 버전이다. Liberty 16.0.0.3은 표준 자바 EE 기술을 사용하여 클라우드 네이티브 애플리케이션 개발을 단순화하는 새로운 MicroProfile 프로그래밍 모델[21]에 대한 지원을 추가한다. WebSphere Liberty에 대한 유연한 접근은 도커 이미지[22] 및 Cloud Foundry 빌드팩[23]과 같은 추가 배포를 통해 제공된다. 2017년 9월 IBM은 Liberty의 지속적인 개발을 Open Liberty라는 새로운 오픈 소스 프로젝트로 이전했다.[24] Open Liberty는 WebSphere Application Server의 Liberty 런타임의 소스이다. Open Liberty의 배포는 OpenLiberty.io 커뮤니티에서 지원한다.[25] IBM은 WebSphere Application Server를 통해 Liberty에 대한 상업적 지원을 제공한다.
버전 8.5.5
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 기능을 추가한다.
버전 8.5.0
IBM 웹스피어 애플리케이션 서버 V8.5는 V8.0과 동일한 자바 EE 6 및 자바 SE 6 (기본값)을 제공하며, 또한 자바 SE 7에서 실행되도록 구성할 수 있다. V8.5의 주요 새로운 기능은 WebSphere Application Server의 Liberty 프로파일과 지능형 관리 기능이다.
IBM 웹스피어 애플리케이션 서버의 Liberty 프로파일은 서버의 모든 상업용 에디션에 포함되어 있으며, 웹, 모바일 및 OSGi 애플리케이션을 위한 경량 서버 프로파일을 제공한다. 이 릴리스에서 Liberty 프로파일은 개발 및 프로덕션 사용을 위한 웹스피어 애플리케이션 서버의 전체 프로파일의 기능적 하위 집합으로, 설치 크기가 50MB 미만이고, 시작 시간이 약 3초이며, 개발자 생산성을 높이는 데 도움이 되는 개발 아티팩트로 취급될 수 있는 새로운 XML 기반 서버 구성을 제공한다. 서버 기능은 서버 구성에 정의된 기능 세트를 통해 작동하며, 기능은 OSGi 서비스의 내부 사용을 통해 동적으로 추가 및 제거된다. 애플리케이션을 개발부터 프로덕션까지 파이프라인을 통해 패키지된 서버로 이동시키는 새로운 모델이 제공되며, 이는 압축 해제 배포를 위한 서버, 서버 구성 및 애플리케이션의 완전한 아카이브이다. 중앙 관리 설치는 WebSphere Application Server Network Deployment 에디션의 작업 관리자 구성 요소를 통해 선택적으로 사용할 수 있다.
지능형 관리 기능은 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 기능이었다.[26]
버전 7.0
이 버전은 2008년 9월 9일에 출시되었다. 자바 EE 5를 준수하는 애플리케이션 서버이다.
IBM 웹스피어 애플리케이션 서버 버전 7에서 도입된 주요 기능은 다음과 같다:
유연한 관리 기능은 지리적으로 분산될 수 있는 수많은 WebSphere Application Server 기본 에디션 및 네트워크 배포 토폴로지를 쉽게 관리할 수 있도록 해준다.
비즈니스 레벨 애플리케이션은 패키징 또는 프로그래밍 모델과 독립적으로 애플리케이션 아티팩트를 관리하는 데 사용된다.
속성 기반 구성 기능은 자동화된 관리 경험을 단순화한다. 관리자는 간단한 속성 파일을 사용하여 WebSphere Application Server 버전 7 구성을 업데이트할 수 있다.
WebSphere Application Server V7의 일반 출시와 WebSphere Application Server V8 (2011년) 사이에는 V7 설치에 선택적으로 추가되는 기능 팩 형태로 여러 추가 기능이 제공되었다. 기능 팩 콘텐츠는 주 릴리스 콘텐츠와 동일한 품질과 지원을 제공하며, 기능 팩의 목적은 다음 주요 릴리스 이전에 새로운 혁신을 제공하는 것이다. WebSphere Application Server V7에 제공된 기능 팩은 다음과 같다:
현대 배치용 기능 팩
OSGi 애플리케이션 및 JPA 2.0용 기능 팩
SCA용 기능 팩
Web 2.0 및 모바일용 기능 팩
XML용 기능 팩
통신 지원 애플리케이션용 기능 팩
버전 6.1
이 버전은 2006년 6월 30일에 출시되었다. 2012년 9월 11일, IBM은 V6.1의 서비스 종료일을 1년 연장하여 2013년 9월 30일로 정하고, 새로운 버전 간 마이그레이션 인센티브와 지원을 발표했다.[27] 이는 자바 EE 1.4를 준수하는 애플리케이션 서버이며 다음 기능을 포함한다:
이 버전은 2004년 12월 31일에 출시되었다. 자바 EE 1.4를 준수하는 애플리케이션 서버이다. 보안 강화에는 JACC 1.0 및 (사전 OASIS) WS-Security 1.0 지원이 포함된다.
자바 표준 에디션 1.4 지원
이전에 WebSphere Application Server V5.0 Enterprise Edition에서 발견되었던 많은 프로그래밍 모델 확장이 엔터프라이즈에서 익스프레스 및 기본으로 옮겨졌다. 이러한 API에는 애플리케이션 프로파일, 시작 빈, 스케줄러 및 비동기 빈이 포함되었다.
이제 "WebSphere Platform Messaging"이라고 불리는 JMS 엔진은 100% 자바 언어로 재작성되었으며 기능이 크게 향상되었다. (WebSphere MQ는 여전히 JMS 공급자로 지원되며 WebSphere Platform Messaging과 상호 운용된다.)
클러스터링은 고가용성 관리자를 사용하도록 재작성되었다. 이는 WebSphere 환경의 모든 단일 인스턴스를 관리하며 해당 단일 인스턴스에 대한 핫 복구를 제공할 수 있다.
WebSphere는 공유 파일 시스템을 사용하여 트랜잭션 로그를 저장할 수 있도록 수정되었으며, 이는 해당 공유 파일 시스템이 마운트된 모든 클러스터 멤버가 외부 HA 소프트웨어 없이 의심스러운 XA 트랜잭션을 핫 복구할 수 있음을 의미했다.
배치 관리자의 역할은 모든 클러스터링 런타임 작업에서 제거되었다. 중앙 집중식 JMX 관리 및 구성 변경에만 필요하다.
이제 프로덕션에서 혼합 버전 셀(V5에서 V6) 실행을 지원한다.
WebSphere Application Server for z/OS
공통 프로그래밍 모델을 공유하므로 네트워크 배포와 동일한 핵심 기능을 제공하지만 다음과 같은 플랫폼 이점을 여전히 포함한다.
버전 6에서는 이전에 WebSphere Business Integration Server Foundation(WBISF)에 있던 일부 기능이 새로운 IBM WebSphere Process Server로 이동했다. 다른 기능은 다른 에디션(Express 이상)으로 이동했다.
버전 5.1
이 버전은 2004년 1월 16일에 출시되었다. J2EE 1.4를 준수하는 애플리케이션 서버이다.
WebSphere Business Integration Server Foundation V5.1
이는 WebSphere Application Server Enterprise Edition V5.0의 후속 제품이다. 워크플로우 엔진은 V5.0에서 사용된 독점적인 FDML 형식 대신 BPEL을 지원하도록 업데이트되었다. 제품 가격도 재조정되었고 인텔 환경부터 메인프레임까지 모든 IBM 플랫폼에서 사용할 수 있게 되었다.
WebSphere eXtended Deployment (XD)
버전 5.0
2002년 11월 19일 출시된 버전. J2EE 1.3 인증 애플리케이션 서버였다. V3/V4 코드베이스를 대폭 재작성한 것으로, WebSphere Application Server가 공통 코드베이스에서 코딩된 첫 번째 사례였다. 이제 인텔 x86부터 메인프레임에 이르는 모든 배포 플랫폼에서 WAS는 실질적으로 동일한 코드이다. 데이터베이스 기반 구성 저장소는 복제 XML 파일 기반 구성 저장소로 대체되었다. Deployment Manager라는 서비스는 셀 구성의 마스터 복사본을 가지고 있었고, 노드는 변경될 때마다 이 마스터 서버에서 필요한 파일을 복사해왔다. V5에는 임베디드 자바 메시지 서비스(JMS) 서버라고 불리는 MQ 5.3의 축소 버전도 포함되었다.
Express Edition이 Standard Edition을 대체했다. Express는 이제 IBM의 모든 소프트웨어 브랜드에서 중소기업 지향 제품을 나타내는 용어가 되었다.
Base
Network Deployment. 이 버전은 클러스터 및 J2EE 페일오버를 지원하는 셀 구성 배포를 지원한다. 또한 이전에 Edge Server로 알려진 Edge Components를 포함한다. 이는 프록시 서버, 로드 밸런싱 및 콘텐츠 기반 라우팅을 제공한다.
Enterprise Edition. 이 버전은 워크플로우 엔진인 Process Choreographer를 처음으로 추가했지만, BPEL 표준보다 먼저 나왔다. 또한 WebSphere 비동기 빈(Asynchronous Beans)이라는 최초의 완전 지원 애플리케이션 스레딩 모델을 추가했다.
WebSphere Application Server for z/OS. 이 버전은 기본적으로 Network Deployment 제품과 동일하지만, 워크로드 관리자(Workload Manager)와 같은 z/OS 기능을 최대한 활용하여 미션 크리티컬하고 확장 가능하며 안전한 워크로드를 위해 메인프레임을 필수적으로 만드는 핵심 기술을 활용하도록 최적화되어 있다.
버전 4.0
이것은 J2EE 1.2 인증 애플리케이션 서버였다. XML 데이터스토어를 이미 사용하던 단일 서버 에디션을 제외하고는 V3.x의 데이터베이스 기반 구성 모델을 상속받았다.
AE (Advanced Edition)
AEs (Advanced Edition single). 클러스터 구성으로 실행할 수 없는 단일 서버 에디션.
AEd (Developer Edition). 기능적으로 AEs와 동일하지만, 비생산 개발 용도로만 사용된다.
EE (Enterprise Edition)
버전 3.5 (및 3.0)
WebSphere 3.5는 WebSphere의 첫 번째 광범위하게 사용된 버전이다.
아래는 IBM AIX RS6000 시스템 터미널에서 WAS v3.5가 시작되는 모습이다.
IBM AIX RS6000에서 WebSphere 3.5 시작
그림에 나타난 것처럼, 프로세스의 루트는 주 WAS 부트스트랩 프로세스이다:
자바 JVM 머신 자체는 먼저 시작된 다음, 그 아래에 여러 개의 JVM 프로세스가 생성되며, 각 프로세스는 자체 클래스 로더를 가진 엔터프라이즈 애플리케이션을 나타낸다.
클래스가 여러 JVM에서 로드되므로 WAS는 로드된 클래스의 가시성을 관리하기 위한 구성 플래그를 제공한다. 또한 관리자 또는 프로그래머는 클래스의 가시성을 관리하기 위해 계층 구조(.ear 또는 .war의 위치 및 MANIFEST에 들어가는 내용)를 알아야 한다.
[29]
다음 그림은 동심원 형태의 클래스 로딩 계층을 보여준다. 클래스의 가시성은 중요하다. 그렇지 않으면 충돌하는 클래스가 애플리케이션 서버 런타임 중에 타입 캐스팅 오류를 발생시킬 수 있다.
클래스 로더 가시성을 보여주는 동심원: WebSphere 메인 부모 부트스트랩 JVM (중앙) 및 그 자식 JVM (Bassem Jamaleddine 제공)
버전 2.0
IBM은 자바빈, CORBA 및 리눅스 지원을 추가한다. Standard Edition (SE) 및 Advanced Edition (AE) 두 가지 에디션으로 제공된다.
_waving.svg)
