Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 5: Các giao diện người dùng hướng-dịch vụ

Một mô hình lập trình hướng dịch vụ có thể làm đơn giản hóa việc phát triển các tương tác con người-chương trình máy tính bằng cách trừu tượng hóa các giao diện, tiêu chuẩn hóa các thông điệp và kết hợp các nguồn thông tin độc lập ở tầng trình bày (presentation layer) dưới sự kiểm soát của một người dùng hoặc người quản trị. Bài viết thứ năm này trong loạt bài viết về mô hình lập trình SOA của IBM trình bày các dịch vụ trực diện người dùng (user facing) cũng như các dịch vụ được người dùng cung cấp thông qua Trình quản lý tác vụ do con người thực hiện (Human Task Manager). Các bài viết trước đây trong loạt bài viết này đã giới thiệu một cách truy cập dữ liệu trung lập về ngôn ngữ và mô hình lập trình các dịch vụ web dựa trên các khái niệm của kiến trúc hướng-dịch vụ (SOA).

Stefan Hepper, Kiến trúc sư phần mềm, WSO2 Inc

Stefan Hepper là kiến trúc sư chịu trách nhiệm về mô hình lập trình Cổng WebSphere Portal và các API công cộng và đã là đồng lãnh đạo Đặc tả kỹ thuật cổng web Java, JSR 168. Stefan cũng bắt đầu dự án Pluto tại Apache; dự án này cung cấp việc thực hiện khung tham chiếu JSR 168. Stefan đã đọc một số bài giảng tại các cuộc hội thảo quốc tế, như JavaOne, đã công bố nhiều bài báo khác nhau và là đồng tác giả của cuốn sách Điện toán mọi nơi (Pervasive Computing). Ông quan tâm nghiên cứu về kiến trúc phần mềm dựa trên thành phần, cơ sở hạ tầng điện toán lan tỏa, và tất nhiên là cả về các cổng web và portlets. Stefan nhận được Bằng tốt nghiệp Khoa học Máy tính của Trường Đại học Karlsruhe, Đức và năm 1998 ông đến với Phòng thí nghiệm Phát triển Boeblingen của IBM


Tác giả chuyên nghiệp của
        developerWorks

Stefan Liesche, Kiến trúc WebSphere Portal, IBM Development Laboratory

Stefan Liesche là một kiến trúc sư CNTT cao cấp được chứng nhận trong phòng thí nghiệm phát triển của IBM ở Boeblingen, Đức. Ông có 11 năm kinh nghiệm trong lĩnh vực phát triển phần mềm. Ông có bằng thạc sĩ khoa học về khoa học máy tính của trường Đại học Hildesheim, Đức. Ông gia nhập IBM vào năm 1998 như là một thành viên của nhóm các dịch vụ, ở đây chuyên môn của ông là các giải pháp doanh nghiệp điện tử (e-business) đầu cuối đến đầu cuối với quy mô lớn dành cho các môi trường phức tạp. Stefan vẫn đang làm việc với dự án Cổng IBM WebSphere Portal trong nhiều năm qua. Đầu tiên ông đã từng làm công việc xây dựng các giải pháp cổng web quy mô lớn trước khi tham gia vào đội kiến trúc phát triển WebSphere Portal. Ông là kiến trúc sư trưởng của Workplace và Portal Foundation



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

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



10 07 2009

Các giao diện người dùng dành cho kiến trúc hướng-dịch vụ

Theo tài liệu, các dịch vụ web thường được thảo luận trong bối cảnh của các tương tác chương trình-đến-chương trình. Tuy nhiên, bài viết này làm sáng tỏ cách một mô hình lập trình SOA cho các dịch vụ web cũng có thể tiến hành phát triển các dịch vụ trực diện con người (human-facing). Có một số cách tiếp cận và mô hình lập trình mà bạn có thể sử dụng để tạo các thành phần UI trực diện người dùng và kết hợp chúng theo phương thức động để biểu thị một UI nhất quán.

