웹 서비스 및 아키텍처 스타일

네트워크 서비스

구성 요소가 제공하는 서비스는 네트워크 간에 호출되거나 다른 구성 요소를 호출할 수 있습니다.

웹 서비스 구현 방법:

        1. Using Remote procedure(RPC) 
        2. Using Service-oriented-architecture(SOA).
        3. Using Representational State Transfer(REST).
        4. Using Application Programme Interface(API).

이 서비스에 대한 자세한 내용:

전형적인 클라이언트 서비스 구조 모델에서 클라이언트 요청과 서버 응답은 같은 경우도 서비스에서 발생한다.구성 요소 (서비스 요청자) 는 하나의 대상을 요청하고, 클라이언트 (서비스 응답자) 대상은 성공/실패로 응답합니다.
서비스 공급업체:
서비스broker/servicerepository/serviceregistry를 통해 포획에 필요한 서비스를 호출할 수 있습니다.있으면 응답하고, 없으면 다른 서비스 제공자를 호출하여 대상을 가져옵니다.
서비스 요청자:
서비스 요청자는 필요한 서비스를 요청하고 일련의 통신을 통해 자원을 구성 요소에 사용할 수 있습니다.서비스 요청자와 서비스 제공자 간의 통신은 서비스 저장소/서비스 등록표를 통해 진행된다.그것은 서비스 공급자로부터 온 서비스를 사용하기 때문에 서비스 소비자라고 불린다.
서비스 매니저:
이러한 유형의 서비스는 서비스 요청자와 서비스 소비자 간의 중개 구성 요소를 충당한다.때때로 서비스 제공자가 서비스 사용자가 요청한 자원이 없을 때 현재 서비스 사용자는 다른 서비스 제공자에게 해당하는 자원을 요청한다.
예:
서비스 요청자(SR1)가 서비스 에이전트(SB1)를 통해 서비스 제공자 SP1에 요청한 것으로 가정하지만 서비스 제공자(SP1)에 해당하는 리소스가 없습니다.따라서 이제 SP1은 서비스 요청자(SR2)의 이름으로 동일/기타 서비스를 통해 SP2에 동일한 리소스를 요청합니다.또한 여기 SP1은 SR1의 서비스 에이전트입니다.결국, 자원을 사용할 수 있다면, 그것은 계속될 것이다.SP[n]에서 리소스를 찾으면동일한 결과가 서비스 요청자(SR1)에게 반환됩니다. 이는 피어 스타일과 유사할 수 있습니다.
따라서 같은 구성 요소는 서비스 요청자와 서비스 제공자/서비스 에이전트를 충당할 수 있다.

건축 스타일은 드물다.

  Basic Architecture styles in order:
  1.Client-Server
  2.Peer-to-Peer
  3.Monolithic
  4.Service-Oriented
  5.Micro Services

첫 번째부터.

클라이언트 - 서버

위에서 말한 바와 같이 서버는 자원 공급자이고 클라이언트는 그들을 방문하는 사람이다.많은 클라이언트들이 같은/다른 자원을 요청할 것이며, 서버는 모든 클라이언트에게 서비스를 제공해야 한다.클라이언트도 원격에서 파일에 접근할 수 있다.

점 대 점

모든 시스템 (노드) 은 네트워크로 집중되어 필요할 때 파일을 공유합니다.각 노드는 공용 파일과 폴더에 액세스할 수 있습니다.공유는 케이블, 광섬유 등 매체를 통해 이루어진다.
각 노드는 동일한 처리 능력과 등전위를 가지고 있다.

방대하고 단일했어

소프트웨어는 하나의 모듈로 만들어졌다.모든 기능과 임무는 같은 모듈을 통해 완성될 것이다.언제든지 변경이 필요하면 같은 모듈을 변경하고 배치해야 합니다.모듈화 프로그래밍 스타일의 모듈화 정도는 낮다.이것은 혼자서 게임을 하는 것에 비유할 수 있다.
차세대 아키텍처:

서비스 대상

