Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 6: Mô hình thành phần tiến hoá

Một cách tiếp cận có hệ thống để triển khai thực hiện SOA

Một mô hình lập trình dựa trên thành phần, trung lập với ngôn ngữ dành cho kiến trúc hướng dịch vụ (SOA) tạo điều kiện cho việc triển khai thực hiện các dịch vụ web và lắp ráp chúng thành các giải pháp. Mô hình lập trình này cho phép các lập trình viên không chuyên sử dụng các tài sản công nghệ thông tin (CNTT) hiện có mà không cần phải thành thạo các công nghệ phức tạp. Nó đáp ứng các nhu cầu của các nhà thiết kế giải pháp và các nhà phân tích nghiệp vụ, cung cấp một mức độ trừu tượng hóa cao hơn, che giấu sự khác biệt giữa các công nghệ thực thi, nhưng vẫn cho phép hoàn thành trách nhiệm về nghiệp vụ.

Donald Ferguson, Kiến trúc sư trưởng SWG, IBM Corporation

Tiến sĩ Donald F. Ferguson là một trong 55 ủy viên Hội đồng IBM, vị trí kỹ thuật cao nhất trong cộng đồng kĩ nghệ của IBM gồm 200.000 các nhà kỹ thuật chuyên nghiệp. Don là kiến trúc sư trưởng và nhà lãnh đạo kỹ thuật của Tập đoàn phần mềm IBM gồm dòng các sản phẩm Lotus, Rational, WebSphere, DB2. Don là chủ tịch Hội đồng Kiến trúc SWG, tập hợp các kiến trúc sư của các sản phẩm hàng đầu của SWG. Mọi nỗ lực mới đây nhất của Don đều tập trung vào các dịch vụ web, quản lý quá trình nghiệp vụ, nền tảng máy khách, nền tảng gia công/lưu trữ trên máy chủ, các dịch vụ Lưới (Grid) và phát triển ứng dụng cho WebSphere. Don đã là kiến trúc sư trưởng cho dòng các sản phầm WebSphere từ lúc khởi đầu cho đến khi đảm nhận vai trò kiến trúc sư trưởng của SWG vào năm 2003



Marcia Stockton, Kỹ thuật viên cao cấp, IBM

Marcia L. Stockton là thành viên của ban lãnh đạo kỹ thuật cao cấp và là một nhà phát minh chính của Tổ hợp phần mềm IBM tại Công viên tam giác nghiên cứu (Research Triangle Park), Bắc Carolina (cư trú tại California). Bà cũng là một thành viên IEEE cấp cao. Marcia lãnh đạo Nhóm công tác về mô hình lập trình của Hội đồng Kiến trúc của Tổ hợp phần mềm, ở đây bà lãnh đạo thực hiện các sáng kiến tích hợp ngang hàng và khuyến khích làm đơn giản hóa mô hình lập trình trên các sản phẩm của Lotus, Rational, WebSphere, DB2 và Tivoli. 73 bằng sáng chế Hoa Kỳ của bà bao trùm các lĩnh vực từ mạng, Web, an ninh, bảo mật, đa phương tiện, không dây, các thiết bị lan tỏa (pervasive) cho tới mã nhận dạng tần số vô tuyến. Mới đây bà lãnh đạo việc định nghĩa kiến trúc quản lý nhân dạng (identity) và về việc lập trình phân tán phía máy chủ. Bà đến với IBM vào năm 1988 sau năm năm phát triển phần mềm mạng. Bà đã có bằng cử nhân văn chương (B.A.) của trường Cao đẳng Swarthmore vào năm 1975



Martin Nally, Kỹ sư trưởng, IBM

Martin Nally là một kỹ sư xuất sắc của IBM, người đã gia nhập IBM từ năm 1990 với 10 năm kinh nghiệm trong ngành công nghiệp trước đó. Ông đã là kiến trúc sư và nhà phát triển hàng đầu của VisualAge Smalltalk của IBM và là kiến trúc sư hàng đầu và giám đốc phát triển tổng thể của WebSphere Studio của IBM. Ông đã thiết kế và xây dựng các công cụ và thiết kế mô hình lập trình trừu tượng hóa trong hơn 10 năm qua. Chức vụ hiện nay của ông là Giám đốc kỹ thuật, Phần mềm Rational của IBM



