Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 11: SOA và môi trường phần mềm trên máy tính lớn

Service-Oriented Architecture (SOA- Kiến trúc hướng dịch vụ) là một khái niệm tiến hóa áp dụng được cho cả các hệ thống phần mềm mới và hệ thống đang có. Tuy nhiên, cách tốt nhất để áp dụng SOA cho một hệ thống phần mềm hiện có có thể không được rõ ràng. Hãy tìm ra một số cách tiếp cận và làm thế nào để các cách tiếp cận này có thể đem lại lợi ích cho việc kinh doanh của bạn.

Jim Rhyne, Kỹ sư cao cấp, IBM

Jim Rhyne là một kỹ sư xuất sắc của IBM và là kiến trúc sư trưởng của các phần mềm trung gian (middlewares) và các công cụ dành cho zSeries của IBM, bao gồm CICS, WebSphere Developer cho zSeries, COBOL doanh nghiệp cho z/OS, PL/I doanh nghiệp cho z/OS, Nhà phân tích tài sản WebSphere Studio. Trước đó ông đã là một kiến trúc sư cao cấp của phần mềm WebSphere và phần mềm Môi giới thành phần của IBM. Jim là một người ủng hộ cho việc hiện đại hóa phần mềm trên máy tính lớn và thường xuyên khuyến cáo những người dùng các máy tính lớn của IBM, các nhà phân tích công nghiệp và các tổ chức dịch vụ phần mềm.



31 07 2009

Mở đầu

Trong nhiều năm qua, việc phát triển phần mềm tiến triển bằng cách cải thiện các ngôn ngữ lập trình. Gần đây, trọng tâm đó đã chuyển hướng tới các quá trình lập trình; ví dụ, ngôn ngữ Java™ loại trừ nhu cầu liên kết các mô đun đã biên dịch lại với nhau. SOA là sự đổi mới gần đây nhất theo xu hướng này. Bài viết này, mặc dù chủ yếu nhắm tới các nhà phát triển và các kiến trúc sư phần mềm máy tính lớn, cũng áp dụng được cho phần mềm tiền SOA dành cho các môi trường khác, ví dụ như hệ điều hành Linux®.

Thành phần hóa (componentization) và lắp ráp thành phần là các nguyên tắc chính trong thiết kế phần mềm SOA. SOA dựa vào công nghệ thường gặp và trở nên thông dụng mọi nơi, như Internet, XML và HTTP. Nó được định nghĩa theo các tiêu chuẩn và trong tầm tay của cả các cá nhân, doanh nghiệp nhỏ cũng như các doanh nghiệp lớn. Đó là giải pháp tốt nhất mà chúng ta có hiện nay để xây dựng ứng dụng.

SOA được mô tả trong sách trắng Nền tảng SOA của IBM (IBM® SOA Foundation) (xem Tài nguyên để biết thêm thông tin) như sau:

Điều cần phải nói rõ ràng ngay bây giờ là SOA không chỉ là về công nghệ. IBM xem xét SOA như là một mối quan hệ toàn diện giữa doanh nghiệp và tổ chức công nghệ thông tin (CNTT). SOA bao gồm các công cụ và các phương pháp luận để nắm bắt thiết kế hoạt động nghiệp vụ và sử dụng thông tin thiết kế đó để giúp cải thiện hoạt động nghiệp vụ. Nó cũng bao gồm các công cụ, mô hình lập trình và các kỹ thuật để triển khai thực hiện thiết kế hoạt động nghiệp vụ trong các hệ thống thông tin. Nó bao gồm các cơ sở hạ tầng phần mềm trung gian để cho chạy bản triển khai thực hiện ấy. SOA bao gồm việc quản lý bản triển khai thực hiện để bảo đảm tính sẵn dùng cho hoạt động nghiệp vụ và để đảm bảo hiệu quả sử dụng các tài nguyên trong việc thi hành bản triển khai thực hiện đó. Nó bao gồm việc thiết lập ai là người có thẩm quyền và qui trình được sử dụng để kiểm soát các sự thay đổi trong thiết kế hoạt động nghiệp vụ và việc triển khai thực hiện nó trong hệ thống thông tin. Và cuối cùng, SOA đẩy nhanh thời điểm phát huy giá trị (time-to-value) của các lợi ích ấy.

Một số trong các qui trình kiến trúc ấy -- mô hình hóa nghiệp vụ và thiết kế qui trình nghiệp vụ nói riêng – cũng áp dụng được cho các ứng dụng máy tính lớn giống như áp dụng chúng cho môi trường nền tảng Java 2, ấn bản doanh nghiệp (Java 2 Platform, Enterprise Edition-J2EE) hay các kiểu các ứng dụng khác. Tài liệu hướng dẫn này tập trung vào các công cụ, các mô hình lập trình và các kỹ thuật để thực hiện SOA được điều chỉnh để thích nghi với môi trường máy tính lớn của IBM. Bạn nên bổ sung cho bài viết này các hướng dẫn song hành về thêm khả năng (enablement) SOA của các ứng dụng máy tính lớn IBM cho các môi trường, ví dụ như xử lý theo bó CICS®, IMS™ và DB2® của IBM và các bài viết phụ thêm về các chủ đề phát triển SOA.

Các thay đổi kỹ thuật mang lại các khả năng SOA của phần mềm mà không làm thay đổi chức năng của nó được nói đến như là sự thêm khả năng SOA (SOA enablement). Nói chung, thuật ngữ sự thêm khả năng SOA không phải được dùng để áp dụng cho việc thiết kế và xây dựng phần mềm mới. Các nhà phát triển có thể quyết định kết hợp việc thêm khả năng SOA với các thay đổi chức năng cho một ứng dụng, nhưng việc thêm khả năng SOA không cần thay đổi chức năng.

Tại sao lại sử dụng SOA?

Thiết kế ứng dụng SOA cung cấp nhiều lợi thế cho công nghệ thông tin (CNTT). Nói cụ thể, trọng tâm ở đây có ba phần:

  • Tính kết nối hầu như phổ quát (near-universal) nhằm loại bỏ chi phí và sự phức tạp do công nghệ độc quyền gây ra và các thành phần hòa giải có mặt chỉ để giải quyết sự không phù hợp về công nghệ.
  • Tái sử dụng thông qua việc xây dựng bằng cách gộp nhóm, làm việc tốt với Kiến trúc dựa theo mô hình.
  • Áp dụng được cho hầu hết các ngôn ngữ lập trình và các môi trường chạy.

Vấn đề đáp ứng theo yêu cầu

Các công việc kinh doanh hiện đại được thúc đẩy để nắm lấy các cơ hội do các thị trường mới mang lại và để trở nên có năng xuất ngày càng cao hơn. Phải đón cơ hội bằng tính linh hoạt và tính linh hoạt CNTT nảy sinh từ khả năng định lại cấu hình, sửa đổi và tạo phần mềm mới khi cần thiết. Năng suất trước hết là kết quả của việc tái kỹ nghệ và tự động hóa qui trình nghiệp vụ. Phần mềm trở nên dễ uốn nắn đến mức có thể dễ dàng thay đổi để đáp ứng các thay đổi nhu cầu nghiệp vụ.

Việc thiết kế và triển khai thực hiện phần mềm linh động đã là một thách thức kể từ lúc phát minh ra các máy tính có chương trình được lưu trữ. Công nghệ ảo hóa (Virtualization) -- sự thay thế các kết buộc (binding) tĩnh giữa các phần tử của chương trình bằng các kết buộc có thể thay đổi trong quá trình hoạt động -- là một chìa khóa dẫn đến tính linh động. Tuy nhiên, nó phải được sử dụng một cách thận trọng trong các môi trường máy tính công năng cao để cho đừng ảnh hưởng đến công năng và việc sử dụng tài nguyên.