Hơn thế nữa, thành phần Trình quản lý tác vụ do con người thực hiện (Human Task Manager) mới của Trình dàn dựng qui trình WebSphere (WebSphere Process Choreographer) tạo điều kiện cho bước ngoặt mới bằng cách cho phép một loại hình dịch vụ mới: các dịch vụ được cung cấp bởi con người bên trong khung công tác của một qui trình nghiệp vụ được triển khai thực hiện bằng phần mềm. Chúng tôi sẽ trình bày chủ đề đó ở phần cuối của bài viết này.

Mẫu hình phát triển Model-View-Controller (MVC- Mô hình -Khung nhìn- Điều khiển ) nhấn mạnh các khung công tác ứng dụng UI hiện đại nhất. Tầng mô hình là các thao tác SOA; tầng khung nhìn là các UI. Các công nghệ UI có thể biểu hiện thông tin trên các thiết bị khác nhau, từ các thiết bị điện tử mới lạ và các điện thoại thông minh đến các trình duyệt và các trình khách phong phú có khả năng xử lý phía khách rất đáng kể. Các công cụ và phần mềm trung gian kết nối các công nghệ UI của tầng khung nhìn tới dữ liệu và các dịch vụ web tầng mô hình.

Trong cách tiếp cận SOA, các môi trường để chứa các thành phần được trừu tượng hóa như là các thùng chứa (containers); chúng cung cấp một tập hợp các dịch vụ hạ tầng cơ sở quen biết. Từ phối cảnh UI, có ba thùng chứa chính để chủ chứa các thành phần UI phía khách là:

  • Trình duyệt Web cơ bản.
  • Trình duyệt Web được khuyếch trương với Java™Script và HTML động.
  • Công nghệ Khách Workplace của IBM (IBM Workplace™ Client Technology™) -- đó là trình khách phong phú Eclipse cộng với sự hỗ trợ phía khách của Máy chủ Ứng dụng IBM WebSphere® IBM nguyên thủy.

Các thùng chứa có thể được tăng cường bằng cách hỗ trợ các công nghệ như servlets, JavaServer Pages (JSP) và JSP Tags; Struts để phân đoạn (sequencing) trang; JavaServer Faces (JSF) để cấu tạo trang cao cấp; và portlets để kết hợp các khung nhìn của nhiều ứng dụng trên cùng một trang.

Các khung công tác để phát triển UI

Các khung công tác để phát triển UI có thể làm đơn giản hóa việc tạo ra các ứng dụng hướng-người sử dụng phức tạp. Dưới đây là các khung công tác UI thường được dùng để tạo ra các thành phần UI:

  • Struts, có cộng đồng các nhà phát triển lớn nhất và sự hỗ trợ các công cụ tuyệt vời, là một dự án mã nguồn mở Apache, báo hiệu trước đặc tả kỹ thuật Portlet Java, JSR 168 (Java Portlet Specification, JSR 168) (xem Tài nguyên để có đường liên kết đến các trang web Struts). Struts là một khung công tác MVC nhiều trang để phát triển UI dựa trên-máy chủ khi sử dụng mẫu hình servlet/JSP. Một phiên bản đặc biệt của Struts, thư viện phiên bản 1.1 hỗ trợ các portlet JSR 168 trên cổng web WebSphere IBM (IBM WebSphere Portal).
  • JavaServer Faces là một sự thực hiện MVC dành cho các ứng dụng Web của Java và xây dựng thêm dần dựa trên các công nghệ trước đó. Nó rất thích hợp cho việc phát triển portlet, cung cấp các portlet và servlet, xử lý trạng thái, xác nhận hợp lệ và đánh giá sự kiện. Một trang JSF có một hoặc nhiều mô hình cục bộ để tương tác với các thành phần kiểm soát UI trên trang web. Các thành phần kiểm soát này biểu hiện các thuộc tính UI thành kết quả đầu ra và một logic phức tạp đảm bảo chúng được trình bày "đúng" vị trí. Mô hình phía khách có thể được được nối đến Kênh dịch vụ doanh nghiệp (Enterprise Service Bus) để gửi và nhận các sự kiện.
  • Java Widget Library (JWL-Thư viện tiện ích Java), một bộ tiện ích mở rộng có thể được sử dụng bởi các lập trình viên cổng web và portlet, bổ sung thêm quá trình xử lý phía khách bằng JavaScript cho JSF và sẽ được Rational® Suite® DevelopmentStudio. của IBM hỗ trợ. Việc cập nhật tại chỗ khung nhìn trên máy khách tiết kiệm việc truyền dẫn vòng tròn đến máy chủ, rút ngắn phần lớn thời gian đáp ứng và cải thiện đáng kể trải nghiệm của người dùng.