10 07 2009

Tại sao cần một mô hình lập trình dựa trên thành phần?

Tầm nhìn thúc đẩy mô hình lập trình SOA của IBM đã dựa trên hai nhận xét chính, tóm lược rất đúng trong các đoạn trích dẫn dưới đây:

"Thường hay diễn ra việc trình bày thiết kế bằng lời nói thông thường (buzzword). Ít nhất một số trường hợp hành xử như thế trong ngành công nghiệp phần mềm là do còn thiếu hiểu biết về lý do tại sao một tập hợp nào đó các điều kiện ràng buộc về kiến trúc là hữu ích. Nói cách khác, lập luận hậu thuẫn cho các kiến trúc phần mềm tốt là chưa hiển nhiên đối với các nhà thiết kế khi các kiến trúc đó được chọn để tái sử dụng".
-- Roy Thomas Fielding đã viết như thế trong "Các phong cách kiến trúc và Thiết kế các Kiến trúc phần mềm dựa trên mạng " (Xem Tài nguyên để tìm đường liên kết tới bản luận án này).

Vấn đề này có thể được khắc phục bằng cách thể hiện kinh nghiệm của những người có hiểu biết tỉ mỉ về những lý do đằng sau các ràng buộc kiến trúc thành một bộ các mẫu, các tạo phẩm lập trình và các công cụ.

Nhận xét quan trọng thứ hai gắn liền với con người và cách con người tương tác với công nghệ như thế nào:

"Việc tạo ra các giải pháp kiến trúc hướng dịch vụ (SOA) có nghĩa là phải suy tính lại các thông lệ hiện nay đang áp dụng để xây dựng các hệ thống, các kỹ năng trong một tổ chức và các cách thức mà các thành viên trong nhóm cộng tác với nhau. Định hướng dịch vụ góp phần vào việc phát triển các giải pháp, được lắp ráp từ các ứng dụng hỗn độn và SOA là một phong cách kiến trúc nhấn mạnh đến sự ghép lỏng các bên cung cấp dịch vụ độc lập".
-- A.W. Brown và các cộng sự đã viết như vậy trong bài báo "Nhận thức rõ các giải pháp hướng dịch vụ với nền tảng phát triển phần mềm IBM" (Xem Tài nguyên để có đường liên kết đến bài báo này).

Các tiêu chuẩn dịch vụ Web dựa trên XML, đã gợi ý các khía cạnh của một mô hình lập trình dựa trên thành phần. Các tiêu chuẩn như: Tính tương tác giữa các dịch vụ Web (WS-I), Ngôn ngữ mô tả dịch vụ Web (WSDL) và Chính sách dịch vụ Web (WS-Policy) cố gắng tạo ra một sự trừu tượng hóa không cần biết nền tảng (platform-agnostic abstraction) và một khung công tác phổ quát chung cho việc tích hợp phần mềm nghiệp vụ. Ngược lại, giá trị của các dịch vụ web được rút ra từ việc sử dụng chúng trong một SOA.

Hầu hết các tài liệu về các dịch vụ Web tập trung vào các giao thức liên tác, các giao diện dịch vụ và việc sử dụng chúng. Thay vào đó, bài viết này tập trung vào mô hình lập trình để triển khai thực hiện các dịch vụ và lắp ráp chúng thành các giải pháp. Một mô hình thành phần sẽ làm đơn giản hoá quá trình xây dựng và lắp ráp các dịch vụ.

Một mô hình thành phần được định nghĩa tốt sẽ cho phép một hệ sinh thái rộng lớn của các vai trò của người sử dụng -- ví dụ như nhà phân tích nghiệp vụ, nhà phát triển tích hợp, nhà phát triển bộ tiếp hợp và các nhà quản trị giải pháp -- tạo ra các ứng dụng hướng dịch vụ bằng cách khởi tạo các cá thể, sử dụng, lắp ráp và tùy biến các loại thành phần khác nhau sao cho khớp với các mục tiêu, các kỹ năng và các khung công tác thiết kế của người sử dụng. (Lưu ý: Việc lập trình vẫn còn tồn tại như là một nghề nghiệp và một vai trò phát triển phần mềm quan trọng, nhưng không phải tất cả mọi người đều phải là một lập trình viên chuyên nghiệp để làm việc hiệu quả với các tạo phẩm SOA).