Chúng ta đã nghiên cứu thiết kế phần mềm để phân tách logic sắp xếp qui trình xử lý, chính sách, các tính toán cơ sở, giao diện với con người và quản lý dữ liệu. Sự phân tách này ghi nhận rằng logic sắp xếp và chính sách thường bị ảnh hưởng nhất bởi các thay đổi trong thực hành nghiệp vụ. Các sự phân tách khác (giao diện người dùng và dữ liệu) bảo vệ phần mềm ứng dụng khỏi các thay đổi công nghệ trong lưu trữ dữ liệu và giao diện người dùng (UI) được ưa thích, bao gồm cả việc truy cập từ các thiết bị di động. Việc kết buộc các phần tử tách biệt này theo phương thức ảo và động cho phép chúng nhanh chóng được tách ra và kết nối lại theo các cách khác nhau. Ví dụ, một chính sách có thể được gỡ bỏ và thay thế mà không phải dừng quá trình xử lý của phần mềm tổng thể, mà nó là một bộ phận.

Việc xây dựng các thành phần phần mềm, cho dù là logic sắp xếp qui trình xử lý, chính sách, các tính toán cơ sở, giao diện với con người hoặc quản lý dữ liệu, sẽ làm tăng năng suất bằng cách tái sử dụng. Nó cũng tạo ra sự nhất quán trên toàn bộ các qui trình nghiệp vụ và làm đơn giản hoá việc bảo trì bằng cách tránh phải thay đổi mã tương đương trong nhiều mô đun phần mềm.

Tái sử dụng là một quá trình khám phá sẽ vẫn tiếp tục diễn ra khi mà các thành phần dùng chung được sử dụng trong kịch bản mới. Một thành phần phát triển một cách tự nhiên bằng cách tích lũy thêm khả năng, giữ lại tất cả các khả năng cũ để tránh nguy cơ tái cơ cấu lại phía khách. Tuy nhiên, theo định kỳ, các thành phần cần được thiết kế lại và được cấu trúc lại. Mặc dù việc này thường có thể được thực hiện mà không làm ảnh hưởng đến những người sử dụng, bạn phải có khả năng nhận biết những người sử dụng thành phần trong các trường hợp ở đó việc cơ cấu lại và cấu trúc lại sẽ ảnh hưởng đến họ.

Trong SOA, các thành phần có các giao diện dịch vụ được mô tả bằng Ngôn ngữ mô tả dịch vụ Web (Web Services Description Language -WSDL). WSDL của một thành phần mô tả cả hai, cả các dịch vụ mà thành phần đó cung cấp lẫn các dịch vụ mà thành phần đó yêu cầu. WSDL là một trong các tiêu chuẩn tương tác lẫn nhau của các dịch vụ web. Bên cung cấp dịch vụ có thể được kết nối đến bên yêu cầu dịch vụ nếu các mô tả WSDL của chúng khớp nhau. Điều này cho phép hai thành phần trao đổi các thông điệp.

Môi trường máy tính lớn

Máy tính lớn hiện đại được sinh ra vào năm 1964. Nó nhanh chóng trở thành một mẫu máy tính doanh nghiệp, và phát triển liên tục để duy trì vị trí này. Thật không ngờ, mã ứng dụng được viết cách đây 40 năm hiện nay vẫn còn có khả năng chạy trong hầu hết các môi trường máy tính lớn. Có khoảng chừng hàng chục hoặc hàng trăm tỷ dòng mã COBOL đang sử dụng hiện nay mà phần lớn khởi đầu đã được viết trong những năm 1970 và những năm 1980. Nhồi đầy bên trong các ứng dụng này là triển khai thực hiện các lôgic của nhiều thủ tục nghiệp vụ, các tính toán và các chính sách có giá trị. Việc thêm khả năng SOA cho môi trường máy tính lớn bao gồm các thói quen thực hành, các mẫu kiến trúc, các công cụ và phần mềm trung gian biểu lộ các logic này và làm cho nó dễ sử dụng lại.

Các máy tính lớn của IBM có tầm mở rộng cao, có khả năng thực hiện hàng chục triệu giao dịch hàng ngày. Chúng cũng có thể được tinh chỉnh để đạt được tỷ lệ sử dụng bộ xử lý và I/O vượt quá 90%. Độ tin cậy là rất cao và sự phục hồi sau các sự cố dừng máy hiếm hoi cũng rất nhanh với sự mất mát thông tin ít nhất. Các cấu hình của hệ thống hỗ trợ việc dự phòng lỗi và khắc phục thảm họa, bới vì các hệ thống chính và các hệ thống sao lưu dự phòng có thể được đặt tách xa nhau nhiều dặm. Các máy tính lớn của IBM và các môi trường chủ chứa ứng dụng chính của chúng là duy nhất về mặt tầm mở rộng và độ tin cậy. Đây là các phẩm chất về tính toán cần thiết đối với hoạt động liên tục của hệ thống CNTT điển hình trong các doanh nghiệp lớn. Các máy tính lớn của IBM đã đạt được các phẩm chất này bằng cách đổi mới kỹ thuật liên tục trong các lĩnh vực như công nghệ áo hóa phần cứng, dự phòng lỗi, tự chẩn đoán, đa xử lý chia sẻ bộ nhớ trên quy mô lớn và chia sẻ tài nguyên từ xa. Nhiều sự đổi mới kỹ thuật này đã được máy chủ cỡ trung bình chấp nhận. SOA cho môi trường doanh nghiệp cũng được thiết kế với các thuộc tính này, đạt được khả năng tái sử dụng mà không bị mất tính hiệu quả và chất lượng dịch vụ.


Ba dạng thêm khả năng SOA cho môi trường máy tính lớn

Việc triển khai thực hiện một SOA cho một doanh nghiệp đòi hỏi ba điều quan trọng:

  • Các thay đổi trong các ứng dụng, bao gồm việc thiết kế lại các ứng dụng hiện có và thiết kế các thay đổi trong các ứng dụng sẽ được tạo ra.
  • Các thay đổi về các kỹ năng CNTT.
  • Các thay đổi về cơ sở hạ tầng CNTT (phần cứng, các hệ thống, phần mềm trung gian và trao đổi thông tin).

Mặc dù bài viết này tập trung vào các thay đổi ứng dụng, hãy ghi nhớ rằng sự thành công của một dự án thêm khả năng SOA phụ thuộc vào các thay đổi cả ba dạng nói trên. Các phiên bản mới nhất của phần cứng, các hệ thống, phần mềm trung gian và trao đổi thông tin - đặc biệt là công nghệ ảo hóa, phần mềm quản lý và trao đổi thông tin - được thiết kế để đáp ứng các nhu cầu của SOA, làm việc rất tốt. Tốt nhất là hãy kiểm kê cơ sở hạ tầng CNTT trước khi bắt đầu một dự án SOA và cập nhật mọi phương tiện thiết yếu cho sự thành công của dự án. Ngoài ra, hãy thống kê các kỹ năng sẵn có và bố trí đào tạo. Thỉnh thoảng, một nhà cung cấp dịch vụ, ví dụ như Các dịch vụ tư vấn nghiệp vụ của IBM (IBM Business Consulting Services), có thể được mời tham gia hợp đồng thực hiện một dự án kiểm chứng thiết kế (proof-of-concept) và đội ngũ nhân viên CNTT sẽ tham gia học hỏi các kỹ năng cần thiết trong quá trình đó.