Các cổng web (Portals) mang lại sự hỗ trợ UI lớp đầu tiên. Trong kiến trúc cổng web, một portlet (thường được phát triển bằng cách sử dụng một trong những khung công tác UI đề cập ở trên) là các khối xây dựng cơ bản. Kiến trúc này cho phép các nhà phát triển tập trung vào khía cạnh độc đáo của ứng dụng của họ và giao phó các chức năng chung cho vòng đời, sự tùy biến của từng người dùng, kết hợp và tích hợp với các thành phần khác vào phần mềm trung gian (middleware).

Các phần sau mô tả các thành phần portlet của các dịch vụ riêng biệt và các cổng web dưới dạng một cơ chế kết hợp dịch vụ.


Portlets dành cho UI hướng-dịch vụ

Thành phần portlet triển khai thực hiện một giao diện và giao thức dịch vụ chuẩn hóa. Đặc tả kỹ thuật Portlet của Java và chuẩn các dịch vụ Web cho Portlet từ xa (WSRP) định nghĩa giao diện này cho Java và các dịch vụ web, tương ứng (xem Tài nguyên để biết thêm thông tin về WSRP). Hai tiêu chuẩn này là đủ giống nhau để cho các portlet được viết cho cả hai giao diện có thể hoán đổi cho nhau nếu có các thùng chứa hoặc máy chủ ủy quyền (proxy) thích hợp có mặt.

Ví dụ về portlet Java

Mỗi portlet của Java thực hiện giao diện portlet hay mở rộng một tầng có thực hiện nó. Giao diện này định nghĩa hợp đồng dịch vụ giữa portlet và thùng chứa của nó và định nghĩa vòng đời của portlet:

  • Khởi tạo portlet và đặt nó vào trong dịch vụ (phương thức init).
  • Xử lý yêu cầu (phương thức processActionrender).
  • Gỡ bỏ portlet ra khỏi dịch vụ (phương thức destroy).

Trong quá trình xử lý yêu cầu, thùng chứa portlet gọi các phương thức của portlet sau đây:

  • Phương thức processAction để thông báo cho portlet về một hành động của người dùng. Chỉ có một hành động của người sử dụng ứng với mỗi yêu cầu phía khách sẽ được kích hoạt. Portlet có thể phát ra một chuyển hướng, thay đổi chế độ portlet hay trạng thái cửa sổ của nó hoặc sửa đổi trạng thái của nó.
  • Phương thức render để yêu cầu một đoạn đánh dấu.

Các portlet cũng có thể gọi thêm các dịch vụ để thực hiện các chức năng mong muốn. Ví dụ trong Liệt kê 1 sử dụng một dịch vụ web để lấy ra và hiển thị các bảng giá cổ phiếu cho một người dùng cụ thể.

Liệt kê 1. Mã ví dụ của portlet bảng giá cổ phiếu
public class StockQuotePortlet extends GenericPortlet {

	private ServiceManager serviceManager;

	public void init(PortletConfig config) throws PortletException {
		serviceManager = new ServiceManager();
	}