Mô hình thành phần của chúng ta, dựa trên các tiêu chuẩn dịch vụ Web, đã thêm một định nghĩa sinh động về các thành phần và các kiểu thành phần và cách thức làm thế nào để các thành phần được định nghĩa và được cấu trúc để tái sử dụng và chế biến bằng các công cụ phù hợp với vai trò, đáp ứng các quan sát của chúng ta về khía cạnh con người trong sử dụng công nghệ.

Một mô hình lập trình dựa trên-thành phần có nhiều lợi ích, đáng kể nhất là giảm sự phức tạp. Không có một vai trò đơn lẻ nào cần phải hiểu được tất cả các cách có thể để thực hiện một chức năng hay phải hiểu được tất cả các giao diện của một hệ thống. Sự phức tạp mà từng vai trò phải đối mặt là có giới hạn và các vai trò nhà phát triển khác nhau đóng góp vào giải pháp theo cách được xác định rõ ràng, sử dụng các công cụ phù hợp với các nhiệm vụ của chúng.

Một mô hình thành phần phải là trừu tượng và trung lập với ngôn ngữ, bởi vì vai trò của nó là để che giấu các chi tiết và các khác biệt công nghệ.

Nó cũng phải tạo điều kiện cho các lập trình viên không chuyên lắp ráp và liên kết "các mảnh giải pháp". Vì vậy, tất cả các khía cạnh của một thành phần (hoặc một tập hợp các thành phần) có liên quan đến việc lắp ráp và đo cắt được khai báo rõ ràng theo một cách thức trung lập với ngôn ngữ, sao cho chúng có thể được thao tác bằng các công cụ mà không cần đến một lập trình viên sửa đổi mã nguồn. Chúng ta sử dụng XML để diễn đạt các khai báo này.

Một định nghĩa mô tả chính xác SOA có thể vẫn còn phải bàn cãi, nhưng đã có sự chấp nhận rộng rãi về một số khía cạnh quan trọng:

  1. SOA là một kiến trúc thành phần phân tán (distributed component). Các thành phần SOA được đặt một cách trong suốt bên trong hay ở bên ngoài hệ thống doanh nghiệp và có thể truy cập từ khắp mọi nơi như là các dịch vụ thông qua các giao thức thông báo và gọi thủ tục từ xa liên tác với nhau, được hỗ trợ khắp mọi nơi. Các tiêu chuẩn định nghĩa giao diện cho phép liên tác giữa các công cụ của nhà phát triển. Trên đường kết nối Tính liên tác của giao thức -- đối lập với dễ di chuyển (portability) mã -- là là vấn đề trọng tâm của các tương tác thành phần SOA, cho phép truy cập khắp mọi nơi và độc lập với nền tảng. Bên gọi dịch vụ không cần biết về công nghệ thực hiện nằm bên dưới các thành phần, ví dụ như Java™ 2 Platform, Enterprise Edition (J2EE), Microsoft® .Net và PHP.
  2. Các thành phần SOA bao gói các chức năng và cho phép tái sử dụng ở mức độ trừu tượng được mô hình hóa bởi nhà phân tích nghiệp vụ và các mô hình nghiệp vụ. Điều này có thể tăng cường trách nhiệm bằng cách ánh xạ trực tiếp hơn một chức năng CNTT với chức năng nghiệp vụ mà nó hỗ trợ.
  3. Các hợp đồng có thể xử lý bằng máy, tuyên bố rõ ràng cho phép các bên thứ ba truy cập vào các dịch vụ do một thành phần SOA tạo ra. Các hợp đồng này nói rõ các đặc điểm chức năng cũng như các khả năng và các yêu cầu phi chức năng (chất lượng của dịch vụ, hay QoS). Các thành phần SOA chú thích các hoạt động của chúng bằng cách sử dụng WSDL. Ngôn ngữ thi hành qui trình nghiệp vụ cho các Dịch vụ Web (BPEL4WS) cũng có thể được sử dụng để định nghĩa các chuỗi các hoạt động hợp lệ trên một thành phần.
  4. Các thành phần SOA có thể được tìm kiếm, lựa chọn và bị ràng buộc theo phương thức động bởi các thuộc tính khai báo của chúng và được tích hợp bằng cách sử dụng các cơ chế phối hợp, giống như những cơ chế được mô tả trong Phần 3 ở loạt bài này "Process choreography and business state machines" (developerWorks, 07.2005).