Các kỹ năng SOA là cần thiết để triển khai thực hiện ban đầu và bảo trì các hệ thống của SOA. Tất cả các nhà phát triển thành phần trong doanh nghiệp -- bao gồm các nhà phát triển ngôn ngữ COBOL -- phải thực hành thiết kế SOA, bởi vì các thành phần trở nên có khả năng sử dụng lại chỉ trong phạm vi mà các nhà thiết kế hoặc người triển khai thực hiện (implementer) đã hình dung trước các cách trong đó các thành phần dịch vụ có thể được sử dụng. Các kiến trúc sư ứng dụng, bao gồm những người chịu trách nhiệm đối với các ứng dụng hiện có, cũng phải hiểu và thực hành kỹ năng SOA mới -- thiết kế tích hợp -- bao gồm việc lắp ráp thành phần, tự động hóa tiến trình và tích hợp dữ liệu.

Đối với hầu hết các doanh nghiệp, hành trình đến SOA mất nhiều thời gian và được thực hiện theo cách thay đổi dần dần, mang lại các giá trị có thể chứng minh được cả trong ngắn hạn và dài hạn. Rất nhiều tổ chức CNTT, đặc biệt là trong các lĩnh vực bảo hiểm và dịch vụ tài chính, đã bắt đầu các dự án phát triển thêm dần cho các bộ phận hỗ trợ SOA của vốn phần mềm hiện có của họ. Họ báo cáo rằng việc thêm khả năng SOA ngay cả ở mức độ khiêm tốn nhất, cũng làm cho dễ dàng đạt được việc tích hợp ứng dụng, tự động hóa quá trình và định lại cấu hình phần mềm nhanh chóng.

Chúng tôi khuyên cáo lập kế hoạch thêm khả năng SOA như là một phần của quá trình thay đổi dần từng bước, chứ không phải như là một quá trình tách biệt mà sự chuyển giao nó sẽ thay thế các hệ thống hiện hành. Các dự án thay đổi lớn đầy rủi ro, tốn kém và chỉ được đảm bảo khi các hệ thống hiện có không còn có thể đáp ứng được các nhu cầu nghiệp vụ. Các lý do ủng hộ việc này bao gồm chi phí, các yêu cầu cũng thay đổi khi dự án tiến triển và sự đối lập về tổ chức của các bên liên quan đến bản triển khai thực hiện hiện tại. Ngược lại, sự thay đổi dần từng bước cơ sở hạ tầng CNTT là một thông lệ thực tế bình thường, chỉ gây ra các gián đoạn nhỏ và các thay đổi dần dần các kỹ năng và trong các cấu trúc ứng dụng cũng dễ dàng làm cho trở thành thông lệ bình thường.


Thêm khả năng SOA đối với các ứng dụng hiện có

Chúng ta tập trung vào khám phá cách thức SOA mang lại hai loại giá trị: khả năng truy cập và tái sử dụng /tính linh hoạt. Một ứng dụng SOA mới sẽ trưng ra cả hai loại giá trị. Một ứng dụng hiện có trải qua quá trình thêm khả năng SOA thường đi theo một trong ba mẫu sau:

  • Bao bọc (Wrapping) -- Ứng dụng hiện có và giao diện hiện có của nó được gắn kèm, không thay đổi, tới một cổng kết nối (gateway), cung cấp một hoặc nhiều giao diện SOA. Mẫu này cung cấp khả năng truy cập, nhưng không cải thiện tính sử dụng lại được hay tính linh hoạt.
  • Đổi mới khuôn mặt (Refacing) -- Ứng dụng hiện có được sửa đổi hoặc mở rộng để cung cấp một giao diện mới phù hợp hơn để sử dụng nó như là một dịch vụ. Mẫu này cung cấp việc truy cập và một mức độ về sử dụng lại/tính linh hoạt.
  • Thành phần hóa (Componentizing) -- Ứng dụng hiện có được tháo dỡ phân ra thành các thành phần và sau đó được lắp ráp lại để tạo điều kiện thuận lợi cho việc sử dụng lại và để đưa ra các chức năng trước đó không thể truy cập như là các hoạt động dịch vụ. Mẫu này cung cấp giá trị tối đa của cả việc truy cập lẫn việc sử dụng lại/tính linh hoạt.

Mỗi một trong các mẫu này có các ưu điểm và nhược điểm. Thông thường một tổ chức CNTT đầu tiên thường cố gắng bao bọc để đạt được khả năng truy cập với chi phí thấp. Nếu việc bao bọc gây ra chi phí hoạt động cao hơn, tổ chức CNTT xử lý lại bề mặt (reface) hoặc thành phần hóa các ứng dụng được sử dụng rất nhiều để cải thiện hiệu năng. Một động cơ có liên quan dẫn đến việc đổi mới khuôn mặt hoặc thành phần hóa là để trưng ra các dịch vụ ứng dụng mà trước đó chỉ có thể truy cập được thông qua một hộp thoại phức tạp, đòi hỏi các thông tin không liên quan trực tiếp đến các dịch vụ được đưa ra.

Ta hãy xem xét từng mẫu một cách chi tiết hơn.

Bao bọc

Việc bao bọc các ứng dụng máy tính lớn đã bắt đầu từ kỷ nguyên khách/chủ và là một thông lệ thực hành hoàn thiện với các công nghệ đã hoàn thiện. Các đề nghị về cổng kết nối của IBM ví dụ như là các dịch vụ chuyển đổi truy cập của máy chủ WebSphere (WebSphere® Host Access Transformation Services - sau đây gọi tắt là HATS) hỗ trợ bao bọc các ứng dụng 3270 và 5250. HATS mới đây đã được nâng cấp để cung cấp việc truy cập các dịch vụ web. Phiên bản gần đây nhất của CICS cung cấp việc truy cập trực tiếp thông qua các dịch vụ web. Khi tính năng này được ghép với cầu 3270 có khả năng kết nối và các đặc tính môi trường chạy của luồng dịch vụ, các ứng dụng hỗ trợ ánh xạ cơ sở CICS (CICS Basic Mapping Support - BMS) có thể được công bố như là dịch vụ web. IMS cung cấp một khả năng tương tự khi sử dụng một máy chủ ứng dụng J2EE có sự hỗ trợ cho các dịch vụ Web được kết nối thông qua phần mềm kết nối IMS.

Các ứng dụng máy tính lớn có thể được thiết kế với một giao diện đầu cuối hoặc một giao diện thông báo. Đôi khi chúng có cả hai giao diện này và phân tách mã UI khỏi logic nghiệp vụ. Một thông lệ thực hành tốt nhất cho các ứng dụng CICS và IMS là tách sự hỗ trợ UI 3270 khỏi logic nghiệp vụ, sau đó ghép hai tầng này bằng cách sử dụng giao diện thông báo. Nguyên tắc thiết kế này tương tự như kiến trúc Mô hình/Khung nhìn/Trình điều khiển, nhưng được phát triển độc lập. Nó cách ly các thay đổi trong UI khỏi những thay đổi trong logic nghiệp vụ và cho phép UI thực hiện trong một thùng chứa riêng biệt được điều chỉnh để đạt được năng lực xử lý UI tối ưu.

Hai hạn chế của giao diện 3270 (terminal) là đặc biệt quan trọng khi thiết kế để truy cập SOA.

