서비스 지향 언어가없는 이유는 무엇입니까?

편집하다:

더 혼란을 피하기 위해 : 나는 웹 서비스 등에 대해 이야기 하지 않습니다 . 내부적으로 응용 프로그램을 구성하는 것에 대해 이야기하고 있지만 컴퓨터가 통신하는 방식이 아닙니다. 프로그래밍 언어, 컴파일러 및 명령형 프로그래밍 패러다임 확장 방법에 관한 것입니다.

기발한:

명령형 프로그래밍 분야에서, 우리는 지난 20 년 (또는 그 이상) 동안 객체 지향 (OO)과 서비스 지향 (SO)이라는 두 가지 패러다임을 보았다. 구성 요소 기반 (CB).

두 패러다임 모두 모듈 개념을 도입하여 명령형 프로그래밍 패러다임을 확장합니다. OO는 객체 (및 클래스)를 호출하고 데이터 (필드)와 프로 시저 (메소드)를 모두 캡슐화합니다. 반대로, 데이터 (레코드, Bean 등)를 코드 (구성 요소, 서비스)와 분리합니다.

그러나 OO에는 스몰 토크, C ++, Java 및 기타 모든 JVM 호환, C # 및 기타 모든 .NET 호환, Python 등 기본적으로 패러다임을 지원하는 프로그래밍 언어가 있습니다.

SO에는 그러한 모국어가 없습니다. COM / DCOM (이진, C, C ++), CORBA, EJB, Spring, Guice (모든 Java) 등 절차 적 언어 또는 OO 언어 위에 만 존재합니다.

이러한 SO 프레임 워크는 개념에 대한 모국어 지원 누락으로 분명히 어려움을 겪고 있습니다.

• 서비스와 레코드를 나타 내기 위해 OO 클래스를 사용하기 시작합니다. 이로 인해 메소드 만있는 클래스 (서비스)와 필드 만있는 클래스 (레코드)가 명확하게 구분됩니다. 그런 다음 서비스 또는 레코드 간 상속은 클래스 상속으로 시뮬레이션됩니다. 기술적으로 엄격하게 유지되지는 않지만 일반적으로 프로그래머는 두 역할 중 하나만 수행하도록 수업을하도록 조언받습니다.
• IDL, XML 구성, Java 코드의 주석 또는 Guice와 같은 임베디드 DSL과 같이 누락 된 부분을 나타내는 추가 외부 언어를 사용합니다. 서비스 구성은 서비스 코드 자체의 일부가 아니므로 특히 필요하지만 이에 국한되지는 않습니다. OO에서 객체는 다른 객체를 생성하므로 이러한 기능이 필요하지 않지만 서비스는 다른 서비스를 인스턴스화하거나 구성하지 않기 때문입니다.
• They establish an inner-platform effect on top of OO (early EJB, CORBA) where the programmer has to write all the code that is needed to "drive" SO. Classes represent only a part of the nature of a service and lots of classes have to be written to form a service together. All that boiler plate is necessary because there is no SO compiler which would do it for the programmer. This is just like some people did it in C for OO when there was no C++. You just pass the record which holds the data of the object as a first parameter to the procedure which is the method. In a OO language this parameter is implicit and the compiler produces all the code that we need for virtual functions etc. For SO, this is clearly missing.
• 특히 최신 프레임 워크는 AOP 또는 자체 검사를 광범위하게 사용하여 누락 된 부분을 OO 언어에 추가합니다. 이것은 필요한 언어 표현을 제공하지는 않지만 이전 시점에서 설명한 보일러 플랫폼 코드를 피합니다.
• 일부 프레임 워크는 코드 생성을 사용하여 보일러 플레이트 코드를 생성합니다. XML의 구성 파일 또는 OO 코드의 주석은이 정보의 소스입니다.

위에서 언급 한 모든 현상이 SO에 기인 할 수는 없지만 SO 언어가 필요하다는 것을 분명히 보여주기를 바랍니다. 이 패러다임은 매우 인기가 있기 때문에 왜 없는가? 또는 학문적 인 것이 있지만 적어도 업계에서는 사용하지 않을 수도 있습니다.

코드의 <5 %가 실제로 서비스를 정의하고 있기 때문에 시간이 상당히 줄어 듭니다. 인터페이스가 정의되면 크게 완료됩니다. 나머지 시간은 OO (또는 대안) 가 작업을 수행하는 데 소비됩니다 .

간단히 말해, 문제의 작은 부분에 대해 전문적인 언어를 만드는 것이 큰 승리는 아닙니다. 두 가지 언어 (서비스 용과 구현 / 소 비용)가 모두 통합 복잡성을 추가하는 것입니다.

[해당 애플리케이션 경계가 아닌 내부 애플리케이션 레이아웃임을 OP에서 명확히하기 위해 편집] :

이러한 서비스 레이아웃을 갖는 주요 목표는 서비스 사이에 얇은 접점을 갖는 것입니다. 필자의 원래 이유는 여전히 (imo)를 유지하고 있으며 상대적으로 적은 수의 문제가 서비스 기반의 내부 응용 프로그램 구조에 적합하다는 사실에 대한 해답을 추가합니다. 따라서 작은 부분의 문제를 해결할뿐만 아니라 전반적인 문제의 비율을 줄입니다.

