SOA는 "평범한 영어"란 무엇입니까? [닫은]

누군가 SOA가 무엇인지 평범한 영어로 설명 할 수 있습니까 ? 여기에서는 SOA, 거기에서는 SOA를 듣지만 그것이 무엇이며 용도가 무엇인지 정확히 이해할 수 없습니다. 단순한 개념이었고 나중에 거대한 무언가로 진화 했습니까?

위키를 포함한 모든 문서는 다소 추상적이거나 내가 바보이고 이해하지 못할 수도 있습니다. 이것에 대한 바보 가이드가 있습니까?

이 세 글자 뒤에 정확히 무엇이 있습니까?

이 기사 (SOA 란 무엇입니까?-SOA 및 웹 서비스 설명)가 도움 이 될 수 있습니다 .

약간의 티저 :

• SOA는 단순하고 잘 정의 된 인터페이스가 있고 필요한 기능을 수행하기 위해 느슨한 결합을 통해 오케스트레이션되는 개별 소프트웨어 에이전트로 구성되는 방식으로 애플리케이션을 설계하는 스타일입니다.

• SOA에는 서비스 공급자와 서비스 소비자라는 두 가지 역할이 있습니다. 소프트웨어 에이전트는 두 가지 역할을 모두 수행 할 수 있습니다. SOA는 완전히 새로운 개념은 아니지만이 기사는 주로 웹 서비스로 구현 된 SOA에 중점을 둡니다.

SOA는 매우 오래된 아이디어에 대한 새로운 배지입니다.

• 코드를 재사용 가능한 모듈로 나눕니다.

• 변경 될 가능성이있는 설계 결정을 모듈에 캡슐화합니다.

• 서로 다른 유용한 방법 ( "패밀리"또는 "제품 라인"이라고도 함)으로 결합 할 수있는 방식으로 모듈을 설계하십시오.

이것들은 모두 기반 소프트웨어 개발 원칙이며, 대부분 David Parnas가 처음으로 설명했습니다.

SOA의 새로운 기능은

• 네트워크에서하고 있습니다.

• 모듈은 프로 시저 호출과 같은 일반적인 프로그래밍 언어 메커니즘이 아닌 네트워크를 통해 서로 메시지를 전송하여 통신합니다. 특히 서비스 지향 아키텍처에서 부품은 일반적으로 변경 가능한 상태 (기존 프로그램의 전역 변수)를 공유하지 않습니다. 또는 상태를 공유하는 경우 해당 상태는 그 자체가 에이전트이고 여러 동시 클라이언트를 쉽게 관리 할 수있는 데이터베이스에 조심스럽게 잠겨 있습니다.

더 고급 단어와 기술 용어를 사용하여 SOA (Service Oriented Architecture)를 설명하는 많은 답변을 봅니다. 나는 평범한 영어 로 비유 를 사용하여 평신도를 위해 그것을 설명하는 기회를주고 싶습니다 .

그러나 먼저 SOA
SOA에 대한 설명은 아래 그림과 같이 3 개의 계층으로 설명 될 수 있습니다. 한쪽에는 공급자가 있고 다른쪽에는 소비자 가 있으며 두 쪽이 통신 하는 브리지 로 구분됩니다 .

소비자는 비즈니스에 필요한 여러 응용 프로그램을 사용하고 공급자는 이러한 응용 프로그램에 정보를 제공 하는 구성 요소 를 사용 합니다. 이들은 공통 아키텍처를 사용하는 서비스 세트를 통해 통신합니다 .

비유
시골쪽에있는 집을 상상해보십시오. 여러면에서 도시 나 마을과 같은 더 큰 공동체의 일부입니다. 이 도시에는 물과 전기 공급, 위생 처리, 교통 및 기타 유틸리티 제공을위한 자체 복잡한 시스템이 있습니다. 하우스는 이 모델의 소비자 인의 도시 (또는 지역 사회)는 공급자 및 파이프, 하수구, 전력선, 광섬유 등이이다 인프라 가 통신하는.