Đầu tiên là, mỗi yêu cầu và phản hồi phải không vượt quá 1920 byte thông tin cho mỗi giao dịch. Các chuyển đổi lớn hơn yêu cầu nhiều giao dịch, tăng thêm độ dài đường đi và tiêu thụ tài nguyên. Ví dụ, một giao dịch truy vấn về John Smith có thể trả về hàng trăm khách hàng. Nếu màn hình 3270 đầu tiên (hiển thị một lần chỉ có 15 khách hàng) không hiển thị đúng khách hàng cần tìm, người vận hành yêu cầu các màn hình tiếp theo, mỗi yêu cầu là một giao dịch mới tiêu phí hoạt động của CPU, I/O và bộ nhớ. Một giao diện tốt hơn, nhất là dành cho trao đổi thông tin giữa các chương trình, sẽ phải trả về tất cả các bản ghi John Smith cùng một lúc.

Thứ hai là, đầu cuối 3270 là đầu cuối hội thoại. Điều này có nghĩa là có một bó các tài nguyên của máy tính lớn kết hợp với mỗi người dùng đã đăng nhập vào, ngay cả đối với một đầu cuối rỗi. Ngoài ra, một số ứng dụng cũ hơn được viết để nhớ sẵn (cache) thông tin (ví dụ như toàn bộ danh sách các khách hàng có tên là John Smith) được một đầu cuối cụ thể nào đó yêu cầu. Trong khi mã ứng dụng như vậy cải thiện hiệu năng cho các giao dịch giống như hiển thị 15 khách hàng kế tiếp có tên là John Smith, nó làm ảnh hưởng ngược lại đến các đặc tính khác của hệ thống. Người sử dụng một ứng dụng như vậy không thể thay đổi các đầu cuối hoặc tạm thời ngắt kết nối khỏi ứng dụng, phần mềm trung gian không thể thực hiện cân bằng tải và hệ thống không thể quản lý thông tin nhớ sẵn bằng cách ghi tráo đổi nó ra ngoài trong khi người sử dụng còn đang suy nghĩ hay vắng mặt để làm giảm sự tiêu dùng bộ nhớ.

Các kích thước thông báo lớn hơn cho phép mỗi giao dịch thêm nhiều thông tin, giảm chi phí hoạt động và cải thiện thời gian đáp ứng. Phần mềm trung gian của máy tính lớn, ví dụ như CICS và IMS, hỗ trợ các kích thước thông báo lên đến 32KB cho mỗi giao dịch trong các giao diện thông báo. Khi một ứng dụng chia tách các logic UI khỏi logic nghiệp vụ, việc thêm khả năng SOA thường được áp dụng tại giao diện thông báo của logic nghiệp vụ, hoàn toàn bỏ qua mã UI. Các phiên bản gần đây của phần mềm trung gian này đã bắt đầu hỗ trợ thậm chí các kích thước thông báo lớn hơn; tuy nhiên, các kích thước thông báo trên 32KB yêu cầu phải có thay đổi trong chương trình ứng dụng.

Điều này dẫn tới mẫu tiếp theo: đổi mới khuôn mặt.

Đổi mới khuôn mặt

Mục đích của mẫu đổi mới khuôn mặt là thêm một giao diện thông báo -- thường là một giao diện SOA, thích hợp để sử dụng như là một dịch vụ, được mô tả trong WSDL -- vào một ứng dụng hiện có. Giao diện này có thể được triển khai thực hiện theo một số cách khác nhau tuỳ thuộc vào loại người sử dụng và nhu cầu về hiệu năng. Mẫu đổi mới khuôn mặt, đòi hỏi các thay đổi ứng dụng vừa phải, có thể là một bước có ích theo hướng thành phần hóa hoàn toàn.

Đổi mới khuôn mặt thường được thực hiện mà không cần thiết kế lại ứng dụng.

Bạn có thể đưa thêm vào một giao diện thông báo giữa logic UI và logic nghiệp vụ. Cách tiếp cận này, mặc dù có thể phức tạp, có thể mang lại các cải thiện tuyệt vời về hiệu năng, khả năng sử dụng lại và tính linh hoạt.

Hoặc bạn cũng có thể sao chép và hiệu chỉnh mã ứng dụng hiện có trong khi để nguyên hỗn hợp UI và logic nghiệp vụ ban đầu. Điều này bổ sung thêm chức năng cần thiết mà không thay đổi đáng kể mã gốc, có thể với chi phí thấp hơn và ít rủi ro hơn.

Một số vấn đề thiết kế phần mềm có thể được đề cập giải quyết trong dự án đổi mới khuôn mặt:

Trộn lẫn mã liên quan đến-UI, đến-nghiệp vụ và đến-dữ liệu
Ví dụ, trong việc tạo ra một ứng dụng để hiển thị và chỉnh sửa các nội dung của một tệp tin chính, bản thiết kế đơn giản nhất, cho chỉ một người sử dụng sẽ nhận các thông số truy vấn từ người sử dụng, truy vấn cơ sở dữ liệu và hiển thị 15 mục đầu tiên đã tìm thấy, giữ nguyên con trỏ cơ sở dữ liệu ở trạng thái mở cho đến khi người sử dụng sửa đổi một trong các mục được hiển thị trước đó hoặc cuộn xuống khung nhìn để thấy 15 mục tiếp theo. Thiết kế này rất khó thay đổi khi các kết quả truy vấn được trả về trong một thông báo chứ không phải là đang được hiển thị. Nó cũng khó thay đổi nếu người dùng muốn nhận được nhiều hơn hay ít hơn 15 mục. Việc tạo ra một giao diện giữa logic truy vấn và logic UI có thể giải quyết hầu hết các vấn đề này. Các kết quả truy vấn được trả về trong một thông báo; số lượng các kết quả lớn nhất được trả về có thể được định rõ trong một tham số kèm theo (inbound).

Duy trì trạng thái phiên làm việc của người sử dụng
Ví dụ trên đây đã giữ con trỏ cơ sở dữ liệu ở trạng thái mở giữa các tương tác của người sử dụng, ngăn cản những người dùng khác truy cập vào các đoạn cơ sở dữ liệu đã bị khóa. Đối với một hệ thống đa người dùng (multi-user), việc lưu trữ sẵn kết quả truy vấn trong bộ nhớ tiến trình xử lý và giải phóng các khóa cơ sở dữ liệu sẽ cải thiện hiệu năng tổng thể của hệ thống. Tuy nhiên, tiến trình của ứng dụng với các nội dung bộ nhớ sẵn đặc thù cho người sử dụng bị treo cho đến khi người sử dụng thực hiện một hành động nào đó. Các tiến trình chiếm hữu các luồng, bộ nhớ và các tài nguyên khác và các tài nguyên này bây giờ trở nên khan hiếm khi tải người sử dụng tăng lên. Bằng cách bổ sung thêm mã để quản lý các bộ nhớ sẵn truy vấn cho nhiều người dùng cùng một lúc trong một tiến trình đơn lẻ, tiến trình này sẽ không cần tạm bị treo, mà có thể được chuyển sang làm việc cho một người dùng khác. Các phần mềm trung gian của trình quản lý giao dịch cao cấp, ví dụ như CICS và IMS, cung cấp các vùng lưu trữ tạm thời (scratchpad, các hàng đợi lưu trữ tạm thời), có thể được sử dụng để ghi nhớ sẵn trạng thái ứng dụng xuyên qua các tương tác của người dùng. Ngoài ra, phần mềm trung gian có thể quản lý các bộ nhớ sẵn này để giảm bớt áp lực lên bộ nhớ chính và sao chép chúng giữa các bộ xử lý để cải thiện việc quản lý tải công việc.