	public void doView(RenderRequest request, RenderResponse response) 
    throws PortletException, IOException {
		
       	response.setContentType("text/html");    

       	// invoke autogenerated wrapper to locate service
	NetXmethodsServicesStockquoteStockQuoteServiceLocator loc = 
		new NetXmethodsServicesStockquoteStockQuoteServiceLocator();
	NetXmethodsServicesStockquoteStockQuotePortType port = 
		loc.getNetXmethodsServicesStockquoteStockQuotePort();

	// loop through all stock quotes the user is interested in
	PortletPreferences prefs = request.getPreferences();
	Iterator quoteKeys = prefs.getMap().keys().iterator();
	String key;
	Float quote;
	StockBean quoteBean = new StockBean();
	while ( quoteKeys.hasNext() ) {
		key = quoteKeys.next();
	   		quote =  port.getQuote (key);
		quoteBean.add(key, quote);
	}

	request.setAttribute("StockQuoteBean", quoteBean);

    // render stock quotes using a JSP        
  PortletRequestDispatcher rd = getPortletContext().getRequestDispatcher("jsp/View.jsp");
  rd.include(request,response);

	}
}

Phần này minh họa cách bạn có thể thực hiện một dịch vụ UI bằng cách sử dụng đặc tả kỹ thuật Portlet của Java như thế nào và portlet của bạn có thể gọi thêm các dịch vụ web như thế nào. Phần kế tiếp chỉ ra cách công bố UI của bạn như là một dịch vụ web khi sử dụng WSRP.

Dịch vụ Web cho các Portlet từ xa (WSRP)

Web Services for Remote Portlets (WSRP - Dịch vụ Web cho các Portlet từ xa) là tiêu chuẩn để biểu hiện từ xa của các portlet, cho phép một cổng web kết hợp nội dung từ nhiều nguồn. WSRP mở rộng các khả năng tích hợp các dịch vụ web thành các thành phần hướng-trình bày và trưng ra tầng khung nhìn để chia sẻ chung xuyên suốt các nền tảng, các ngôn ngữ thực hiện và các nhà cung cấp. Các dịch vụ cung cấp nội dung và ứng dụng có thể được phát hiện và được cắm thêm vào trong các ứng dụng tuân thủ chuẩn mà không cần bất kỳ nỗ lực lập trình thêm nào.

Các dịch vụ Web điển hình sử dụng mẫu hình trình bày từ xa, có nghĩa là tất cả các logic khung nhìn thi hành trên máy khách, trong khi logic ứng dụng và tầng dữ liệu (trình điều khiển và mô hình) cư trú trên máy chủ. Ngược lại, WSRP phân tách sự trình bày giữa máy khách và máy chủ theo mẫu hình phân tán.

Hình 1. Các dịch vụ web hướng dữ liệu so sánh với các dịch vụ web hướng trình bày của WSRP
So sánh WSRP

Hình ảnh ở trên mô tả sự khác biệt này. Ở phần bên trái là một dịch vụ web hướng dữ liệu điển hình để cung cấp các dữ liệu chưa định dạng; nó phải phụ thuộc hoàn toàn vào mã biểu hiện phía khách để trình bày dữ liệu. (Điều này dẫn đến yêu cầu phải cài đặt và quản lý một thành phần ứng dụng phía khách trên máy khách). Ở phần bên phải là một dịch vụ WSRP; logic trình bày phân tán của nó phân tách nhiệm vụ trình bày thành:

  • Tạo ra ngôn ngữ đánh dấu.
  • Kết hợp các đoạn đánh dấu thành một trang web (không hiển thị).
  • Biểu hiện ngôn ngữ đánh dấu bằng cách sử dụng một thùng chứa phía khách tiêu chuẩn.

Ví dụ về WSRP

Liệt kê 2 hiển thị một ví dụ về yêu cầu getMarkup của WSRP được đưa ra thông qua Simple Object Access Protocol (SOAP - Giao thức Truy cập Đối tượng Đơn giản) từ một trình tiêu thụ WSRP.

