Tamta’s blog

A Primer for Service-Oriented Architecture (SOA)
By Niel Powers, Vice President of Products for Progress OpenEdge Division
Bản gốc ở đây: http://www.progress.com/

Trong lĩnh vực công nghệ người ta thường hay tìm cách mô tả và định nghĩa những phương pháp tiếp cận mới bằng cách đặc tả những khía cạnh kỹ thuật. Thế là lập tức có ngay những từ viết tắt, những chuẩn, những đặc tính nó có thể đem lại cho người đọc đủ mọi thứ trên đời, chỉ trừ khả năng hiểu được vấn đề.

Thế nên chúng ta hãy thử một cách khác: hãy bàn về SOA từ góc độ doanh nghiệp thuần túy. Yêu cầu của doanh nghiệp luôn thay đổi kéo theo nhu cầu đối với hệ thống IT cũng thay đổi và cuối cùng là các công nghệ, phương pháp và chuẩn cũng phải thay đổi theo. Cách nhìn này khả dĩ giúp chúng ta có một khái niệm chung về SOA cho dù ta đang đứng ở vị trí nào trong doanh nghiệp

Bản chất SOA chỉ đơn thuần là sự đáp ứng đối với một thách thức ngày càng lớn: đó là yêu cầu thực tế thay đổi ngày càng nhanh, đến mức những cấu trúc ứng dụng kiểu truyền thống không còn giải quyết nổi.

Hãy nhìn vào bất cứ một lĩnh vực kinh doanh nào trong thời buổi này, bạn sẽ thấy nó đang thay đổi nhanh và liên tục đến mức không có công ty nào có thể yên vị được. Mỗi ngày họ đều phải outsource bớt công việc, nhận lấy những việc làm mới, tái cấu trúc những quy trình có sẵn và chia sẻ thông tin với đối tác bằng một nhịp điệu mà mấy năm trước có nằm mơ cũng không thấy nổi.

Thế đấy, mọi doanh nghiệp ngày hôm nay đều đòi hỏi mức độ linh hoạt cao hơn, cả ở khả năng thay đổi quy trình và mức độ tương tác giữa các công đoạn nghiệp vụ. Tính linh hoạt được áp dụng vào trong quy trình nghiệp vụ, đó chính là cốt lõi của SOA.

Bài học lịch sử: sản xuất hàng loạt và các thành phần có thể tháo ráp và dùng chung

Thời nửa đầu thế kỷ 19, Eli Whitney and Samuel Colt đã đem đến nhiều thay đổi lớn trong nền công nghệ vũ khí. Hai ông này có nhiều phát kiến, nhưng một trong những cái quan trọng nhất là vũ khí phải được sản xuất hàng loạt và có thể dùng chung phụ tùng với nhau. Ở thời hậu kỹ nghệ ngày nay, điều này nghe có vẻ quá hiển nhiên nhưng thực ra nó đã là một thay đổi lớn thời bấy giờ.

Việc này chẳng qua chỉ nêu bật giá trị của mỗi bộ phận riêng lẻ, giá trị của việc lắp ráp chúng lại với nhau, và giá trị của sản phẩm cuối cùng (là khẩu súng Colt nổi tiếng.) Hẳn nhiên nó còn làm cho việc sửa chữa, lên đời và thiết kế kiểu hàng mới đều dễ dàng hơn. Tin hay không tùy bạn, nhưng đó chính là SOA.

Nếu bằng cách nào đó chúng ta làm phần mềm theo kiểu nó là tập hợp những bộ phận vừa riêng lẻ vừa nói chuyện được với nhau, chúng ta sẽ có những hệ thống IT rất linh hoạt khi cần phải thay đổi, nâng cấp và tái cấu trúc để đáp ứng được nhu cầu của doanh nghiệp.

