Tại sao không có ngôn ngữ hướng dịch vụ?

Biên tập:

Để tránh nhầm lẫn thêm: Tôi không nói về các dịch vụ web và như vậy. Tôi đang nói về cấu trúc các ứng dụng trong nội bộ, nó không phải là về cách máy tính giao tiếp. Đó là về ngôn ngữ lập trình, trình biên dịch và cách mô hình lập trình mệnh lệnh được mở rộng.

Nguyên:

Trong lĩnh vực lập trình bắt buộc, chúng ta đã thấy hai mô hình trong 20 năm qua (hoặc hơn): hướng đối tượng (OO) và hướng dịch vụ (SO) aka. dựa trên thành phần (CB).

Cả hai mô hình mở rộng mô hình lập trình mệnh lệnh bằng cách đưa ra khái niệm mô-đun của riêng họ. OO gọi chúng là các đối tượng (và các lớp) và cho phép chúng gói gọn cả dữ liệu (trường) và thủ tục (phương thức) với nhau. Ngược lại, SO tách dữ liệu (bản ghi, đậu, ...) khỏi mã (thành phần, dịch vụ).

Tuy nhiên, chỉ có OO có các ngôn ngữ lập trình hỗ trợ mô hình của nó: Smalltalk, C ++, Java và tất cả các tương thích JVM khác, C # và tất cả các tương thích .NET khác, Python, v.v.

SO không có ngôn ngữ bản địa như vậy. Nó chỉ tồn tại trên các ngôn ngữ thủ tục hoặc ngôn ngữ OO: COM / DCOM (nhị phân, C, C ++), CORBA, EJB, Spring, Guice (tất cả Java), ...

Các khung SO này rõ ràng phải chịu sự hỗ trợ ngôn ngữ bản địa bị thiếu trong các khái niệm của chúng.

• Họ bắt đầu sử dụng các lớp OO để đại diện cho các dịch vụ và hồ sơ. Điều này dẫn đến các thiết kế trong đó có sự phân biệt rõ ràng giữa các lớp chỉ có phương thức (dịch vụ) và các lớp chỉ có trường (bản ghi). Kế thừa giữa các dịch vụ hoặc bản ghi sau đó được mô phỏng bằng sự kế thừa của các lớp. Về mặt kỹ thuật, nó không được giữ nghiêm ngặt như vậy nhưng nói chung các lập trình viên được khuyến khích làm cho các lớp chỉ đóng một trong hai vai trò.
• Họ sử dụng các ngôn ngữ bên ngoài bổ sung để thể hiện các phần còn thiếu: IDL, cấu hình XML, Chú thích trong mã Java hoặc thậm chí DSL được nhúng như trong Guice. Điều này đặc biệt cần thiết, nhưng không giới hạn, vì thành phần của các dịch vụ không phải là một phần của mã dịch vụ. Trong OO, các đối tượng tạo các đối tượng khác để không cần các phương tiện như vậy nhưng đối với SO thì có vì các dịch vụ không khởi tạo hoặc định cấu hình các dịch vụ khác.
• Họ thiết lập một hiệu ứng nền tảng bên trong trên OO (EJB, CORBA đầu tiên) trong đó lập trình viên phải viết tất cả các mã cần thiết để "lái" SO. Các lớp chỉ đại diện cho một phần bản chất của dịch vụ và rất nhiều lớp phải được viết để tạo thành một dịch vụ cùng nhau. Tất cả các tấm nồi hơi là cần thiết bởi vì không có trình biên dịch SO sẽ làm điều đó cho lập trình viên. Điều này giống như một số người đã làm nó trong C cho OO khi không có C ++. Bạn chỉ cần truyền bản ghi chứa dữ liệu của đối tượng làm tham số đầu tiên cho thủ tục là phương thức. Trong ngôn ngữ OO, tham số này là ẩn và trình biên dịch tạo ra tất cả mã mà chúng ta cần cho các hàm ảo, v.v. Đối với SO, điều này rõ ràng là thiếu.
• Đặc biệt là các khung mới hơn sử dụng rộng rãi AOP hoặc hướng nội để thêm các phần còn thiếu vào ngôn ngữ OO. Điều này không mang lại tính biểu cảm ngôn ngữ cần thiết nhưng tránh được mã nền tảng nồi hơi được mô tả ở điểm trước.
• Một số khung sử dụng tạo mã để sản xuất mã tấm nồi hơi. Các tệp cấu hình trong XML hoặc các chú thích trong mã OO là nguồn thông tin cho việc này.