Liệt kê 2. Yêu cầu getMarkup của WSRP được đưa ra thông qua SOAP
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"	 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi=
"http://www.w3.org/2001/XMLSchema-instance"> 
      <soapenv:Body>
         <getMarkup xmlns="urn:oasis:names:tc:wsrp:v1:types"> 
            <registrationContext>
               <registrationHandle>192.168.66.57_1096235652731_0</registrationHandle> 
            </registrationContext>
            <portletContext>
               <portletHandle>0.1</portletHandle>   
            </portletContext>   
            <runtimeContext>    
               <userAuthentication>wsrp:none</userAuthentication>    
               <portletInstanceKey>ProxyTest_row1_col1_p1</portletInstanceKey>    
               <namespacePrefix>Pluto_ProxyTest_row1_col1_p1_</namespacePrefix>   
            </runtimeContext>   
            <userContext>    
               <userContextKey>dummyUserContextKey</userContextKey>   
            </userContext>   
            <markupParams>    
               <secureClientCommunication>false</secureClientCommunication>    
               <locales>en</locales>    
               <locales>de</locales>    
               <mimeTypes>text/html</mimeTypes>    
               <mode>wsrp:view</mode>    
               <windowState>wsrp:normal</windowState>    
               <clientData>     
                  <userAgent>WSRP4J Proxy Portlet</userAgent>    
               </clientData>    
               <markupCharacterSets>UTF-8</markupCharacterSets>    
               <validNewModeswsrp:view</validNewModes>    
               <validNewModes>wsrp:help</validNewModes>    
               <validNewModes>wsrp:edit</validNewModes>    
               <validNewWindowStates>wsrp:normal</validNewWindowStates>>    
               <validNewWindowStates>wsrp:maximized</validNewWindowStates>    
               <validNewWindowStates>wsrp:minimized</validNewWindowStates>   
            </markupParams>  
         </getMarkup> 
      </soapenv:Body>
   </soapenv:Envelope>

Đáp ứng của trình sản xuất (producer) WSRP cho yêu cầu này là một đoạn mã HTML mà trình tiêu thụ (thường là một cổng web) có thể kết hợp thành một tài liệu đầy đủ, ví dụ như là một trang của cổng web.

Thay vì triển khai từng ứng dụng hoặc portlet trên mỗi máy chủ có ý định sử dụng nó, rõ ràng là có lợi hơn khi chia sẻ chung các ứng dụng xuyên suốt phạm vi mạng. WSRP cho phép:

  • Quản trị dễ dàng hơn (Easier administration) -- Thay vì quản lý các triển khai tại chỗ của các thành phần có khả năng cắm thêm, các nhà quản trị cổng web có thể duyệt tìm trong sổ đăng ký các dịch vụ WSRP để cung cấp nó. Những người dùng được hưởng lợi vì các dịch vụ mới và tích hợp nội dung theo yêu cầu sẽ có sẵn để sử dụng kịp thời.
  • Phân phối tải (Load distribution) -- Các tải công việc được phân phối trên nhiều máy chủ.
  • Chi phí cơ sở hạ tầng được giảm bớt (Reduced infrastructure cost) -- Các ứng dụng có thể chia sẻ cơ sở hạ tầng lưu trữ ở máy chủ. Ví dụ, việc phân tán chỉ tầng trình bày (thông qua WSRP) của một ứng dụng nhân hàng tầng sau sẽ giữ gìn cho môi trường điện toán có bảo vệ của nhà cung cấp ứng dụng, nhưng người dùng có thể tương tác với UI chia sẻ chung.
  • Kiểm soát trình bày nội dung (Control over content presentation) -- Các nhà cung cấp nội dung và ứng dụng có thể mở rộng tầm với của họ tới những người sử dụng mới khi các cổng web phân tán lại các nội dung.

Các cổng web: kết hợp động UI hướng-dịch vụ