Ghép phiên của người sử dụng với trạng thái phiên của người sử dụng trong ứng dụng
Khi một tiến trình dùng để phục vụ nhiều người sử dụng, mỗi lần được thi hành, nó phải có khả năng nhận biết người sử dụng, người đã đưa ra yêu cầu đang được xử lý để định vị trạng thái phiên có liên quan đến người sử dụng. Trong các ứng dụng SOA, những người sử dụng dịch vụ có thể là con người, các kịch bản lệnh luồng công việc được máy tính hóa hoặc các thành phần khác, do đó, cách tốt nhất là chuyển một kiểu khóa của người sử dụng (user key) (một giá trị dữ liệu để nhận biết một phiên của người sử dụng) đến tiến trình của ứng dụng khi nó bắt đầu chạy. Các ứng dụng cũ hơn có thể chứa nhiều khóa của người sử dụng (ví dụ, các TERMID), không đáp ứng được yêu cầu này. Việc đưa thêm vào các tham số khóa của người sử dụng là đặc biệt có ích khi một số thành phần phải được chạy thi hành để thỏa mãn một yêu cầu của người sử dụng; thực tiễn này đảm bảo rằng trạng thái phiên của người sử dụng phù hợp được sử dụng trong mỗi thành phần.

Phân tách logic nghiệp vụ và logic dữ liệu
Mặc dù một vài qui trình nghiệp vụ (ví dụ như các tính toán giảm giá và thuế bán hàng) là thuần túy logic, hầu hết các qui trình nghiệp vụ sẽ thay đổi dữ liệu lưu trữ lâu dài (các địa chỉ của khách hàng, kho hàng sẵn có) sử dụng mẫu Tạo mới, Lấy ra, Cập nhật, Xóa (CRUD) phổ biến. Một kiến trúc chương trình đơn giản sẽ tự nhiên trộn lẫn logic nghiệp vụ với logic truy cập dữ liệu (như SQL). Sự phụ thuộc vào các lược đồ dữ liệu và phiên bản SQL cụ thể như thế có thể cản trở tính linh hoạt để sử dụng lại logic nghiệp vụ và logic dữ liệu. Việc đặt logic thao tác dữ liệu vào trong một dịch vụ hoặc thủ tục truy cập dữ liệu làm cho logic nghiệp vụ ít phụ thuộc vào nguồn dữ liệu. Ngoài ra, việc thiết kế và thực hiện dịch vụ truy cập dữ liệu tự nó trở thành tài nguyên có thể sử dụng lại. Nếu cần đến hiệu năng cao nhất, dịch vụ truy cập dữ liệu thường có thể được triển khai thực hiện như là một thủ tục cơ sở dữ liệu lưu sẵn (stored).

Nhiều vấn đề về thiết kế khác có thể được bổ sung thêm vào danh sách này và cần được xem xét khi đang dự tính một dự án đổi mới khuôn mặt. Những vấn đề được liệt kê ở đây có thể thực sự cản trở việc di chuyển đến một SOA nếu chúng không được đề cập giải quyết.

Các thay đổi thiết kế đã đề xuất tạo điều kiện thuận lợi cho việc thành phần hóa, mẫu để thêm khả năng SOA tiếp theo sẽ được thảo luận.

Thành phần hóa

Thành phần hóa làm cho một ứng dụng có tính mô đun bằng cách tạo ra các giao diện cho các chức năng bên trong mà trước đây không truy cập được (ví dụ như các tính toán giảm giá trong một ứng dụng đặt hàng tương tác). Thành phần hóa là một mở rộng của đổi mới khuôn mặt bởi vì nó đưa thêm vào các giao diện SOA bên trong một ứng dụng, trong khi đổi mới khuôn mặt chỉ áp dụng cho các giao diện bên ngoài.

Các kiến trúc thành phần hiện đại giả thiết rằng các thành phần chạy thi hành trong các môi trường phần mềm trung gian được gọi là các thùng chứa (containers). Thùng chứa gánh vác nhiều trách nhiệm quản lý tài nguyên mà nếu không như thế các trách nhiệm này sẽ phải được mã hóa vào trong ứng dụng (ví dụ như thiết lập và dỡ bỏ các kết nối tài nguyên, quản lý luồng, kiểm soát giao dịch và tạo ra và xóa các cá thể cấu trúc dữ liệu). Kết quả là một thành phần gần như không bị phụ thuộc vào các kiểu tài nguyên cụ thể hoặc các loại hệ điều hành. Việc triển khai lại thành phần vào trong thùng chứa khác có các chức năng tương tự trở nên dễ dàng hơn nhiều. Vì vậy, thành phần hóa cũng bao gồm việc cấu trúc lại ứng dụng để loại bỏ các chức năng quản lý tài nguyên khỏi ứng dụng và thay thế chúng bằng các chức năng tương đương do thùng chứa cung cấp.

Trong các kiến trúc thành phần hiện đại, nhà phát triển xác định rõ ràng các nhu cầu quản lý tài nguyên của thành phần trong một ngôn ngữ chính sách quản lý tài nguyên. Các ví dụ về điều này bao gồm các bộ mô tả triển khai J2EE và Enterprise JavaBeans Query Language (EJB QL- Ngôn ngữ Truy vấn JavaBeans doanh nghiệp). Thông tin này được các công cụ triển khai đọc khi chuyên gia triển khai thành phần chuẩn bị thành phần đó để chạy thi hành trong một môi trường phần mềm trung gian cụ thể và kết hợp nó với tài nguyên thực tế mà nó sẽ sử dụng. Trong các môi trường phần mềm trung gian cũ hơn, việc triển khai phần mềm được một lập trình viên hệ thống thực hiện bằng cách sử dụng cách làm tùy cơ ứng biến (ad hoc) (ví dụ trường hợp nhà phát triển ứng dụng điền vào một tờ giấy biểu mẫu và đưa nó cho một lập trình viên hệ thống). Ngôn ngữ chính sách quản lý tài nguyên thực sự là một ngôn ngữ cấu hình đã trộn lẫn các chính sách mức ứng dụng (ví dụ như các kết nối cơ sở dữ liệu) với các chính sách phần mềm trung gian (như là sẽ sử dụng cách truyền vận nào cho việc trao đổi thông báo). Cách làm thực tế mới hơn có thể được tự động hóa bằng các công cụ và cũng ít bị lỗi. Ví dụ, việc một công cụ triển khai có thể phát hiện ra một sự kết hợp với cơ sở dữ liệu không đúng trước khi ứng dụng thi hành. Trước đây, ứng dụng sẽ không phát hiện ra lỗi này cho đến khi thi hành, gây ra các thông báo lỗi và sổ hết nội dung (dump).

Các hệ thống con của máy tính lớn, ví dụ như các phần mềm trung gian CICS, IMS và DB2 từ lâu đã cung cấp các thùng chứa với các chức năng quản lý tài nguyên và một ngôn ngữ cấu hình, đang di chuyển hướng tới một phong cách hiện đại của một ngôn ngữ quản lý chính sách tài nguyên và một bộ tiêu chuẩn của các dịch vụ mà thùng chứa cung cấp. Trong khi đó, thành phần hóa các ứng dụng hiện có vẫn có thể cung cấp các lợi ích đáng kể trong việc sử dụng lại và tính linh hoạt.

Có một số các vấn đề kỹ thuật được đề cập giải quyết trong việc áp dụng một mẫu thành phần hóa. Một số được liệt kê ở đây và nhiều khả năng sẽ được thảo luận chi tiết hơn trong trong các bài viết tiếp theo. Có lẽ thách thức khó khăn nhất là thu thập các mã có liên quan từ nhiều tệp tin nguồn; các công cụ phát triển có thể giải quyết nhanh chóng và có hiệu quả nhiệm vụ này. Một thách thức khác là thiết kế lại các phương tiện để chia sẻ thông tin giữa hai hoặc nhiều đoạn mã mà trước đó chỉ là một phần của chỉ một mô đun; việc chuyển thông tin trong các thông số, mặc dù có thể thực hiện được, không phải lúc nào cũng là giải pháp tốt nhất.