이 모델은 SOA와 느슨하게 비교할 수 있습니다. 집에있는 사람들은 라디에이터, 컴퓨터, 화장실, 램프, 바닥 난방, 욕조 등과 같은 다양한 "응용 프로그램"을 사용합니다. 이러한 응용 프로그램은 도시에서 물을 생성하거나 전기를 생성하거나 폐기물을 처리하는 방법에 대해 신경 쓰지 않습니다. 작동합니다. 도시의 구성 요소는 발전기, 수도 펌프 및 위생 구역입니다. 집에 이러한 모든 요구 사항을 제공하지만 적합하다고 생각되는 방식으로 사용하는 것은 집에 달려 있습니다.

나는 이것이 적어도 누군가에게 SOA에 대한 더 나은 그림을 줬기를 바랍니다.

네 명의 요리사가 있다고 가정 해 봅시다. SOA에서는 그들이 서로를 미워한다고 가정하기 때문에 가능한 한 적게 서로 대화를해야합니다.

어떻게하나요? 음, 먼저 역할과 인터페이스를 정의 할 것입니다. 요리사 1은 샐러드를 만들고, 요리사 2는 수프를 만들고, 요리사 3은 스테이크를 만듭니다. 그런 다음 테이블에 잘 정리 된 접시를 놓습니다. 인터페이스) "모두가 당신의 창작물을 당신의 요리에 넣어주세요. 다른 사람은 신경 쓰지 마세요."라고 말합니다.

이런 식으로 네 명의 요리사는 가능한 한 적게 서로 대화해야하는데, 이는 소프트웨어 개발에 매우 ​​좋은데, 서로를 싫어하기 때문이 아니라 물리적 위치, 의사 결정의 효율성 등과 같은 다른 이유 때문입니다.

또한 원하는대로 요리 (서비스)를 다시 조합 할 수 있습니다. 예를 들어 디저트를 카페 서비스에 사용하거나 수프를 다른 회사에서 구입 한 빵과 결합하여 더 저렴한 메뉴를 제공하거나 다른 레스토랑에서 샐러드를 사용하여 요리와 결합하도록 할 수 있습니다. .

가장 성공적인 SOA 구현 중 하나는 Amazon이었습니다. 설계로 인해 전체 인프라를 다시 패키징하여 Amazon Web Service로 판매 할 수있었습니다.

* 이것은 SOA의 한 측면 일뿐입니다.

SOA는 아키텍처 스타일이지만 이기종 애플리케이션을 개발하고 통합하는 방법에 대한 비전 . SOA의 주요 목적은 모 놀리 식 애플리케이션 에서 벗어나 애플리케이션 을 빌드하기 위해 구성 할 수있는 재사용 가능한 서비스 세트를 갖는 것 입니다.

IMHO, SOA는 엔터프라이즈 수준에서만 의미가 있으며 단일 응용 프로그램에 대해서는 의미가 없습니다.

많은 기업에서 각 부서에는 다음을 의미하는 고유 한 기업 애플리케이션 세트가 있습니다.

1. 유사한 기능이 여러 번 구현되었습니다.

2. 데이터 (예 : 고객 또는 직원 데이터)는 여러 애플리케이션간에 공유되어야합니다.

3. 애플리케이션은 부서 중심이었습니다.

SOA의 아이디어는 재사용 가능한 서비스를 전사적으로 사용할 수 있도록하여 애플리케이션을 구축하고 구성 할 수 있도록하는 것입니다. SOA의 약속은

1. 유사한 기능을 반복적으로 다시 구현할 필요가 없습니다 (예 : 고객 또는 직원 서비스 제공).

2. 애플리케이션을 함께 통합하고 공통 데이터 또는 기능에 대한 액세스를 용이하게합니다.

3. 엔터프라이즈 중심 개발 노력.

SOA 비전에는 기술적 인 변화와 조직의 변화 . 일부 문제를 해결하는 반면 다른 문제도 도입합니다. 예를 들어 모 놀리 식 애플리케이션을 사용하는 것보다 SOA를 사용하는 경우 보안이 훨씬 더 어렵습니다. 따라서 SOA는 작동 여부에 대한 논의의 대상이됩니다.