기능적 언어는 핵심적인 서비스 지향적입니다. 객체를 생성하고 함수를 호출하는 대신 함수를 생성하고 메시지를 전달합니다. Erlang은이 기술의 주요 예입니다. 언어의 기능적 측면을 넘어서도 핵심 프레임 워크에 내장 된 프로세스 간 및 시스템 간 통신이 있기 때문에 마치 로컬 프로세스 인 것처럼 원격 프로세스에 메시지를 보낼 수 있습니다. .

Scala, Clojure 및 F #과 같은 다른 언어도 "서비스 지향"의미를 제공합니다. 문제는 그들이 존재하지 않는다는 것이 아니라, 일반 대중이 그들을 두려워하기 때문에 인기가 없다는 것입니다.

서비스 지향은 통합 문제에 대한 구조적 답변이었습니다. 통합은 이상적으로는 기존 언어, 제품, 장치, 리소스를 더 큰 그림에 맞는 포괄적 인 솔루션입니다.

새로운 언어가 필요하지 않습니다. 문제는 이미 너무 많은 언어 를 사용하는 것이므로 상호 운용성 비용이 많이 듭니다.

그러나 웹 서비스 정의 언어라는 한 종류의 언어가 도입되었습니다. WSDL은 SOA의 메타 언어이며 WADL이라는 REST에는 다른 언어가 있습니다.

질문을 뒤집어 놓고 "SO 언어는 어떻게 생겼습니까?"

모듈 간의 계약은 어떻게 작성됩니까?
기본 작동 메커니즘은 어떻게 실행됩니까?

서비스 지향은 응용 프로그램의 속성이며 반드시 사용되는 언어는 아닙니다. 서비스는 기능에 의존하는 구조입니다. 이 함수는 프로그래밍 언어의 메커니즘에 의존하여 연산을 기계 실행 가능 명령어로 변환하는 구문입니다.

BPEL은 SO 언어의 가능한 예이지만 매우 수준이 높으며 사용할 수있는 모듈에 의존합니다. 이러한 모듈은 비 BPEL 언어로 작성되므로 작업을 수행 할 수 있습니다 (일명 기계어로 번역).

좋은 Q와 좋은 순간의 반영을 주었다.

얼마나 많은 사람들이 동의하고 동의하지 않는지 확인하기 위해 본인의 질문에 대한 답변을 제공 할 것입니다.

몇 가지 가능성 :

• SO 언어를 구성하는 것은 어려운 것 같습니다. 주로 서비스 구현과 그 구성이 분리되어 있기 때문입니다. 내가 대학에서 들었던 몇 가지 학문적 해결책이 있습니다 (참조, 죄송합니다).하지만 업계에 적용되지는 않는 것 같습니다. 그러나 나는 이것이 실제적인 이유가 아닌 변명으로 간주합니다. OO 언어와 컴파일러는 구현하기가 매우 어렵지만 오랫동안 시장에 솔루션이 있습니다.

• 프로그래머는 OO를 이해하지 못하고 잘못된 방식으로 사용하기 때문에 OO 언어를 SO에 사용합니다. OO에는 SO와 모순되는 두 가지 기본 개념이 있기 때문에 잘못 말합니다.

  1. 기능은 작업하는 데이터가있는 클래스로 이동합니다. 코드와 데이터는 동일한 모듈에서 함께 연결됩니다. 다른 클래스의 데이터에서 작동하는 별도의 클래스를 갖는 것은 OO 스타일이 아닙니다. 이것이 Züllighofen의 도구 및 재료 접근 방식 (WAM)으로 SO 패러다임과 일치합니다.

  2. 객체는 다른 객체를 만들고 객체의 네트워크를 형성합니다. 계층 구조 나 복잡한 관계를 만들 수 있습니다. 서비스는 항상 외부에서 구성된 플랫 네트워크를 형성합니다. 서비스는 일반적으로 하나의 인스턴스 (Singleton) 만있는 반면, 개체는 해당 개체가 존재하는 한 자주 인스턴스화됩니다. SO의 레코드가 네트워크에 연결되어 있지 않습니다.

• OO의 일부 기능은 SO와 유사하거나 SO에 필요한 기능을 용이하게하기 위해 사용될 수 있으므로 OO 언어를 사용하는 것이 편리합니다.

  1. OO의 의존성 역전 원칙은 서비스가 외부 적으로 구성되는 방식과 유사합니다.

  2. 싱글 톤 객체는 서비스와 같고 객체 팩토리는 서비스 로케이터와 같습니다.

  3. OO에는 서비스 인터페이스와 유사한 인터페이스가 있습니다.

  4. 클래스의 상속은 서비스와 레코드의 상속과 유사 할 수 있습니다.

• OO와 SO는 다양한 종류의 문제에 유용합니다. 따라서 모든 응용 분야에서 패러다임을 여기저기서 사용하고 싶은 유혹이 있습니다. 별도의 언어를 사용하면 동일한 프로그램 내에서 두 언어를 전환하는 데 방해가됩니다.

• SO는 프로그래밍 패러다임 일뿐만 아니라 프로그램 동작이기도합니다. 웹 서비스, 운영 체제 구성 요소 등은 SO이지만 반드시 SO 언어로 작성 될 필요는 없습니다. 이러한 "이진 구성 요소"는 매우 자연스럽고 성공적입니다. 그러나 그것은 다른 것입니다. 프로그램이 내부적으로 통신하는 방식이 아니라 프로그램이 서로 통신하는 방식입니다. 사람들이 자주 섞는 것 같아요.