Tại tầng khung nhìn của cổng web, việc tích hợp một số UI của các dịch vụ tầng sau thành một UI được quản lý tập trung có thể làm thống nhất cơ sở hạ tầng CNTT bị đứt đoạn và cung cấp cho những người dùng chỉ một khung nhìn duy nhất về các dịch vụ CNTT với chỉ một UI cần phải nắm vững. Các ứng dụng ban đầu được thiết kế riêng biệt, có thể nối với nhau thành các ứng dụng phức hợp, cho phép thực hiện các chức năng mới. Ví dụ, một portlet e-mail nối vào một portlet cộng tác có thể lọc hộp thư đến (inbox) để hiển thị e-mail đã nhận được chỉ khi người gửi đang trực tuyến và sẵn sàng để trò chuyện (chat) -- một khả năng không có ở cả hai ứng dụng ban đầu.

Một hệ quả đáng ngạc nhiên của mô hình cổng web là việc cải thiện tính lanh lẹn trong cung ứng các nghiệp vụ theo yêu cầu (On Demand Businesses). Các nhà quản trị trở thành những người hợp nhất ứng dụng, những người tạo ra các ứng dụng phức hợp mới -- mà không cần lập trình -- bằng cách định nghĩa các trang mới, bổ sung thêm các portlet cho chúng, đấu nối các portlets với nhau và thiết lập các quyền được phép (kiểm soát truy cập). Một cổng web tự phục vụ cho phép những người dùng điều chỉnh môi trường làm việc của họ theo các nhu cầu riêng chỉ dành cho họ. Kiến trúc cổng web giải phóng các nhà phát triển ứng dụng để họ tập trung vào việc xây dựng giá trị kinh doanh mới.

Trong tương lai, các cổng thậm chí có thể kết hợp các dịch vụ phức hợp và vì thế, có khả năng kết hợp các UI ở một mức cao hơn. Các cổng web có thể tích hợp liên tục các nội dung từ các cổng web khác, cung cấp khả năng tích hợp nội dung theo chiều ngang ở quy mô toàn doanh nghiệp.


Các tương tác hai chiều của người dùng trong SOA

Cổng web WebSphere là một cổng kết nối (gateway) có sự tham gia của người dùng trong kiến trúc hướng dịch vụ. Sự tham gia này có thể theo hai chiều (bidirectional): người dùng có thể vừa truy cập và vừa cung cấp các dịch vụ thông qua các giao diện portlet thích hợp.

Các tác vụ do con người thực hiện trong một luồng công việc

Khái niệm về một người dùng máy tính như là một bên cung cấp dịch vụ là quen thuộc khi chúng ta bước ra ngoài lĩnh vực các dịch vụ web: tất cả chúng ta đều đã từng yêu cầu nhân viên dịch vụ điện thoại tìm ra một số điện thoại. Nhân viên này cung cấp một dịch vụ trả lời cho một yêu cầu dịch vụ bằng lời nói.

Vì vậy, một người có thể là một bên cung cấp dịch vụ và việc gọi dịch vụ có thể được thực hiện dưới dạng một dịch vụ web khi sử dụng một giao diện người dùng dựa trên- cổng web. Cổng web cung cấp thông tin (dữ liệu đầu vào) về một tác vụ cho người dùng, sau đó người dùng thực hiện các tác vụ (dịch vụ) và cung cấp các kết quả (dữ liệu đầu ra) tới cổng web.

Các ví dụ quen thuộc về tác vụ con người làm trong một qui trình dòng công việc là: một kỹ thuật viên quang học kiểm tra thủ công các mắt kính trước khi giao cho khách hàng; một thợ phụ kiểm tra an toàn sau khi lắp lốp xe ô tô mới; và một người quản lý ngân hàng xác nhận nhân dạng của một khách hàng trước khi cho phép rút một lượng tiền mặt lớn. Trong một qui trình nghiệp vụ điển hình, một số bước được thực hiện bởi máy tính và một số bước được thực hiện bởi con người. Hình 2 minh họa một số các cách kết hợp các dịch vụ được thực hiện bởi con người và bởi máy móc.

Trình quản lý tác vụ do con người thực hiện