이것은 SOA의 1000 피트 뷰입니다. 그러나 여기서 멈추지 않습니다. BPM (Business Process Orchestration), ESB (Enterprise Service Bus), CEP (Complex Event Processing) 등과 같은 SOA를 보완하는 다른 개념이 있습니다. 이들은 모두 IT / 비즈니스 조정 문제 , 즉 IT를 보유하는 방법을 다룹니다 . 비즈니스를 효과적으로 지원할 수 있습니다.

SOA는 Service Oriented Architecture의 약자입니다.

SOA는 고유 한 소프트웨어 모듈을 높은 수준의 재사용 성과 함께 원활하게 통합 할 수있는 방식으로 소프트웨어 응용 프로그램을 설계하고 작성합니다.

대부분의 사람들은 SOA를 클라이언트 / 서버 소프트웨어 웹 서비스 작성으로 제한합니다. 그러나 SOA의 컨텍스트는 너무 작습니다. SOA는 그보다 훨씬 크고 지난 몇 년 동안 웹 서비스는 의사 소통의 주요 매체였습니다. 이는 사람들이 SOA를 일반적으로 SOA의 경계와 의미를 제한하는 웹 서비스로 생각하는 이유 일 것입니다.

종속성없이 자체적으로 작동 할 수있을 정도로 독립적 인 데이터베이스 액세스 모듈을 작성하는 것을 생각할 수 있습니다. 이 모듈은 데이터베이스 액세스가 필요한 모든 호스트 소프트웨어에서 사용할 수있는 클래스를 노출 할 수 있습니다. 호스트 응용 프로그램에는 시작 구성이 없습니다. 필요하거나 필요한 것은 데이터베이스 액세스 모듈에 의해 노출되는 클래스를 통해 전달됩니다. 이러한 클래스를 서비스라고 부르고 모듈을 서비스 사용으로 간주 할 수 있습니다.

SOA를 연습하면 DRY [반복하지 마십시오]를 적용하여 높은 수준의 재사용 성을 제공하여 유지 관리가 용이 ​​한 소프트웨어가됩니다. 유지 보수성은 모든 소프트웨어 아키텍처가 가장 먼저 생각하는 것입니다. SOA는이를 제공합니다.

내가 이해하는 한 기본 개념은 다른 시스템에 유용한 것을 제공하는 작은 "서비스"를 만들고 시스템 내부에서 모든 작업을 수행하는 대형 시스템을 구축하지 않는다는 것 입니다.

따라서 상호 작용에 사용할 프로토콜을 정의하고 (예 : SOAP 웹 서비스 일 수 있음) "비즈니스 작업을 수행하는 시스템"이 "큰 목표"를 달성하기 위해 소규모 서비스와 상호 작용하도록합니다. .

Thomas Erl과 Roger Sessions의 기사를 읽어 보시면 SOA가 무엇인지 확실하게 이해할 수 있습니다. 이것들은 또한 좋은 자원입니다. 평신도 설명을 위해 상사에게 설명 된 SOA를보십시오.

SOA 구축

SOA 디자인 패턴

SOA에서 무결성 달성

SOA가 VW Beetle과 같아야하는 이유

상사를위한 SOA 설명

WCF 서비스 성능

대규모 조직에서 일어나는 경향은 시간이 지남에 따라 모든 것이 모든 곳에서 모 놀리식이거나 이질적인 시스템이거나 둘 다일 뿐이라는 것입니다. 결국 누군가가 와서 우리가 엉망이라고 말합니다. 이제, 당신은 (누군가에게 돈을) 모든 것을 재 설계하고 싶을 것입니다. 모든 것을 모 놀리 식으로 지향하는 것은 당신이 지불하는 패러다임에 따라 달라 지지만 동시에 마스터 / 모놀리스와는 독립적으로 조각과 부분을 추가 할 수 있습니다.

