Phần trên đã mô tả các trường hợp sử dụng cùng với những yêu cầu phức tạp đối với các phương pháp tính toán. Các yêu cầu này có thểđược đáp ứng dễ dàng hơn thông qua một kiến trúc phù hợp với các đặc tính thiết yếu của các trường hợp sử dụng ở trên mà người ta gọi là kiến trúc hướng dịch vụ (SOA – Service Oriented Architecture).
5.1.1 Các yếu tố của kiến trúc hướng dịch vụ
Đểđạt được các ưu điểm trên, SOA quy định các yêu cầu sau:
Kết nối lỏng (Loose coupling) – Không có thuộc tính giao dịch chặt chẽ được áp dụng giữa các thành phần. Nói chung, việc xác định tính nhất quán của dữ liệu là không phù hợp qua các nguồn thông tin từ các bộ phận của các thành phần khác nhau. Tuy nhiên, điều này khá hợp lý cho các mối quan hệ hợp đồng mức cao mà qua đó các tương tác giữa các thành phần được quy định.
Tính trung lập cài đặt (Implementation neutrality) - Giao diện là quan trọng. Chúng ta không thể phụ thuộc vào các chi tiết của việc triển khai các thành phần tương tác. Đặc biệt, phương pháp này không thể cụ thể cho các ngôn ngữ lập trình.
Khả năng cấu hình linh hoạt (Flexible configurability) - Hệ thống được cấu hình trễ và linh hoạt. Nói cách khác, các thành phần khác nhau được ràng buộc với nhau trễ trong quá trình này. Các cấu hình có thể tựđộng thay đổi.
Thời gian hoạt động dài (Long lifetime) - Không nhất thiết phải cần các thành phần có thời gian sống rất lâu. Tuy nhiên, vì chúng ta đang xử lý các tính toán giữa các thành phần không đồng nhất và tự trị trong môi trường động nên luôn cần đến khả năng xử lý các trường hợp ngoại lệ. Điều này có nghĩa là các thành phần phải tồn tại đủ lâu để có thể phát hiện bất kỳ trường hợp ngoại lệ nào có liên quan, để có hành động sửa sai, và đểđáp ứng với các hành
động khắc phục được thực hiện bởi những thành phần khác. Các thành phần phải tồn tại đủ
lâu đểđược khám phá, được dựa vào, và để tạo ra niềm tin trong hành vi.
Mức độ chi tiết (Granularity) – Các bên tham gia một SOA nên được hiểu ở mức thô. Đó là, thay vì mô hình hóa các hành động và tương tác ở một mức độ chi tiết, sẽ tốt hơn để nắm bắt những giá trị cao cấp cần thiết có thể cho thấy mục đích của hợp đồng kinh doanh giữa các thành viên tham gia. Mức thô giúp giảm sự phụ thuộc giữa các thành viên tham gia và làm giảm thông tin cần liên lạc, chỉ cần tập trung với một vài thông điệp có ý nghĩa.
Các nhóm (teams) - Thay vì đóng khung các tính toán một cách tập trung, sẽ tốt hơn khi suy nghĩ về cách thức tính toán được thực hiện bởi các bên tự trị. Nói cách khác, thay vì một bên tham gia chỉ huy các đối tác của mình, tính toán trong hệ thống mở nên là một vấn đề của các đối tác kinh doanh làm việc như một nhóm. Đó là, thay vì một bên riêng lẻ, một nhóm các bên tham gia hợp tác là một mô hình tốt hơn.
5.1.2 So sánh lời gọi thủ tục từ xa (RPC) với định hướng tài liệu (OD)
Có hai khung nhìn chính về dịch vụ Web. Các dịch vụ có thểđược hiểu theo khung nhìn RPC làm trung tâm hoặc tài liệu làm trung tâm. Khung nhìn thứ nhất xem dịch vụ là việc đưa ra một tập các phương pháp được gọi từ xa, nghĩa là, thông qua các cuộc gọi thủ tục từ xa. Khung nhìn sau coi dịch vụ là việc trao đổi tài liệu với nhau. Trong cả hai khung nhìn, những gì được truyền đi là các tài liệu XML và những gì được tính toán là những đối tượng dựa trên hoặc tương ứng với các tài liệu XML. Tuy nhiên, có một sự khác biệt quan trọng về khái niệm.
Khung nhìn RPC xem các tài liệu XML liên quan đến việc tính toán phân phối tổng thể. Các tài liệu chỉ đơn thuần là biểu diễn tuần tự (serialization) của các đối tượng kinh doanh dùng để tính toán. Khung nhìn coi tài liệu làm trung tâm coi tài liệu như biểu diễn (representation) chính và mục đích chính của tính toán phân tán. Mỗi thành phần sẽ đọc, tạo, lưu, và truyền các tài liệu. Các tài liệu được tạm thời hiện thực hóa thành các đối tượng kinh doanh để cho phép tính toán.
Khung nhìn RPC do đó tương ứng với dịch vụ một tấm gỗ dán mỏng của dịch vụ Web trên một ứng dụng hiện có. Ứng dụng này sẽ quyết định những tính năng của dịch vụ sẽ hỗ
trợ. Khung nhìn tài liệu xem xét các dịch vụ Web tự nhiên hơn, coi đó như một phương tiện thực hiện các mối quan hệ kinh doanh. Các văn bản phải được xử lý (và các mối quan hệ của chúng) xác định các chức năng của các dịch vụ. Các đối tượng kinh doanh không được lộ ra cho phía bên kia biết.
Vì lý do này, khung nhìn tài liệu làm trung tâm hợp lý hơn với các trường hợp sử dụng chính của chúng ta trong việc sử dụng các dịch vụ trong môi trường mở. Khung nhìn RPC hợp lý hơn cho trường hợp sử dụng làm cho các ứng dụng đã phát triển liên tác độc lập. Những gì xảy ra là các nhà phát triển ứng dụng thể hiện giao diện ứng dụng của họ trong các hình thức dịch vụ Web, rồi sau đó có thể bị ràng buộc theo cách thông thường. Nếu các ứng dụng được thiết kế hỗ trợ tích hợp phương thức, thì khung nhìn RPC của dịch vụ là hợp lý hơn cho liên tác như vậy. Tuy nhiên, nếu các ứng dụng được thiết kếđể hoạt động như các thành phần độc lập, thì khung nhìn tài liệu sẽ hợp lý hơn, ngay cảđối với liên tác ứng dụng.