Human Task Manager (HTM - Trình quản lý tác vụ do con người thực hiện) cung cấp cho những người dùng tham gia vào một quá trình dòng nghiệp vụ một khung nhìn thống nhất về công việc của họ. Bằng cách sử dụng HTM, người dùng có thể làm một công việc hoặc yêu cầu làm một công việc cần phải được hoàn thành, độc lập với việc triển khai thực tế của dịch vụ tương ứng như thế nào.

HTM cũng cung cấp các các dịch vụ web tự động với một khung nhìn thống nhất về công việc do con người thực hiện. Một hệ thống có thể thêm một tác vụ vào một danh sách tác vụ do con người thực hiện. Sau khi tác vụ được thực hiện, hệ thống nhận được thông báo, có thể lấy kết quả thực hiện tác vụ và tiếp tục quá trình xử lý của nó.

HTM quản lý và điều phối các yêu cầu dịch vụ do người dùng cung cấp. HTM duy trì các danh sách các yêu cầu dịch vụ này luôn sẵn sàng đối với một người dùng định trước như là danh sách tác vụ để thi hành. Các danh sách tác vụ có thể khác nhau với những người dùng khác nhau, tùy thuộc vào vai trò của họ trong tổ chức. Ví dụ, danh sách tác vụ của một tác giả nội dung sẽ chứa các yêu cầu nội dung cần được tạo ra, trong khi danh sách tác vụ của người quản lý các tác giả nội dung sẽ chứa các yêu cầu chấp thuận nội dung đã được tạo ra bởi các thành viên trong ban nội dung. Nếu một người dùng chọn làm một tác vụ nào đó trong danh sách công việc của anh ta, thì anh ta cũng xác nhận đã nhận tác vụ đó, thực hiện hành động cần thiết phải làm và chuyển kết quả quay trở lại cho HTM.

Những người dùng sử dụng HTM để yêu cầu công việc được hoàn thành. Dịch vụ được yêu cầu có thể được cung cấp bởi một người khác hay bởi một dịch vụ tự động. Các tác vụ thường được thi hành trong thời gian dài, giống như qui trình nghiệp vụ. Yêu cầu dịch vụ là độc lập với bên cung cấp hiện tại của dịch vụ đó. Điều này cho phép thay đổi bên cung cấp dịch vụ mà không làm thay đổi bên yêu cầu dịch vụ. Các dịch vụ được con người làm thủ công có thể được thay thế bởi một dịch vụ tự động và ngược lại. Những người dùng có thể truy vấn trạng thái của công việc mà họ yêu cầu bằng cách sử dụng HTM. HTM cung cấp trạng thái của các tác vụ mà chúng đã bắt đầu (hoặc cho các tác vụ khác được con người thực hiện hoặc cho các tác vụ được các dịch vụ web tự động thực hiện).

Hình 2. Các kịch bản của Trình quản lý tác vụ do con người thực hiện
Các kịch bản của HTC

Tóm tắt

Việc áp dụng các khái niệm SOA cho các giao diện người dùng và giao phó các chức năng chung của vòng đời phần mềm cho một thùng chứa UI bằng cách sử dụng kiến trúc cổng web/portlet có thể tăng thêm thời gian phát huy giá trị (time-to-value) đối với nhà phát triển phần mềm. Tiêu chuẩn WSRP, chuyển giao các thành phần UI thông qua các dịch vụ web, mang lại các lợi ích cho cả bên cung cấp nội dung lẫn bên tiêu thụ nội dung, tạo điều kiện thực hiện một kiểu kết hợp ứng dụng mà không cần lập trình. Các khung công tác cổng web có thể kết hợp các portlet thành một giao diện người dùng theo phương thức động. Sự tham gia của những người dùng vào SOA có thể được mô hình hóa như là một dịch vụ web, với sự tương tác của con người được hẫu thuẫn bằng Trình quản lý tác vụ do con người thực hiện .

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=407158
ArticleTitle=Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 5: Các giao diện người dùng hướng-dịch vụ
publish-date=07102009