따라서 Oracle의 SOA를 구입하면 Oracle이 모든 부분의 보스가됩니다. 들어오는 다른 모든 플레이어는 서비스 (웹 서비스 또는 그것이 무엇이든간에)를 통해 SOA와 함께 작업해야합니다. 오 예, 전면에 ASP.NET MVC가 있습니다.

중요한 것은 시스템에 영향을주지 않고 시스템 안팎으로 물건을 옮기고 공급 업체 Oracle SOA, Microsoft WCF를 모든 두뇌로 유지하는 것입니다. 모든 것이 엉망이고, 유동적이며, 영향을 거의 또는 전혀받지 않고 들어오고 나가는 것, 심지어 컴퓨터뿐만 아니라 인간 서비스도 마찬가지입니다.

나에게 그것은 좋은 프런트 엔드를 가진 웹 서비스 (또는 미래에 우리가 부르는 모든 것)를 의미합니다. 그리고 만약 당신이 데이터베이스를 소유하고 있다면 그냥 데이터베이스에 접속하고 유행어에 대해 걱정하지 마세요. 괜찮아.

단 하나의 제안 :-

SOA 개념, 기술 및 디자인 읽기Thomas Erl의 을 .

SOA에 대한 세부 사항을 일반 영어와 사례 연구로 매우 아름답게 제공했습니다.

SOA는 Service Oriented Architecture의 약자입니다 .... 간단히 말해서, 매우 일반적인 코드를 작성합니다. 즉, 많은 애플리케이션에서 사용할 수있는 작업을 수행합니다. 주소록 또는 계산기 일 수 있습니다. IIS에서이 코드를 실행합니다. 따라서 코드를 통해 서비스를 제공합니다. 그래서 당신은 서비스 제공자입니다. 이제 누군가 비슷한 코드를 사용하기를 원하면 코드를 다시 작성할 필요가 없습니다. 그는 단순히 웹 서비스를 통해 코드를 사용합니다. 따라서 그는 서비스 소비자가됩니다. 따라서 이러한 서비스를 사용하여 프로그램을 만드는 것을 SOA라고합니다. 서비스 공급자와 소비자가 서로 다른 프로그래밍 언어를 사용하더라도 상호 작용할 수 있으므로 느슨한 결합이 있습니다. 이해하길 바랍니다.

ittoolbox 블로그에서.

다음은 과거 설계 기술과의 유사점 및 차이점을 요약 한 것입니다.

• SOA 대 구조적 프로그래밍 o 유사성 : 매개 변수가 전달되고 함수의 작동이 호출자로부터 추상화되는 서브 루틴 호출과 가장 유사합니다 (예 : CICS 링크 및 실행 및 COBOL CALL 예약어). 카피 북은 일반적으로 서비스에 대한 XML 스키마로 정의되는 데이터 구조를 정의하는 데 사용됩니다. o 차이점 : SOA는 느슨하게 결합되어 서비스 변경이 소비자 ( "호출"프로그램)에 미치는 영향이 적고 서비스가 언어와 플랫폼간에 상호 운용 가능함을 의미합니다.

• SOA 대 OOA / OOD o 유사점 : 캡슐화, 추상화 및 정의 된 인터페이스 o 차이점 : SOA는 클래스 계층 또는 상속없이 느슨하게 결합됩니다. 저수준 추상화-클래스 수준 대 비즈니스 서비스

• SOA 대 레거시 구성 요소 기반 개발 (CBD)-예 : CORBA, DCOM, EJB o 유사점 : 구성 요소 조립, 인터페이스, 원격 호출을 통한 재사용 o 차이점 : 표준의 광범위한 채택, XML 스키마 대 마샬링 된 객체, 서비스 오케스트레이션, 재사용을위한 설계 더 쉬움, 서비스는 비즈니스 중심과 IT 중심, 비즈니스 서비스는 코스 그레인 (범위가 넓음)

• SOA (통합 용) 대 EAI (Enterprise Application Integration) o 유사점 : 모범 사례 (잘 정의 된 인터페이스, 표준화 된 스키마, 이벤트 기반 아키텍처), 재사용 가능한 인터페이스, 공통 스키마 o 차이점 : 표준, 채택 및 개선 된 도구