Thế nào là một thành phần?

Hầu hết các cuộc thảo luận trước đã tập trung vào các yêu cầu kỹ thuật cho một mảnh phần mềm được đặt tên là một thành phần. Phần này bắt đầu đề cập đến cách làm thế nào để nhận biết các thành phần tiềm năng trong một ứng dụng hiện có. Bạn sẽ tìm hiểu về các công cụ và cách làm thực tiễn tốt nhất nhằm khám phá và tạo ra các thành phần ở các phần sau trong bài viết này.

Khám phá thành phần là một nhiệm vụ thiết kế để xác định các ranh giới cấu trúc và các ranh giới lô gic: các dữ liệu và các hành vi nào sẽ đặt vào trong một thành phần và các dữ liệu và các hành vi nào sẽ thuộc về thành phần khác. Khi các thành phần được tạo ra, việc đăng ký chúng và các thuộc tính căn bản của chúng trong một cơ sở dữ liệu sử dụng lại sẽ cho phép các nhà phát triển khác tìm thấy và tái sử dụng chúng.

Các thành phần có nhiều nét giống với các đối tượng trong việc lập trình hướng đối tượng. Vì vậy, không có gì đáng ngạc nhiên là quá trình khám phá thành phần cũng giống với việc thiết kế hướng đối tượng. Tại mức khái quát nhất, một thành phần cung cấp các dịch vụ liên quan đến một trong hai:

  1. Một kiểu dữ liệu (data), cụ thể, ví dụ như khách hàng hay sản phẩm.
  2. Một kiểu quy trình xử lý (process) cụ thể (ví dụ như bảng lương, gửi hóa đơn thanh toán hoặc dự toán). Các thành phần như vậy thường sử dụng và tích hợp nhiều kiểu dữ liệu. Ví dụ, việc gửi hóa đơn thanh toán tập hợp các thông tin về các sản phẩm, các khách hàng, các đơn đặt hàng và các quy trình khác, như là vận chuyển và nguồn tài chính. Trong thực tế, có rất nhiều kiểu quy trình khác nhau và các nhà thiết kế thường tạo ra các thể loại thành phần có liên quan đến quy trình xử lý để tận dụng lợi thế của các khía cạnh giống nhau của các kiểu quy trình.

Trong khi một số chuyên gia nhận biết các thành phần có liên quan đến dữ liệu trước tiên -- vì tin tưởng điều này tạo điều kiện thuận lợi cho việc nhận biết tiếp theo các thành phần liên quan đến quy trình xử lý -- chúng tôi khuyên bạn nên đi đều giữa hai hoạt động ấy, điều chỉnh các định nghĩa thành phần ban đầu của bạn khi chi tiết hóa thiết kế của mình.

Bạn hãy bắt đầu bằng cách ánh xạ tương ứng các cấu trúc và các chuỗi hiện có tới các khái niệm mức nghiệp vụ. Các công cụ mô hình hóa như Trình mô hình hóa phần mềm Rational của IBM (IBM Rational® Software Modeler) -- một cải tiến tuyệt vời so với các công cụ đơn giản như các bảng tính hoặc các cơ sở dữ liệu -- hỗ trợ hình dung trực quan các mối quan hệ của phần mềm và tạo điều kiện thuận lợi cho việc kiểm tra hợp lệ và các nhiệm vụ phân tích khác. Các chú thích hay các phần mở rộng của siêu mô hình (metamodel) liên kết các mô hình của bạn tới mã đang được phân tích. Các mô hình này chứa các định nghĩa ban đầu của cả các thành phần liên quan đến quy trình xử lý lẫn các thành phần liên quan đến dữ liệu, mà bạn chỉnh sửa khi bạn định nghĩa các thành phần. Mô hình đã hoàn thành là một bản thiết kế chi tiết để sắp xếp mã hiện có vào các thành phần.

Các nhà phát triển có thể sử dụng bản thiết kế chi tiết đó để chỉnh sửa mã để đưa vào trong các thành phần. Trong một số trường hợp, các vỏ thành phần được tạo ra trực tiếp từ mô hình, ta luôn luôn có thể tạo bằng tay các vỏ thành phần từ mô hình. Các mã được tái sử dụng sau đó sẽ được trích xuất từ mã nguồn của ứng dụng và chèn vào bên trong các vỏ thành phần. Một số việc chỉnh sửa cuối cùng là cần thiết để làm cho các mã này tương thích với các mã đã có trong vỏ thành phần và với các giao diện mà vỏ thành phần định nghĩa.

Có nhiều việc với quá trình này hơn là những mô tả ngắn gọn ở trên có thể gợi ra. Hãy chuẩn bị sẵn sàng cho nhiều thử nghiệm ban đầu. Chọn một dự án thành phần hóa mà sẽ mang lại lợi ích kinh doanh khi nó thành công, nhưng hãy tránh các dự án phức tạp hoặc những dự án mà thời hạn là trọng yếu với việc kinh doanh, đã ấn định chắc chắn hoặc những nơi ít dung thứ việc thử nghiệm (và các lỗi). Việc nghe lời khuyên từ các chuyên gia và việc cộng tác với các dự án tương tự hầu như luôn luôn có lợi. Hãy chắc chắn rằng bạn hiểu được lý lẽ cơ bản đằng sau lời khuyên mà bạn nhận được và rằng nó có liên quan đến các mục tiêu của bạn.

Bạn sẽ thấy rằng các thành phần liên quan đến quy trình xử lý tập hợp (lắp ráp) các dữ liệu khác và các thành phần liên quan đến quy trình xử lý khác. Các giao diện dịch vụ của các thành phần liên quan đến quy trình xử lý này trở thành các giao diện cho dịch vụ mới, được thành phần hóa để thay thế cho ứng dụng cũ. Có thể sẽ hiệu quả hơn khi viết các thành phần quy trình xử lý thay đổi thường xuyên bằng một ngôn ngữ đặc thù quy trình, chẳng hạn như Business Process Execution Language (BPEL- Ngôn ngữ thi hành quy trình nghiệp vụ). Bởi vì BPEL có thể mô tả các quy trình cô đọng hơn ngôn ngữ Java hoặc COBOL, số lượng thay đổi sẽ được giảm bớt. Ngôn ngữ Java, do nó là một ngôn ngữ thông dịch, hỗ trợ các chu kỳ thay đổi/thử nghiệm nhanh chóng, là tốt hơn cho việc này khi so với COBOL nếu như các quy trình xử lý không phải là trọng yếu về mặt hiệu năng.

Một dự án SOA nói chung thường chứa mã mới quan trọng, bổ sung thêm sự tích hợp dữ liệu hoặc tự động hóa quy trình mà trước đây do con người thực hiện; mã mới này cần phải tuân theo các chỉ dẫn thành phần hóa. Nó có thể được triển khai thực hiện bằng BPEL, ngôn ngữ Java hoặc COBOL tùy thuộc vào các nhu cầu của dự án và các kỹ năng hiện có.


Các cách thực hành tốt nhất

Quản lý danh mục phần mềm