Để hiểu rõ hơn khái niệm này được áp dụng vào hệ thống phần mềm và CSHT IT như thế nào, chúng ta cần phải chẻ vấn đề ra làm hai phần: (1) là những ứng dụng riêng lẻ có thể thay thế được và (2) là hệ thống nền để các ứng dụng trên có thể nói chuyện được với nhau

Đến đây thì lại không tránh khỏi phải đi sâu vào kỹ thuật một xíu, đầu tiên là những ứng dụng thành phần

Phần mềm ứng dụng = các tập quán nghiệp vụ tốt nhất được lập trình.

Tất cả mọi ứng dụng doanh nghiệp đều được thiết kế để tiếp nhận một nghiệp vụ nào đó và tự động hóa nó. Nói như một người bạn của tôi thì “Phần mềm ứng dụng chẳng qua chỉ là quan điểm của một người nào đó về quy trình tối ưu để xử lý công việc, được phát biểu và lập trình nên mà thôi”

Có vẻ không quá phức tạp, có điều phần lớn những ứng dụng này bao gồm nhiều quy trình xử lý khác nhau, nhưng lại được lập trình chung với nhau như một khối không thể tách rời. Hậu quả là không hề có sự linh hoạt: ứng dụng sẽ bao gồm những quy trình cứng nhắc, các thành phần tương tác với nhau một cách cứng nhắc và phương pháp triển khai những thành phần này đã được định sẵn, không thay đổi gì được. SOA nhắm đến việc thay đổi cấu trúc khô cứng này bằng một cấu trúc khác trong đó các nghiệp vụ thành phần đã được mô tả rõ ràng và được triển khai như thể chúng là những dịch vụ riêng rẽ

Mỗi ‘dịch vụ’ sẽ tương ứng với một nghiệp vụ cụ thể nào đó với những chức năng và giới hạn đã đuợc định nghĩa rõ ràng. Đây là phần thực thi của SOA. Dưới đây là một ví dụ:

Một phần mềm xử lý đơn hàng thực chất là tập hợp của một số nghiệp vụ riêng rẽ đã được tự động hóa. Những nghiệp vụ này bao gồm kiểm tra công nợ khách hàng; kiểm tra hàng tồn kho; xác định giá và khấu trừ; tính thuế và cước vận chuyển; in hợp đồng, chứng từ và hóa đơn; cuối cùng là ghi sổ kế toán. Như đã nói, phần lớn phần mềm ứng dụng không tách rời những nghiệp vụ này để chúng có thể gỡ ra từng phần và thay thế được. Bởi vậy nên rất khó có thể thay đổi quy trình kiểm tra công nợ, khó outsource được việc tính thuế mặc dù có dịch vụ làm được việc này tốt hơn, và kết quả của chương trình kiểm soát tồn kho khó có thể được dùng bởi những phần mềm khác.

Tự bản thân SOA không thay đổi được cách nhìn, nhưng nó có thể giúp doanh nghiệp thay đổi cách nhìn một cách nhanh chóng để thích ứng với môi trường kinh doanh.

SOA đề xuất việc thay thế ứng dụng nói trên bằng một ứng dụng khác với kiểu thiết kế, lập trình và triển khai trong đó mỗi nghiệp vụ là một kiểu ‘dịch vụ’ với đầy đủ tính mềm dẻo linh hoạt mà những ứng dụng kiểu cũ không thể có được. Các ‘dịch vụ’ này có thể có cùng chức năng như trước kia, nhưng lại được triển khai theo kiểu hoàn toàn khác. Trong mô hình mới này, mỗi ứng dụng được hình thành từ một hoặc nhiều dịch vụ, mỗi dịch vụ tương ứng với một loại nghiệp vụ riêng biệt nhưng tất cả các dịch vụ này đều tương tác với nhau để cùng giải quyết những vấn đề thực tế và tự động hóa các chức năng nghiệp vụ.

Các chuẩn tương tác là tiền đề cho một giải pháp SOA toàn diện

