일부 응용 프로그램 (모두 C#, C++, Python과 같은 다른 언어로 작성 됨)을 연결하는 방법을 살펴보고 그것에 대해 어떻게해야할지 모르겠습니다.다른 언어로 작성된 응용 프로그램 간 통신
연결하는 것이 의미합니까? 내가 작업하고있는 시스템은 각각 특정 처리 작업을 담당하는 작은 프로그램으로 구성됩니다. 한 응용 프로그램에서 다른 응용 프로그램으로 쉽게 데이터 세트를 전송할 수 있어야합니다. (문제의 데이터 세트는 아마도 몇 메가 바이트가 아닙니다.) 그리고 현재 작업 상태를 제어 할 방법이 필요합니다.
SOAP과 같이 보일 수도 있고 SOAP이 보편적 인 해결책이 될 수도 있지만 사람들이이 주제에 대해 어떻게 생각하는지에 대한 의견을 얻고 싶었습니다.
의견/제안 감사합니다.
나는 개인적으로 ØMQ을 향해 좋아하고 있습니다. 메시지를 전달하기위한 친숙한 BSD 소켓 같은 인터페이스를 가진 라이브러리이지만, 태스크 분산을위한 흥미로운 패턴을 구현한다는 것을 알게 될 것이다.
파이프 라인에 여러 프로세스를 정렬하려는 것처럼 들립니다. ØMQ를 사용하면 밀어 넣기 및 폴링 소켓을 사용하여 작업을 수행 할 수 있습니다. (그리고 이후에는 여러 프로세스와 컴퓨터에서 약간의 노력으로 확장 할 수 있습니다.) 시작하려면 guide을, 그리고 밀어 넣기 및 당기기의 구체적인 방법은 zmq_socket(3) 맨 페이지를 살펴보십시오.
언급 한 모든 언어에 대해 바인딩을 사용할 수 있습니다.
메시지의 내용은 ØMQ 자체가 신경 쓰지 않고 원시 데이터 블록입니다. JSON 또는 Protocol Buffers과 같이 자신에게 적합한 형식을 사용할 수 있습니다.
내가 잘 모르는 부분은 '제어 상태'입니다. 예를 들어 중간에 직장을 취소하는 데 관심이 있습니까?
C# ~ C#의 경우 Windows Communication Foundation을 사용할 수 있습니다. 파이썬과 C++에서도 사용할 수 있습니다.
또한 명명 된 파이프를 체크 아웃 할 수도 있습니다.
WCF는 내가 지원하지 않을 수있는 다른 언어를 통합해야 할 수도 있지만 흥미로운 것 같습니다. 제안 해 주셔서 감사합니다. – Hamza
모든 응용 프로그램에서 볼 수있는 중앙 집중식 데이터를 사용하여 문제를 해결할 수있는 모델로 이동하는 것이 좋습니다. "진실의 원천"을 말하십시오.
불행히도 그건 내 통제 밖에있는 것인데, 나는 단일 언어 방식이 내 인생을 훨씬 쉽게 만들어 줄 것이라고 동의한다. – Hamza
단수의 언어 일 필요는 없다. –
대부분의 외부 소프트웨어는 심볼에 사용되는 이름 - 맹 글링 알고리즘으로 인해 C++ 코드와 연결하는 데 문제가 있습니다. 따라서 다른 언어로 작성된 프로그램과 인터페이스 할 때 래퍼를 extern "C" 또는 extern "C" { 블록으로 선언하는 것이 가장 좋습니다.
머리를 주셔서 감사합니다, 나는 이것을 염두에 두겠습니다 :) – Hamza
내가 쉽게 다른 하나의 응용 프로그램에서 데이터 세트를 전송할 수 있어야
을 사용하여 파일 시스템 (문제의 데이터 세트 것은, 아마도 몇 메가 바이트 큰되지 않습니다).
와 나는 또 다시 작동
의 현재 상태를 제어하는 파일 시스템을 사용하는 방법의 몇 가지 형태가 필요합니다.JSON 직렬화 된 객체가있는 "current_state.json"파일은 여러 언어가 작동하는 데 적합합니다.
소켓처럼 보이거나 SOAP이 보편적 인 해결책 일 수 있습니다.
아마도. 그러나 이런 종류의 일은 과잉입니다. OS에는 이미 필요한 모든 기능이 있습니다. 파일 시스템 만 사용하십시오. 그것은 매우 간단하고 매우 신뢰할 수 있습니다.
제안을 주셔서 감사합니다. 필자는 파일 시스템 접근법을 확실히 고려해 봤지만 SOAP과 같은 구조화 된 프로토콜을 사용하면 데이터와 제어 메시지를 결합하는 것이 더 쉬워 질 것이라고 생각했습니다. – Hamza
"쉽게"? 어떻게 그렇게? 파일 시스템보다 "더 쉽다"는 질문에 몇 가지 예를 제공하십시오. 나는 보통 디렉토리에서 보통 파일보다 더 단순 할 수있는 것을 비워 둔다. 아마 나는 뭔가를 놓치고있다. –
필자는 파일에서 쓰거나 읽는 것보다 더 간단 할 수는 없다는 것에 동의한다. 나는 일관된 데이터/제어 메시지 세트를 시스템 전체에 걸쳐 유지하는 것을 언급했다. (구조화 된 프로토콜이 더 편리 할 수도있다.) 내가 무슨 일이 벌어지고 있는지 추적하기 위해 json 파일을 유지하는 제안 된 방법은별로 문제가되지 않는다. 고려해야 할 또 다른 흥미로운 점은 파일 시스템 대 소켓을 사용하여 구현 된이 시스템의 성능입니다. 나는 간단한 비교를해야 할 수도 있습니다. – Hamza
프로세스 간 통신에는 여러 가지 방법이 있습니다. 앞에서 말한 것처럼 소켓은 보편적 인 솔루션 일 수 있습니다. SOAP은 다소 과잉이라고 생각합니다. 메일 슬롯을 사용할 수도 있습니다. 나는 몇 년 전에 이것을 사용하여 C++ 응용 프로그램을 작성했습니다. 명명 된 파이프도 솔루션 일 수 있지만 Windows에서 코딩하는 경우 어려울 수 있습니다. 제 생각에는
:
가장 좋은 후보입니다.
고마워, 나는 내가 지금 그것을 체크 아웃하러 가기 전에 내가 전에 mailslots에 대해 들어 보지 못했다는 것을 인정해야한다. – Hamza
제안에 감사드립니다. 이것은 매우 흥미로 웠습니다! 파이프 라이닝은 본질적으로 데이터를 여러 하위 응용 프로그램에 포크 처리하고 처리를 마쳐서 다음 단계로 넘어갈 때까지 기다려야 할 것입니다. 여기서는 일종의 국가 검사가 필요합니다. . (거의 다른 프로세스를 통해 데이터를 실행함으로써 유사 동시성과 비슷합니다.) – Hamza
각 하위 애플리케이션은 다음 단계로 작업을 푸시해야합니다. 전체 파이프 라인의 완료를 알리는 한 가지 방법은 pub-sub 소켓을 사용하는 것입니다. 그리고 체인의 마지막 하위 애플리케이션에 일종의 알림을 게시하는 것입니다. 예를 들어, 여러 프로세스가 파이프 라인의 시작 부분에 푸시 소켓을 사용하여 작업을 제출할 수 있으며 각 작업의 ID가 오기를 기다리는 완료 알림에 가입합니다. mongrel2가이를 수행하는 방식입니다. 다음을보십시오 : http://www.igvita.com/2010/09/03/zeromq-modern-fast-networking-stack/ –
이것은 제가 이루려고하는 것과 아주 비슷하게 들리지만, 그 주 동안의 저의 독서 자료처럼 보입니다. 정렬. 많은 제안에 감사드립니다! – Hamza