모든 응용 프로그램 논리를 여러 구성 요소에 봉인하고 일반적인 프로토콜(예를 들어 간단한 대상 접근 프로토콜(SOAP)을 사용하여 이를 서비스로 공유하며 XML과 메시지를 교환할 수 있습니다.
SOA의 각 구성 요소에는 특정한 기능이 있을 수 있습니다. SOAP는 구성 요소 간에 메시지를 전달하는 프로토콜이고 HTTP 프로토콜은 응용 프로그램 간의 더 높은 통신 수준에서 응용 프로그램에 접근하는 데 사용됩니다.웹 서비스 설명 언어(WSDL)는 SOA에서 다른 구성 요소가 접근할 수 있도록 다른 구성 요소에서 사용할 수 있는 서비스를 설명하는 데 사용됩니다.그러나 구성 요소에서 서비스의 구현 세부 사항은 WSDL에 표시되지 않고 XML에서 완성됩니다.UDDI(University Description Discovery and Integration)는 웹 서비스에 대한 설명과 통합에 사용됩니다.
그것은 웹에서 사용할 수 있는 웹 서비스의 색인을 충당한다.그것은 모든 서비스와 연락처가 사용할 수 있는 전화 디렉터리와 비교할 수 있다.

SOA에서 논의할 작은 문제 중 하나는 서로 다른 프로그래밍 언어로 구성된 서로 다른 유형의 응용 프로그램 간의 통신입니다. 호환되지 않는 문제를 제기했습니다.이러한 비호환성은 인터넷 네트워크에서 웹 서비스를 사용하는 SOAP 구현 방법을 통해 해결할 수 있다.이것은 간단한 방식으로 주요 문제를 해결하고 응용 프로그램 간의 통신을 간소화시켰다.그것은 서로 다른 응용 프로그램의 인터페이스를 충당한다.그것은 단층 소프트웨어 문제를 해결할 뿐만 아니라 다층 체계 구조 문제도 해결했다.

미니 서비스

한 마디로 하면 나머지는 마이크로서비스의 구조 스타일이다.그러나 그것도 여러 가지 방식으로 실현될 수 있다.다음은 표현 상태 이동에서 표현 상태 이동으로 단축되며 존재하는 모든 자원/객체가 URL을 통해 액세스됨을 나타냅니다.
결과는 JSON 형식으로 전송됩니다.CRUD 기반 HTTP 방법이 없으면 나머지는 완료할 수 없습니다.
REST는 상태 이동 정책 방법으로, 상태가 없으면 상태를 저장하지 않습니다.
예: 객체에서 HTTP 메서드를 구현하고 리소스의 상태를 항상 확인하고 결과를 반환할 수 있습니다.
만약 내가 HTTP Delete 방법으로 그림을 삭제했다고 가정한다면, 나는 그것이 삭제되었는지 영원히 알 수 없다. GET 방법이 같은 자원에 적용되지 않는 한 결과적으로 찾을 수 없기 때문에 자원이 삭제될 것이다.따라서 삭제된 자원을 검증하는 방법으로 간주할 수 있습니다.
주의해야 할 것은 URI/URL을 사용하는 것은 당신이 마이크로서비스를 사용하고 있다는 것을 의미하지 않는다는 것이다.URI는 WEB의 다른 리소스에 액세스하는 데도 사용할 수 있습니다.
REST-API
API는 웹 서비스 접근 방법을 실현하는 방식으로 여기서 서비스를 얻고 제공한다.API는 외부 세계의 모든 응용 프로그램과 상호작용하는 게이트웨이를 충당하며, 외부 세계는 이러한 응용 프로그램과 통신하기를 원한다.
예를 들어 페이스북은'페이스북 공유 API'를 제공하여 페이스북 벽에 있는 지정된 사이트를 공유하는 데 사용할 수 있다.

simple API에서는 두 응용 프로그램 간의 현대적인 통신 방식으로 결과는 JSON으로 포맷됩니다.
RESTAPI는 REST 구조를 통해 웹에서 리소스를 사용할 수 있도록 합니다.REST의 각 리소스에는 UI, 로그인과 같은 특정 지역 및 특성이 있습니다.정식으로 상호 양보 문화가 되다.API도 인터넷의 응용 프로그램을 통해 호출할 수 있다.
간단하게 말하면 서비스 집합은 하나의 응용 프로그램을 제공한다.
데이터는 서비스에서 흐르고 이를 완전한 체계 구조로 만든다.
마지막으로 API는 REST와 다릅니다.
체크포인트:

서비스 제공자와 서비스 요청자 간의 차이

단일 및 SOA 차이

SOAP 및 API 차이

REST 및 API 차이

마이크로서비스와 API 간의 차이

SOAP와 SOA 간의 차이

이미지 출처: XML 및 웹 서비스 현장 안내서