Tất nhiên sẽ chẳng có ‘dịch vụ’ nào thực sự có ích nếu chúng không cùng làm việc với nhau. Chẳng có ai muốn một hệ thống trong đó có một phần cung cấp thông tin công nợ, phần khác quản lý tồn kho, phần nữa dùng để tính thuế nhưng chẳng có phần nào làm việc với nhau. Hiển nhiên người ta cần một hệ thống nền để chúng có thể thông tin với nhau, hệ thống này phải mạnh, chuẩn, dễ triển khai và mềm dẻo để có thể đáp ứng những nhu cầu ngày càng phức tạp. Vậy khi các nghiệp vụ tiến hóa thành ‘dịch vụ,’ cần phải có một hệ thống đóng vai trò nền tảng để các dịch vụ đó có thể làm việc được với nhau.

Đây chính là điểm mà SOA có thể tận dụng được nhiều chuẩn dữ liệu vừa được phát triển trong vài năm gần đây. Mặc dù bản chất SOA không hẳn được chuẩn hóa như người ta trông đợi, nhưng phần lớn những ứng dụng SOA đã cùng sử dụng chung một số chuẩn trao đổi dữ liệu giống nhau.

Các chuẩn trao đổi dữ liệu và giao thức trên nền Internet được xem là chuẩn của các hạ tầng thông tin, và XML làm nên nền tảng của các chuẩn SOA như SOAP và WSDL

Tuy nhiên việc trao đổi dữ liệu không hề dễ dàng. Hãy thử lấy ví dụ về việc giao tiếp giữa con người với con người. Người ta phải suy tính để chọn đúng ngôn ngữ, đúng từ ngữ, chủ đề, phương tiện và giao thức. Giao tiếp giữa dịch vụ với dịch vụ cũng cần phải tính toán như vậy, có điều là nó yêu cầu mức độ chính xác và tính tiên định cao hơn. SOA đã có thể giải quyết được một số vấn đề thông qua các chuẩn XML, SOAP, WSDL và UDDI; nhưng người ta vẫn cần phải thiết lập những giao thức và chuẩn mới ở mức ứng dụng và ở mức phổ quát nhất.

Bây giờ chúng ta hãy tiếp tục ví dụ ở trên:

Đối với hệ thống xử lý đơn hàng theo kiểu hướng dịch vụ của chúng ta, phần công nợ được tách rời khỏi phần tính giá, phần tính giá tách rời khỏi phần tồn kho và những phần khác. Thế nên cần phải có một hệ các chuẩn để các phần này có thể dựa trên đó mà làm việc với nhau một cách hiệu quả. Module công nợ cần phải có thông tin gì? Nó có thể trả lời những câu hỏi nào và trả ra những kết quả gì? Cùng một mã hàng có được hiểu một cách thống nhất ở các modules khác nhau không?

Vậy thì chúng cần phải tuân theo giao thức nào nếu module xử lý đơn hàng cần lấy thông tin từ module tính giá và yêu cầu đó không được đáp ứng trong thời gian cho phép? Nếu module kế toán báo lỗi, các modules khác sẽ phản ứng thế nào? Tất cả các câu hỏi này đều phải được trả lời nếu muốn các modules có thể làm việc được với nhau.

Hai thành phần cốt yếu của SOA
Đến đây chúng ta đã có hai thành phần cốt yếu của SOA

1) Các module nghiệp vụ được thể hiện thành những dịch vụ được định nghĩa rõ ràng, và
2) một hạ tầng trao đổi thông tin hỗ trợ việc kết nối tất cả các dịch vụ nói trên thành một ứng dụng liền lạc

Hẳn nhiên những thứ trên đây đều chỉ là lý thuyết, và chúng ta ai cũng biết từ lý thuyết đến thực tế là cả một quãng đường dài. Vậy chúng ta cũng nên nói về một số huyền thoại về SOA cũng như một số anh em họ hàng của nó là SOBA (Service Oriented Business Applications) và SODA (Service Oriented Development of Applications)