Việc thực hiện các thành phần và các kiểu thành phần đặc biệt

Một nhà phát triển có thể chọn để triển khai thực hiện các thành phần cơ bản, sử dụng J2EE, PHP hoặc các công cụ khác. SOA với vai trò là một mô hình lập trình, quan tâm cơ bản hơn đến các tương tác thành phần và sự tích hợp chúng thành các thành phần phức hợp, các ứng dụng và các giải pháp mới.

Mô hình lập trình của chúng ta cũng giới thiệu các kiểu thành phần được định nghĩa rõ ràng để mô hình hóa các loại tạo phẩm phổ biến mà các nhà phát triển tạo ra và triển khai vào trong các giải pháp. Các ví dụ bao gồm các đối tượng thuần Java (POJOs), các qui trình nghiệp vụ (BPEL4WS), các dịch vụ của Ngôn ngữ truy vấn có cấu trúc (SQL), Các đối tượng nghiệp vụ tự thích nghi, các chương trình của Hệ thống kiểm soát thông tin khách hàng (CICS) được truy cập thông qua các bộ tiếp hợp tài nguyên của kiến trúc Đầu nối J2EE (J2C), các ứng dụng sử dụng giao diện lập trình ứng dụng nghiệp vụ của SAP, các bean phiên không trạng thái J2EE và các ứng dụng MQSeries® của IBM.

Do bản chất ảo của mô hình thành phần SOA, nhiều thành phần SOA hỗ trợ tự nhiên cho nhiều công nghệ thực hiện. Mặt khác, các công nghệ thực hiện khác nhau là thích hợp hơn cho các nhiệm vụ khác nhau. Để cải thiện tính trong suốt, chúng tôi giới thiệu khái niệm về các kiểu thành phần dịch vụ, mỗi kiểu thích hợp cho một nhà phát triển với một tập hợp kỹ năng nhất định, thực hiện một nhiệm vụ cụ thể và sử dụng một công cụ nhất định. Đối với các truy vấn, lập trình viên thực hiện một tệp tin SQL và một tệp tin có chứa một tập hợp các câu lệnh XQuery; để chuyển đổi tài liệu, các phiếu định kiểu XSLT, v.v được triển khai thực hiện bằng cách sử dụng các công cụ được tối ưu hóa cho nhiệm vụ này. Không cần thiết phải biết rằng một dịch vụ Web, JavaBean cho doanh nghiệp (EJB) hay các tạo phẩm khác được tạo ra khi triển khai, chỉ cần kết quả tổng thể sẽ được đưa ra và sẵn sàng để sử dụng như là một thành phần SOA chung nhất.

Các lập trình viên xây dựng một kiểu thành phần cụ thể, thích nghi với nhiệm vụ, tập trung vào vấn đề phải giải quyết và công cụ để thực hiện việc này, chứ không phải tập trung vào các tạo phẩm kết quả. Các công cụ phát triển SOA nên tập trung vào các kỹ năng của nhà phát triển và các khái niệm mà họ hiểu được. Một bài viết sắp tới sẽ xem xét vắn tắt một số kiểu thành phần, minh chứng bằng ba ví dụ rất khác nhau - các đối tượng Java, giao dịch của Hệ thống quản lý thông tin (IMS) và các câu lệnh SQL – cách làm thế nào để bất kỳ công nghệ thực hiện nào được ánh xạ tương ứng với mô hình thành phần SOA phổ biến và đồng thời đáp ứng các yêu cầu của những nhà phát triển cụ thể.


Sự hợp thành

Trong khi có thể thực hiện hợp thành SOA bằng cách sử dụng các kỹ thuật đặc thù cho từng nền tảng, một kiểu hợp thành mới đặt trọng tâm vào SOA đứng vững với tư cách riêng mà không cần dịch sang mô hình lập trình khác.