위의 응답을 읽으면 SOA가 개발자 (적어도 좋은 사람)가 첫날부터해온 일이라고 들립니다.

또한 병렬 (특히 SIMD) 프로그래밍에서 일반적인 주제 인 "배열 구조"( "구조체 배열"과 반대)의 약자 일 수 있지만 여기서 의미하는 바는 아닙니다!

SOA는 기술 공급 업체가 Enterprise Service Bus 관련 기술을 판매하는 데 도움을주기 위해 고안 한 유행어입니다. 아이디어는 기업에서 작은 섬 애플리케이션 (예 : 회계 시스템, 재고 관리 시스템 등)을 모두 노출하여 서비스를 '애플리케이션'으로 유연하게 조정하거나 전체 엔터프라이즈 범위 비즈니스의 일부가되도록 만드는 것입니다. 논리.

기본적으로 거의 작동하지 않는 오래된 볼록의 부하입니다. 왜냐하면 기술이 조직에서 존재하는 방식 인 이유는 문화, 진화, 회사의 역사에 달려 있고, 그 안에 묶여있는 것이 너무 높아서 기술을 재구성하려는 시도는 실패 할 수밖에 없습니다.

SOA를 다루는 이번 주 Floss Weekly 팟 캐스트 에디션을 들어보세요 . 설명은 상당히 높은 수준이며 너무 많은 기술적 세부 사항을 다루지 않습니다 (SOA 프로젝트의 더 구체적이고 인식 가능한 예제가 도움이되었을지라도).

전통적인 애플리케이션 아키텍처는 다음과 같습니다.

• 사용자 인터페이스
• 사용자 인터페이스 뒤에 캡슐화 / 숨겨진 정의되지 않은 항목 (구현)

프로그래밍 방식으로 데이터에 액세스하려면 화면 스크래핑에 의존해야 할 수 있습니다.

SOA는 UI를 노출하는 대신 기계가 읽을 수있는 데이터 및 / 또는 API를 노출하는 데 초점을 맞춘 아키텍처 인 것 같습니다.

SOA 또는 서비스 지향 아키텍처는 다음과 같은 특정 특성 집합을 준수하는 기본 (및 일반적으로 분산 된) 소프트웨어 서비스에서 애플리케이션 또는 시스템을 구성하는 소프트웨어 아키텍처 패턴입니다.

1. 인터페이스, 정책 및 계약 기반
2. 위치 투명성
3. 자발적인
4. 요약
5. 재사용 가능
6. 구성 가능
7. 무국적
8. 발견 가능
9. 확장 가능
10. 느슨한 결합

SOA의 주요 목표는 소프트웨어 개발 민첩성입니다. 즉, 변경 사항에 쉽고 저렴하게 대응할 수 있으므로 기업이 변화하는 시장에 신속하게 대응할 수 있습니다.

서비스는 일반적으로 (단독적으로는 아님) 웹 서비스로 구현됩니다. 즉, 유비쿼터스 웹 HTTP 프로토콜을 통해 작동하며 XML 기반 SOAP 또는 경량 (더 많이 사용되는) REST 패러다임을 사용하여 구현됩니다.

당신이 누군지에 달려 있습니다!

사업 주인 경우 SOA는 소득과 비즈니스 민첩성을 높이는 솔루션입니다. 기업가 인 경우 SOA는 빈 캔버스에 멋지고 깨끗한 소프트웨어를 그리는 방법입니다. 아키텍트라면 SOA가 통합 플랫폼을 통해 느슨하게 결합 된 서비스를 설계하고 서비스를 콘센트에 연결하는 솔루션입니다. 개발자라면 SOA는 서비스가 디자인과 코드의 중심에있는 프로그래밍 패러다임입니다.

100 개 SOA 질문 [pdf]을 읽어야합니다 .

건배

SOA (Service Oriented Architecture)는 다른 응용 프로그램에서 재사용 할 수있는 플러그 가능한 부품 모음으로 응용 프로그램을 빌드하는 소프트웨어 아키텍처 스타일입니다.