Không phải tất cả các hiện tượng mà tôi đã đề cập ở trên có thể được quy cho SO nhưng tôi hy vọng nó cho thấy rõ ràng rằng cần có một ngôn ngữ SO. Vì mô hình này rất phổ biến: tại sao không có? Hoặc có thể có một số học thuật nhưng ít nhất ngành công nghiệp không sử dụng một.

Bởi vì <5% mã thực sự đang xác định một dịch vụ và tôi sẽ tranh luận về lượng thời gian ít hơn đáng kể. Khi giao diện được xác định, phần lớn được thực hiện. Thời gian còn lại được dành cho OO (hoặc giải pháp thay thế) làm cho mọi thứ hoạt động .

Nói một cách đơn giản, đó không phải là một chiến thắng lớn để tạo ra một ngôn ngữ chuyên biệt cho vấn đề nhỏ đó. Nếu bất cứ điều gì, có hai ngôn ngữ (một cho dịch vụ và một cho việc thực hiện / tiêu thụ) chỉ là yêu cầu thêm độ phức tạp tích hợp.

[chỉnh sửa để làm rõ OP rằng bố cục ứng dụng bên trong, không phải ranh giới ứng dụng]:

Mục tiêu chính của việc bố trí dịch vụ như vậy là có các điểm tiếp xúc mỏng giữa các dịch vụ. Lý do ban đầu của tôi vẫn giữ (imo) và thêm vào câu trả lời đó là thực tế rằng tương đối ít vấn đề phù hợp với chính họ đối với cấu trúc ứng dụng nội bộ dựa trên dịch vụ. Vì vậy, không chỉ bạn đang giải quyết một lát nhỏ của vấn đề, mà tỷ lệ phần trăm vấn đề thấp hơn nói chung.

Ngôn ngữ chức năng là rất dịch vụ định hướng cốt lõi của họ. Thay vì tạo các đối tượng và gọi các hàm trên chúng, bạn tạo các hàm và truyền tin nhắn cho chúng. Erlang là một ví dụ điển hình của kỹ thuật này bởi vì thậm chí vượt ra ngoài các khía cạnh chức năng của ngôn ngữ mà nó có giao tiếp giữa các quá trình và thậm chí giữa các máy được xây dựng trong khung cốt lõi của nó cho phép bạn gửi tin nhắn đến một quy trình từ xa như thể đó là một quy trình cục bộ .

Các ngôn ngữ khác như Scala, Clojure và F # cũng cung cấp ngữ nghĩa "hướng dịch vụ". Vấn đề không phải là họ không tồn tại, mà là dân chúng nói chung sợ họ và vì vậy họ không phổ biến.

Định hướng dịch vụ là / là một câu trả lời kiến ​​trúc cho các vấn đề tích hợp. Tích hợp lý tưởng là một giải pháp bao gồm tất cả phù hợp với bất kỳ ngôn ngữ, sản phẩm, thiết bị, tài nguyên hiện có nào thành một bức tranh lớn hơn.

Không cần một số ngôn ngữ mới, vì vấn đề rất lớn là đã có quá nhiều ngôn ngữ , điều này gây ra chi phí tương tác cao.

Tuy nhiên, có một loại ngôn ngữ được giới thiệu, ngôn ngữ định nghĩa dịch vụ web. WSDL là ngôn ngữ meta của SOA (và có một ngôn ngữ bị bỏ rơi khác cho REST có tên WADL)

Tôi sẽ chuyển câu hỏi và hỏi "ngôn ngữ SO sẽ trông như thế nào?"

Làm thế nào những hợp đồng giữa các mô-đun sẽ được viết?
Làm thế nào các cơ chế hoạt động cơ bản sẽ được thực hiện?