Mô hình hợp thành cho phép khám phá các dịch vụ có các giao diện và các chính sách cơ sở hạ tầng (QoS) mong muốn và kết hợp chúng lại thành các dịch vụ, các mô-đun và các giải pháp mới. Các dịch vụ mới này lại có thể được phối hợp lại.

Cách tiếp cận của chúng ta thống nhất mẫu hình để tạo ra và truy cập logic nghiệp vụ. Trừu tượng hóa cao hơn các cấu kiện lập trình hiện có, ví dụ như các EJB, mô hình lập trình SOA của chúng ta che giấu các sự khác biệt giữa các công nghệ triển khai thực hiện nó. Trong mô hình này, các thành phần được lắp ráp thành các mô-đun, đến lượt chúng các mô đun được phối hợp thành các giải pháp. Các thành phần đưa ra các dịch vụ có thể được gọi thông qua các giao diện có thể gọi trực tiếp được. Các giao diện được mô tả bằng cách sử dụng WSDL, Java hoặc các ngôn ngữ khác. Một việc triển khai thực hiện có thể có các tham chiếu không phân giải được đến các dịch vụ cần thiết, mà sẽ được thỏa mãn trước khi thi hành bằng cách nối các thành phần với nhau. Thao tác đấu nối có thể được thực hiện bằng cách sử dụng một công cụ phù hợp với vai trò, bởi một nhà tích hợp (integrator) giải pháp hoặc nhà lắp ráp (assembler) giải pháp, những người có thể sử dụng sự hiểu biết về các chính sách của doanh nghiệp và hình thái (topology) triển khai Kênh dịch vụ doanh nghiệp (ESB), trong khi người đã phát triển các thành phần ban đầu này có thể không biết đến hình thái này.


Tuỳ biến không cần lập trình

Ít khả năng rằng một dịch vụ có thể luôn luôn được sử dụng lại như nó vốn có, mà không phải cấu hình, tuỳ chỉnh, hoặc liên kết. Khi cần phải thay đổi, thì trong tình hình hiện nay là phải sửa đổi mã nguồn. Tuy nhiên, khả năng mở rộng tái sử dụng rộng rãi các thành phần phụ thuộc rất nhiều vào khả năng thích ứng các thành phần theo môi trường trong đó chúng được sử dụng. Một mô hình lập trình SOA cần phải cho phép xây dựng các dịch vụ và các mô-đun để "các lập trình viên" có thể tùy chỉnh chúng mà không phải sửa đổi mã nguồn. Điều này đặc biệt quan trọng khi lập trình viên thuộc một tổ chức khác với các lập trình viên mà đã xây dựng các thành phần.

Mô hình lập trình dựa trên thành phần dành cho SOA đưa ra một vài cơ chế để tuỳ biến thành phần mà không cần lập trình.

Một thành phần nhằm để sử dụng lại có thể được đóng gói như là một khuôn mẫu với các điểm biến đổi được sẽ được kết nối khi đặt nó vào một giải pháp. Kiểu làm thích nghi này trở thành phần lớp đầu tiên của mô hình lập trình của chúng ta, cùng với một ngôn ngữ quy tắc và các công cụ kèm theo, cung cấp các khả năng tuỳ biến cho các loại người sử dụng mới.

Thành phần hòa giải (mediation) tập trung vào việc xử lý các thông báo đang truyền dẫn. Các thành phần hòa giải thường được phối hợp mà không cần lập trình. Kênh dịch vụ doanh nghiệp đóng một vai trò then chốt như là một kết cấu đa giao thức, lấy các thành phần dịch vụ kết lại thành một tương tác liên tục, cho phép giải quyết các mối quan tâm của hệ thống doanh nghiệp – ví dụ như việc kiểm toán, ghi nhật kí, định tuyến, làm thích nghi các giao diện không ăn khớp, sự thay thế dần từng bước các thành phần (componentry) tương đương, an ninh, và v.v - trên quy mô toàn doanh nghiệp ở tuyến xương sống, bằng cách chèn các thành phần đặc biệt được gọi là các thành phần hòa giải (mediations) vào trong tuyến đường đi của các thông điệp để môi giới việc tương tác giữa các dịch vụ mà không làm thay đổi các điểm cuối hiện có.