Bước đầu tiên trong một dự án cơ cấu lại SOA thường là kiểm kê các phần mềm hiện có và các tạo phẩm hệ thống, nhận biết các sự phụ thuộc lẫn nhau giữa chúng. Vì dự án SOA được thúc đẩy bởi mong muốn làm cho việc triển khai CNTT của các qui trình nghiệp vụ linh hoạt hơn, sẽ rất có ích khi kết hợp các tạo phẩm với các qui trình nghiệp vụ mà chúng hỗ trợ. Việc liên kết các tạo phẩm với lịch sử phát triển của chúng (các số liệu thống kê thay đổi, đầu tư phát triển, các khiếm khuyết và v.v) có thể chỉ ra mẫu có nhiều khả năng dành cho cơ cấu lại dựa theo SOA. Mặc dù một dự án thí điểm SOA nhỏ có thể không cần sự kiểm kê này, nhưng việc bảo trì đang diễn ra và các dự án SOA tương lai sẽ được hưởng lợi từ cách thực hành tuyệt vời này.

Có thể sử dụng việc kiểm kê danh mục phần mềm này để nhận biết phần mềm mang lại ít hay không mang lại lợi ích cho việc kinh doanh. Những phần mềm như vậy có thể được thay thế bằng phần mềm thương mại hoặc đơn giản là không dùng nữa. Việc kiểm kê cũng có thể nhận biết các phần tử phần mềm trọng yếu phải được cơ cấu lại để đạt được các mục tiêu của dự án. Ví dụ, nếu mục tiêu là giảm bớt thời gian cần thiết để sinh ra một hóa đơn sau khi cung cấp một dịch vụ, dòng công việc thanh toán phải được rà soát để nhận ra các hành động gây chậm trễ và thiết kế lại chúng. Ví dụ, nếu bạn đã nhận thấy rằng qui trình nghiệp vụ tổng thể bị tạm dừng cho đến khi một ứng dụng xử lý theo bó chạy thi hành và tạo ra các dữ liệu cần thiết, bạn có thể thiết kế lại ứng dụng xử lý theo bó để nó chạy thường xuyên hơn.

Việc kiểm kê quản lý danh mục phần mềm giúp cho các nhà quản lý và kiến trúc sư CNTT quyết định ở đâu và làm thế nào để phân bổ tài nguyên phát triển để đạt lợi ích kinh doanh cao nhất. IBM cung cấp công cụ nhà quản lý danh mục phần mềm Rational (Rational Portfolio Manager) rất có ích cho mục đích này.

Phát triển phần mềm

Các nghiên cứu tiết lộ các mặt tốn kém nhất của việc phát triển và bảo trì phần mềm: phân tích thay đổi, thiết kế và thử nghiệm. Chỉ riêng việc thử nghiệm có thể tiêu tốn một nửa ngân sách dành cho một chu kỳ bảo trì ứng dụng. Đối với một ứng dụng hiện có, các công cụ phân tích thay đổi, như IBM WebSphere Studio Asset Analyzer (WSAA- Trình phân tích tài sản WebSphere Studio của IBM) và các công cụ tương tự từ các nhà cung cấp khác, đẩy nhanh giai đoạn phân tích và giảm bớt các lỗi. Kết quả phân tích mã nguồn của chúng, Job Control Language (JCL-Ngôn ngữ kiểm soát công việc), siêu dữ liệu cấu hình phần mềm trung gian và các tạo phẩm khác được nắm giữ trong một cơ sở dữ liệu. Một truy vấn tới cơ sở dữ liệu này có thể xác định các mô đun mã nguồn nào và các tệp tin dữ liệu nào cần phải thay đổi nếu phần tử dữ liệu hiện có bị thay đổi hoặc một phần tử dữ liệu mới được thêm vào. Tính đếm các tác động và việc sử dụng mục dữ liệu có thể giúp đánh giá những nỗ lực của công việc phát triển.

Các công cụ phân tích thay đổi cũng có thể cải thiện việc lập kế hoạch thử nghiệm bằng cách nhận biết các thay đổi với các dữ liệu thử nghiệm cũng như các phép thử nghiệm không cần thiết, không tác động lên bất kỳ mã đã thay đổi nào. Các công cụ khác theo vết phạm vi thử nghiệm của ứng dụng bằng bộ thử nghiệm.

Một cách làm thực tế tốt nhất bao gồm các hoạt động đổi mới khuôn mặt hoặc thành phần hóa trong một chu kỳ bảo trì ứng dụng bình thường, đưa thêm vào các thay đổi dần dần trong bối cảnh của các thay đổi khác. Cách tiếp cận này, đôi khi được gọi là cơ cấu lại tại chỗ (in-place reengineering), làm giảm bớt các rủi ro vượt phạm vi (scope creep) và các sự phức tạp bất ngờ.

Các công cụ phát triển hiện đại, dựa trên trạm làm việc (workstation-based) mang lại năng suất tốt nhất và hỗ trợ các thói quen lập trình tốt. Các công cụ tích hợp loại trừ các bước dễ xảy ra lỗi, như là in ấn và sao chép các thông tin từ một công cụ này đến công cụ kế tiếp. Một công cụ tích hợp cho phép bạn chuyển giao các kết quả của một dự án phân tích (ví dụ, một danh sách các tệp tin mã nguồn và các tệp tin dữ liệu bị ảnh hưởng) vào trong một môi trường phát triển tích hợp (Integrated Development Environment - IDE) ở đó một nhà phát triển có thể truy cập và chỉnh sửa các tệp tin mã nguồn. Các nhà phát triển có kinh nghiệm với các công cụ phát triển dựa trên 3270 đôi khi không tự nguyện di chuyển đến một IDE, nhưng các công cụ IDE đã tỏ ra có năng suất cao hơn và một khi đã làm chủ được nó, các nhà phát triển sẽ rất hài lòng với chúng. WebSphere Developer for zSeries® của IBM, một IDE IBM mời dùng nhằm đến các nhà phát triển máy tính lớn, bao gồm các công cụ để thêm khả năng SOA cho các ứng dụng máy tính lớn hiện có. Nhà phát triển WebSphere cho zSeries là một mở rộng của các IDE Rational của IBM, cụ thể là của Nhà phát triển ứng dụng Rational của IBM, và nó bao gồm các khả năng phát triển thành phần của J2EE của sản phẩm này.

Các dịch vụ đã đổi mới khuôn mặt và được thành phần hóa thường được tập hợp lại thành (một bộ phận của) các qui trình nghiệp vụ. Các công cụ đặc biệt để tạo các qui trình BPEL và tích hợp các trình hòa giải (mediator) của một Kênh các dịch vụ doanh nghiệp (Enterprise Services Bus) được cung cấp trong các IDE IBM, ví dụ như là Nhà phát triển tích hợp WebSphere của IBM. WebSphere Developer và WebSphere Developer cho zSeries cùng nhau tạo thành một gói phần mềm IDE đầy đủ để phát triển SOA trên máy tính lớn. Ngoài ra, WebSphere Developer cho zSeries có chứa các công cụ cho các tích hợp đơn giản, ví dụ như việc tuần tự hóa các giao dịch CICS bên trong CICS.

Mô hình hóa và phân tích có thể trở thành các phần không thể thiếu được của quá trình thiết kế và cơ cấu lại phần mềm của bạn. Sử dụng thông tin từ WSAA, các mô hình kiến trúc phần mềm có thể được xây dựng trong Trình mô hình hóa phần mềm Rational (Rational Software Modeler). Các mô hình sau đó có thể được sử dụng để khám phá các thay đổi phần mềm có tiềm năng. Việc phân tích tiếp theo các mô hình có thể xác minh có bao nhiêu công việc cần thiết để thực hiện những thay đổi này và nhận biết các vấn đề kỹ thuật tiềm năng.

IBM cung cấp một ngôn ngữ lập trình mới, Enterprise Generation Language (EGL- Ngôn ngữ tạo hình doanh nghiệp) và một IDE cho ngôn ngữ này, một ngôn ngữ dễ sử dụng bởi các nhà phát triển ứng dụng và hỗ trợ việc lập trình SOA. Ngôn ngữ này và IDE cải thiện năng suất bằng cách làm đơn giản hoá các nhiệm vụ lập trình và hướng dẫn họ trong việc áp dụng đúng đắn các nguyên tắc thiết kế SOA.