Dịch vụ định hướng là một tài sản của ứng dụng, không nhất thiết phải là ngôn ngữ được sử dụng. Dịch vụ này là một cấu trúc dựa trên một chức năng. Hàm này là một cấu trúc dựa trên cơ chế của ngôn ngữ lập trình để dịch hoạt động thành các hướng dẫn thực thi của máy.

BPEL là một ví dụ có thể có của ngôn ngữ SO, nhưng nó ở mức rất cao và phụ thuộc vào các mô-đun có sẵn để sử dụng nó. Các mô-đun này lần lượt được viết bằng các ngôn ngữ không phải là BPEL để có thể thực hiện công việc (còn được dịch sang ngôn ngữ máy).

Q tuyệt vời và đã cho tôi một khoảnh khắc tuyệt vời.

Tôi sẽ đưa ra câu trả lời cho câu hỏi của riêng tôi để xem có bao nhiêu người đồng ý và không đồng ý.

Một số khả năng:

• Có vẻ như rất khó để xây dựng một ngôn ngữ SO. Chủ yếu là do sự tách biệt của việc thực hiện các dịch vụ và thành phần của chúng. Có một vài giải pháp học thuật mà tôi đã nghe nói ở trường đại học (không có tài liệu tham khảo, xin lỗi) nhưng dường như nó không được đưa vào ngành. Nhưng tôi coi đây là một cái cớ, không phải là một lý do thực sự. Các ngôn ngữ và trình biên dịch OO cũng khá khó thực hiện, tuy nhiên vẫn có những giải pháp trên thị trường trong một thời gian dài.

• Các lập trình viên sử dụng ngôn ngữ OO cho SO vì họ không hiểu OO và sử dụng sai ngôn ngữ. Tôi nói sai vì có hai khái niệm cơ bản trong OO mâu thuẫn với SO:

  1. Chức năng đi đến lớp nơi dữ liệu được đặt mà chúng làm việc. Mã và dữ liệu được ghép với nhau trong cùng một mô-đun. Không phải kiểu OO để có các lớp riêng biệt hoạt động trên dữ liệu của các lớp khác. Đó là cách tiếp cận Công cụ và Vật liệu (WAM) của Züllighofen phù hợp với mô hình SO.

  2. Các đối tượng tạo các đối tượng khác và tạo thành mạng lưới của các đối tượng. Họ có thể tạo ra thứ bậc hoặc bất cứ mối quan hệ phức tạp nào. Các dịch vụ luôn hình thành các mạng phẳng được cấu tạo từ bên ngoài. Các dịch vụ thường chỉ có một phiên bản (Singleton) trong khi các đối tượng được khởi tạo thường xuyên như thực thể mà chúng đại diện tồn tại. Các bản ghi trong SO không được kết nối trong các mạng.

• Một số tính năng của OO trông tương tự như SO hoặc có thể được sử dụng để tạo điều kiện thuận lợi cho những gì cần thiết cho SO để sử dụng ngôn ngữ OO trở nên hữu ích.

  1. Nguyên tắc đảo ngược phụ thuộc trong OO tương tự như cách các dịch vụ được cấu thành bên ngoài.

  2. Đối tượng Singleton giống như dịch vụ, nhà máy đối tượng giống như người định vị dịch vụ.

  3. OO cũng có giao diện tương tự như giao diện dịch vụ.

  4. Kế thừa các lớp có thể tương tự (giống nhau?) Như kế thừa các dịch vụ và hồ sơ.

• OO và SO rất hữu ích cho các loại vấn đề khác nhau. Vì vậy, trong mọi ứng dụng, việc sử dụng mô hình ở đây hoặc ở đó là rất hấp dẫn. Có một ngôn ngữ riêng sẽ cản trở việc chuyển đổi giữa hai ngôn ngữ trong cùng một chương trình.

• SO không chỉ là một mô hình lập trình mà còn là một hành vi của chương trình: dịch vụ web, các thành phần hệ điều hành, v.v. là SO nhưng không nhất thiết phải được viết bằng ngôn ngữ SO. Loại "thành phần nhị phân" này rất tự nhiên và thành công. Nhưng đó là một điều khác biệt: đó là cách các chương trình giao tiếp với nhau, không phải cách chương trình giao tiếp bên trong. Tôi đoán mọi người trộn nó lên thường xuyên đủ.