Một lợi ích khác của một mô hình lập trình SOA, được thúc đẩy bởi các đặc điểm đã đề cập trên đây, là khả năng thay thế một thành phần này bằng thành phần khác tại nhiều thời điểm trong vòng đời của phần mềm. Điều này có thể thực hiện được nhờ sự kết buộc muộn các giao diện đã khai báo với các triển khai thực hiện hỗ trợ các giao diện ấy. Có rất nhiều lý do về nghiệp vụ dẫn đến mong muốn thay thế các đơn vị chức năng. Lý do quan trọng nhất có lẽ là để giảm bớt khó khăn trong việc quản lý các thay đổi trong một doanh nghiệp lớn. Việc đưa vào các thay đổi dần từng bước và hạn chế tác động của nó bằng cách tuân thủ các giao diện đã định nghĩa làm tăng tính linh hoạt. Nó cũng phù hợp với việc ghép lỏng thường là đặc điểm của các tổ chức lớn của con người. Hơn nữa, các thành phần dịch vụ làm lợi cho tổ chức bằng cách cho phép các nhóm có các kỹ năng, nhu cầu và thời gian biểu khác nhau làm việc hợp tác với nhau trên cơ sở hạ tầng công nghệ thông tin (CNTT) theo cách làm tăng tối đa hiệu quả của cả tài nguyên hệ thống lẫn nguồn nhân lực, cho phép doanh nghiệp đáp ứng nhanh hơn với sự thay đổi ở mức doanh nghiệp.


Định nghĩa thành phần

Các thành phần SOA của chúng ta được định nghĩa bởi các đặc tả kỹ thuật sau đây:

  1. Một đặc tả dịch vụ (service specification) cung cấp cái nhìn về thành phần như là một tập hợp các dịch vụ được tạo ra và được yêu cầu bởi thành phần này. Nó được định nghĩa bằng ba nhóm các đặc tả kỹ thuật sau đây:
    • Các giao diện, thường là các portTypes WSDL điển hình.
    • Các chính sách, giải thích các thuộc tính QoS, ví dụ như hành vi giao dịch và an ninh.
    • Các mô tả hành vi, ví dụ như là một quá trình trừu tượng BPEL4WS. Một ví dụ khác có thể là một mô hình trạng thái của Ngôn ngữ mô hình hóa thống nhất, phiên bản 2 (Unified Modeling Language - UML2); mô hình này chỉ rõ các hoạt động nào là hợp lệ đối với các trạng thái khác nhau và các phép chuyển trạng thái mà các hoạt động đó gây ra. Những bên gọi dịch vụ có thể tính toán các chuỗi hoạt động hợp lệ từ mô hình trạng thái.
  2. Một sự triển khai thực hiện thành phần dịch vụ (service component implementation):
    • Các đặc tả kỹ thuật dịch vụ được cung cấp.
    • Các đặc tả kỹ thuật dịch vụ được yêu cầu.
    • Các thuộc tính có thể thiết lập đối với thành phần để đo cắt hoặc tùy chỉnh hành vi của nó.
    • Các thuộc tính để cung cấp sự hỗ trợ cơ bản cho điều này; các kịch bản phức tạp hơn sử dụng các điểm biến đổi được và các lời gọi đến thành phần tùy biến.
    • Các chỉ dẫn (các chính sách) về thùng chứa (container) mà là bất biến đối với tất cả các cá thể triển khai thực hiện.
    • Một tạo phẩm triển khai thực hiện (ví dụ như là một lớp Java, một tài liệu BPEL hay một tập hợp các quy tắc XSLT), định nghĩa triển khai thực hiện thành phần này.
  3. Một (cá thể) thành phần dịch vụ (service component) được định nghĩa bởi những đặc tả sau đây:
    • Một tên (name).
    • Một triển khai thực hiện thành phần dịch vụ.
    • Các giá trị của bất kỳ thuộc tính nào của việc triển khai thực hiện, được thiết lập để liên kết thành cá thể ấy.
    • Đặc tả kỹ thuật của bất kỳ dịch vụ nào nhằm phân giải các đặc tả kỹ thuật dịch vụ cần thiết của việc triển khai thực hiện. Các dịch vụ phân giải này có thể là "các dây nối" để kết nối các cá thể thành phần hay một "truy vấn" cần thi hành để tìm kiếm một thành phần trong thời gian đang chạy mà có triển khai thực hiện các giao diện, có các chính sách QoS kết hợp, và khớp với hành vi đã chỉ rõ (ví dụ như là một quá trình trừu tượng hay mô hình trạng thái).