Xác định vấn đề

Các ứng dụng SOA là sự lắp ráp nhiều thành phần. Các công cụ truyền thống, ví dụ như các trình gỡ rối (debugger) và các công cụ phân tích nội dung sổ ra (dump) sau lỗi vẫn còn có ích, nhưng phải được sử dụng cùng với các công cụ theo dõi và quản lý ứng dụng được thiết kế đặc biệt cho các ứng dụng SOA, ví dụ như là các công cụ Trình quản lý ứng dụng phức hợp Tivoli® của IBM (IBM Tivoli® Composite Application Manager) và IBM Tivoli OMEGAMON® XE. Sự lắp ráp cung cấp thêm các điểm theo dõi tại các giao diện thành phần. Các điểm theo dõi này có thể cung cấp thêm chi tiết để đẩy nhanh việc xác định vấn đề và khôi phục lại.

Viết mã phòng thủ

Các nhà phát triển thành phần lập luận khá tự nhiên rằng vì họ không thể biết các thành phần của họ sẽ được sử dụng như thế nào, họ sẽ mở rộng kiểm tra các dữ liệu và các tham chiếu đầu vào cũng như các kết quả và các tham chiếu đầu ra mà các thành phần sinh ra. Sự phối hợp các thành phần như vậy dẫn đến lặp lại nhiều lần việc kiểm tra hợp lệ các dữ liệu được chuyển qua lại giữa các thành phần với hiệu năng thấp hơn so với các cấu trúc ứng dụng đơn khối. Hơn nữa, các kiểu dữ liệu được chọn làm chữ ký đầu vào và đầu ra của thành phần mà một nhà phát triển nghĩ rằng có thể khuyến khích việc tái sử dụng rộng rãi nhất có thể không mang lại hiệu năng tốt nhất. Các thành phần như vậy, khi được phối hợp lại, có thể phải chịu chi phí hoạt động chuyển đổi không cần thiết khi dữ liệu được chuyển qua lại giữa các thành phần. Phép chuyển đổi dữ liệu COBOL sang XML và từ XML chẳng hạn, khá tốn công - và hoàn toàn không cần thiết - khi mà cả trình khách và dịch vụ đều được viết bằng COBOL và việc truyền vận có khả năng truyền dẫn thông tin nhị phân.

Việc phát triển thành phần luôn luôn là một sự thỏa hiệp giữa hiệu năng và chất lượng của các yêu cầu dịch vụ của ứng dụng với khả năng tái sử dụng và tính khái quát của các thành phần hợp thành của chúng. Xem xét cách sử dụng chính của thành phần bên trong các cấu trúc ứng dụng dẫn đến việc bố trí kiểm tra dữ liệu hợp lệ thích hợp hơn -- ví dụ, chỉ tại các ranh giới tin cậy có quản lý. Nếu một cách sử dụng chính mới được dự tính trước cho một thành phần, hãy xét xem việc này có tạo ra một ranh giới tin cậy mới và cần thiết kiểm tra hợp lệ bổ sung thêm ở bên ngoài thành phần không. Cũng áp dụng điều tương tự khi định nghĩa các chữ ký dữ liệu đầu vào và đầu ra cho các thành phần; hãy thiết kế chúng để làm việc tốt trong ứng dụng chính và thay đổi chúng chỉ khi cách sử dụng chúng thay đổi đáng kể.

SOA cũng bao gồm các bộ thích ứng (adapter) để thay đổi các chữ ký dữ liệu đầu vào và đầu ra của các hoạt động của thành phần; các bộ thích ứng bảo vệ các khách hàng của một dịch vụ khỏi các thay đổi trong giao diện của nó với một chi phí thực hiện không đáng kể.


Kiến trúc thành phần cho các ứng dụng

IBM, cùng với các đối tác kinh doanh của mình, đã bắt đầu phát hành thông tin về các nguyên tắc thiết kế, các cách làm thực tế tốt nhất và các công cụ phát triển để triển khai thực hiện các thành phần. Bộ các nguyên tắc chỉ dẫn và các công cụ này được gọi là Service Component Architecture (SCA- Kiến trúc thành phần dịch vụ) (xem Tài nguyên để tìm liên kết đến một bài viết về chủ đề này). Mặc dù các nguyên tắc thiết kế và các cách làm thực tế được mô tả chủ yếu bằng cách sử dụng Java và J2EE, hầu như tất cả các nguyên tắc và các cách làm thực tế này đều có thể được triển khai thực hiện bằng các ngôn ngữ khác mà các nhà phát triển cho máy tính lớn quan tâm (chẳng hạn như C, COBOL và PL/I) và mã kết quả được triển khai trong phần mềm trung gian, ví dụ như DB2, CICS, và IMS. IBM đang làm việc với các bên cộng tác trong ngành công nghiệp, các tổ chức phát triển phần mềm, các cơ quan tiêu chuẩn hóa để định nghĩa SCA và Service Data Objects (SDOs -Các đối tượng dữ liệu dịch vụ) dành cho các ngôn ngữ khác và phần mềm trung gian nói trên và công bố các nguyên tắc thiết kế và các cách làm thực tế trong năm tiếp theo. SCA và SDO nên được sử dụng cho tất cả các nỗ lực phát triển ứng dụng mới. SCA cũng được mong đợi như là kiến trúc đích chính cho các hoạt động thành phần hóa các ứng dụng hiện có.

SCA sẽ là cơ sở thiết kế để tạo ra các thành phần và các khối tập hợp ứng dụng có thể bao gồm các thành phần tương hợp được viết bằng nhiều ngôn ngữ khác nhau. Các thành phần công nghệ cần thiết để tạo điều kiện thuận lợi cho điều này bây giờ đang được đặt vào vị trí. Ví dụ, COBOL doanh nghiệp cho z/OS® của IBM và PL/I doanh nghiệp cho z/OS của IBM cả hai đều hỗ trợ việc xử lý XML và COBOL doanh nghiệp cho z/OS cung cấp các tiện ích mới lạ để tương tác qua lại với Java. Rational Application Developer và WebSphere Developer cho zSeries cung cấp các công cụ để tạo ra các bộ thích ứng dữ liệu cho phép chuyển qua lại các kiểu dữ liệu phức tạp giữa Java và các ngôn ngữ khác. Như là một sự biểu diễn công nghệ, IBM đã tung ra thông tin cho phép các nhà phát triển tạo ra các thành phần COBOL chạy thi hành trong thùng chứa WebSphere Application Server cho z/OS của IBM.


Tóm tắt

SOA cung cấp các công cụ, các kỹ thuật và các cách làm thực tế tốt nhất để rút ra logic nghiệp vụ được thể hiện trong danh mục các phần mềm hiện có của doanh nghiệp của bạn. SOA cho phép phối hợp lại các tài sản phần mềm đáng giá này theo các cách thức mới, để sản sinh ra một triển khai CNTT linh hoạt hơn cho thiết kế nghiệp vụ của bạn và cho phép thích nghi với sự thay đổi các nhu cầu nghiệp vụ. Các nguyên tắc SOA cung cấp một mở rộng thực hành của các cách làm tốt nhất trong việc tái cơ cấu hiện có và áp dụng đồng đều cho phần mềm hiện có và phần mềm mới được tạo ra.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

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=416859
ArticleTitle=Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 11: SOA và môi trường phần mềm trên máy tính lớn
publish-date=07312009