Có hai cách tiếp cận cơ bản để định nghĩa một thành phần SOA. Các định nghĩa có thể do các công cụ phát triển tạo ra hoặc do một nhà phát triển tạo ra bằng tay.

Đầu tiên là một tệp tin điều khiển (control file), một tài liệu, thông qua tham chiếu, kết hợp hoặc ghép nối tất cả các bộ phận của một thành phần. Ví dụ, tệp tin điều khiển có thể tham chiếu định nghĩa WSDL (cung cấp giao diện), tham chiếu lớp Java triển khai thực hiện thành phần (tạo phẩm triển khai thực hiện) hoặc tham chiếu các tài liệu chính sách đi kèm (các quyết định chính sách). Những thứ này lại có thể tham chiếu đến hệ thống tệp tin, đường dẫn của lớp, hệ thống kiểm soát mã nguồn hoặc các URL Web. Định dạng của tệp tin điều khiển tập hợp một số các tạo phẩm được phát triển riêng biệt thành một sưu tập, mà khi phối hợp cùng với nhau, làm nên thành phần. Các công cụ phát triển ứng dụng trợ giúp trong việc định nghĩa tệp tin điều khiển.

Định dạng thứ hai sử dụng pragmas, đó là các phần tử ngôn ngữ chỉ rõ cũng các thông tin giống như trên, nhưng chứa bên trong phần thân của chỉ một tệp tin mã nguồn. Đang tiến triển các hỗ trợ trong Java (ví dụ, các thẻ XDoclet như trong JSR 175) để làm cho các chú giải này trở thành một bộ phận của ngôn ngữ Java. Tuy nhiên, cách tiếp cận này vẫn chưa hỗ trợ các công nghệ triển khai thực hiện thành phần SOA cũng hợp lệ khác, ví dụ như là một tập hợp các câu lệnh SQL hoặc XQuery. Mỗi kiểu thành phần có một định dạng tệp tin mã nguồn kết hợp dành cho tạo phẩm triển khai thực hiện nó, ví dụ như là một tệp Java, máy trạng thái hoặc tệp tin SQL. Hỗ trợ các chú giải trong Phát triển nhanh chóng WebSphere của IBM (IBM WebSphere® Rapid Deployment) có thể tạo ra tất cả các phần tử riêng lẻ hợp thành một thành phần từ một tệp mã nguồn có chứa các pragmas. Ví dụ, các lời chú thích có cấu trúc trong một tệp mã nguồn Java cho biết các phương thức Java nào sẽ trở thành các hoạt động dịch vụ web trên một WSDL được tạo ra để định nghĩa các giao diện dịch vụ của thành phần.


Tóm tắt

Một mô hình lập trình dựa trên thành phần - được hỗ trợ bởi các công cụ hướng-nhiệm vụ và bởi một cơ sở hạ tầng môi trường chạy - là chìa khóa dẫn đến việc chấp nhận SOA nhanh chóng. Chúng ta mong đợi các lợi ích giống như một khuynh hướng mới về việc sử dụng lại phần mềm, cho phép những chuyên gia nghiệp vụ, những người không nhất thiết phải là các lập trình viên, sử dụng và khai thác các thành phần SOA để tạo ra các giải pháp nghiệp vụ mới và điều chỉnh những giải pháp hiện có khi các nhu cầu nghiệp vụ mới phát sinh.

Tài nguyên

Học tập

Thảo luận

  • Hãy dành tâm trí cho cộng đồng developerWorks bằng cách tham gia vào các developerWorks blogs.

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=SOA và dịch vụ Web
ArticleID=407159
ArticleTitle=Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 6: Mô hình thành phần tiến hoá
publish-date=07102009