Đề tài Tìm hiểu công nghệ Agent và nghiên cứu ứng dụng Mobile Agent trong Workflow

gent ngoài những tính năng cơ bản giống với mobile code còn có khả năng mang theo mình dữ liệu, trạng thái thực thi, di chuyển trong mạng dưới sự kiểm soát của chính nó. Vì vậy Mobile Agent an toàn hơn mobile code khi sử dụng. 2.2.1.4 Tính chất của Mobile Agent Có khả năng di trú từ nơi này sang nơi khác Liên lạc được với nhau, nhân bản, nhập lại và tổng hợp tính toán Một số agent có khả năng cung cấp dịch vụ hoặc giao diện cho các ứng dụng kế thừa Có kích thước nhỏ Có khả năng xác định và dùng những tài nguyên trên máy tính đang chứa nó. 2.2.2 Các đặc tính của Mobile Agent Tính tự trị (autonomous): là khả năng tự kiểm soát bản thân của agent sau khi được giao việc mà không cần có sự can thiệp nào của người dùng hoặc các agent khác. Hai đặc tính hướng đích (goal-orient) và tính tự chủ (pro-activeness) thường được dùng để đánh giá mức độ tự trị của agent. Khả năng tự trị của agent chủ yếu được quyết định bởi tri thức trang bị cho agent. Tính di động (mobility): là khả năng di chuyển từ môi trường thi hành này sang môi trường thi hành khác của một agent. Khả năng di động của một agent được phân thành hai loại: 1) Di động mạnh (strong mobility) là khả năng mà hệ thống có thể di chuyển cả mã chương trình và trạng thái thi hành của agent đến một môi trường khác. 2) Di động yếu (weak mobility) là khả năng của hệ thống chỉ có thể di chuyển mã chương trình giữa các môi trường thi hành với nhau, mã nguồn có thể mang kèm theo một số dữ liệu khởi tạo nhưng trạng thái thi hành thì không thể di chuyển. Tính thích ứng (reactiveness): là khả năng của agent có thể thực thi trên những môi trường lạ và cảm nhận được sự thay đổi của môi trường. Khả năng cộng tác (collaboration): là khả năng liên lạc, phối hợp hoạt động của agent với các agent cùng môi trường hay với các loại đối tượng khác trong những môi trường khác. 2.2.3 Một số hệ thống Mobile Agent 2.2.3.1 Aglets Aglets được xây dựng và phát triển bởi D. B. Lange và IBM Tokyo Research Laboratory. Hiện nay, bộ Aglets Software Development Kit (ASDK) do IBM phát triển đã dừng lại ở phiên bản 1.1 Beta3 trên nền JDK1.1. Phiên bản mới nhất của ASDK là 2.0.2 do SourceForge phát triển trên nền JDK1.3. Aglets là một hệ thống Java Mobile Agent hỗ trợ các khái niệm thi hành tự trị và định tuyến động trên lộ trình của nó. Có thể xem aglets như là một khái quát hoá và mở rộng của applet và servlet. Aglet server là một chương trình cung cấp một môi trường thi hành và một máy ảo Java cho Aglet hoạt động. Ngoài ra, Aglet server cũng sử dụng một trình quản lý để tiếp nhận và kiểm soát aglets một cách an toàn. Aglet API là bộ thư viện bao gồm các hàm chuyên biệt dành cho việc phát triển agent. Nhờ vào Aglet API, khả năng nổi tiếng của Java là “viết một lần, thi hành bất cứ đâu”. Một khi aglets được tạo ra, nó sẽ chạy trên máy có hỗ trợ Aglet API mà không quan tâm đến nguồn gốc hệ điều hành và phần cứng bên dưới hay nguồn gốc cụ thể của Aglet API được cài trên máy đang chạy. Trong mô hình đối tượng Aglets, một mobile agent là một đối tượng di động có luồng kiểm soát riêng, làm việc theo sự kiện và liên lạc với các agent khác bằng cách truyền thông điệp. Aglets có một cơ chế định danh duy nhất và toàn cục dựa trên URL. Aglets hỗ trợ cơ chế di động yếu (weak mobility). Các aglets giao tiếp với nhau một cách đồng nhất và độc lập với vị trí lưu trú thông qua đối tượng proxy. Suốt chu kỳ sống, các aglets sẵn sàng bắt những sự kiện (clone, mobility, persistence) phát sinh trong môi trường để có phản ứng thích hợp. Agent có thể giao tiếp đồng bộ hoặc không đồng bộ thông qua các loại thông điệp: synchronous, one-way, hay future reply. Aglets sử dụng ATP (Agent Transfer Protocol) cho việc di chuyển và giao tiếp. Aglets sử dụng hai loạ mẫu thiết kế chính là chủ - tớ (Master - Slave) và hành trình (Itinerary) cho việc di chuyển của các agent. Aglets là một tronh những flatform được sử dụng nhiều nhất để phát triển các hệ thống mobile agent. Một số đề án thực hiện với Aglet có thể kể đến là TabiCan - chợ điện tử chuyển bán vé máy bay và tour du lịch trọn gói, Cps720 (Artificial Intelligence Topics with Agent) tại đại học Ryerson University, Mỹ, Acme - hệ thống hỗ trợ Sales Order Processing trong việc mua bán chứng khoán, của Đại học Loughborough, Anh. 2.2.3.2 Voyager Voyager là một môi trường thương mại hỗ trợ phát triển các ứng dụng agent được hãng Object Space phát triển từ giữa năm 1996. Voyager đã trải qua nhiều lần nâng cấp và thay đổi từ phiên bản 1.0 cho đến bây giờ là phiên bản 4.5. Tháng 03.2002 sản phẩm Voyager được nhượng lại cho Recursion Software, một công ty chuyên về các sản phẩm viết trên C++ và Java để đảm bảo cho việc phát triển Voyager sau này. Các phiên bản từ 1.0 đến 3.3 Voyager được phân phối cho các nhà phát triển như một freeware. Hiện tại Voyager đã có phiên bản 4.5 Evaluation hoàn toàn tương thích với JDK1.3, JDK1.2 và JDK1.1. Phiên bản này bao gồm 6 sản phẩm, trong đó sản phẩm chính yếu dùng cho các ứng dụng mobile agent là Voyager ORB Proffessional. Voyager sử dụng ngôn ngữ lập trình Java với cú pháp chuẩn để tạo dựng các đối tượng ở xa một cách rất dễ dàng, cho phép các đối tượng này trao đổi thông điệp với nhau, và di chuyển các đối tượng giữa các máy tính có hỗ trợ môi trường Voyager. Voyager hỗ trợ mạnh về tính di động với khả năng mang toàn bộ mã chương trình và dữ liệu di chuyển từ máy ảo Java này sang máy ảo Java khác nếu các máy ảo có hỗ trợ Voyager. Trạng thái hoạt động của agent cũng sẽ được bảo toàn và tiếp tục thực thi tại nơi agent đến. Một trong những đặc điểm nổi trội khác của Voyager là tính phổ quát. Các chương trình viết trong Voyager có thể trao đổi thông tin hai chiều với các chương trình viết bằng SOAP, CORBA, RMI và DCOM. Các dạng thông tin được trao đổi có thể là các lời gọi hàm từ xa, các dịch vụ đặt tên, dịch vụ thư mục. Voyager có thể được xem là một cửa ngõ, một cầu nối làm cho các chương trình theo chuẩn khác trở nên liên thông với nhau. Hơn nữa, tất cả các chương trình và đối tượng có thể tổ chức thành một không gian chung, nhờ vậy việc liên lạc sẽ trở thành một - nhiều một cách tự động. Phiên bản 4.5 của Voyager đã được bổ sung thêm các tính năng rất quan trọng hỗ trợ cho các chuẩn dịch vụ Web. SAOP và WSDL cũng đã được phát triển trong phiên bản này giúp các nhà phát triển có khả năng triển khai các ứng dụng truy cập tới các dịch vụ Web từ xa và các chương trình Voyager có thể truy cập nhau thông qua các dịch vụ Web. Thế mạnh thật sự củat Voyager nằm ở sự đơn giản và dễ dùng. Sự “trong suốt” hay cách mà Voyager che dấu các kỹ thuật lập trình phân tán phức tạp đã làm cho việc xây dựng các ứng dụng mobile agent trở nên dễ dàng hơn rất nhiều. Việc tích hợp công nghệ mới và các chuẩn mới vào cùng một sản phẩm tạo cho Voyager sự hấp dẫn riêng biệt. 2.2.3.3 Mole Là hệ thống mobile agent được xây dựng với ngôn ngữ Java tại đại học Stugart của Đức. Phiên bản đầu tiên 1.0 đã hoàn thành năm 1995, 1997 phiên bản 2 được hàon thành và phiên bản 3 hoàn tât nắm 1998 và đề án đã kết thúc với kết quả là môi trường ổn định để xây dựng ứng dụng thoe mô hình agent trên các hệ phân tán. Được xây dưng trên Java, Mole có khả năng thực thi trên tât cả các môi trường có hỗ trợ JDK1.1.x (JDK1.1.7 và JDK1.1.8), sử dụng giao thức TCP/IP trong quá trình giao tiếp. Mole hỗ trợ di chuyển yếu – weak migration. Để thực hiện giao tiếp giữa các giao tiếp Agent – Mole sử dụng các cơ chế truyền thông điệp, gọi hàm từ xa RPCs và cơ chế đặc trưng của Mole là session, badge. Ngôn ngữ giao tiếp giữa các agent được Mole hỗ trợ là KQML. Việc trao đổi dữ liệu giữa các agent được thực hiện theo giao thức TCP/IP. Mole cho phép đa tiểu trình / agent và quản lý tài nguyên và lập lịch các tiểu trình trong hệ thống qua bộ lập lịch trung tâm MCP. Khả năng bảo mật của Mole được đánh giá khá tốt trong các hệ thống agent. Mole tuân theo mô hình bảo mật SANDBOX của Java. Agent trong hệ thống Mole được chia thành 2 loại: user agent và system agent. User agent là những agent di đông được kích hoạt bởi người dùng và không thể truy cập trực tiếp tài nguyên hệ thống. Ngược lại, system agent (service agent) được khởi động bởi người quản trị - không có tính di động và được phép truy cập tài nguyên hệ thống. Môi trường Mole phù hợp cho phát triển những ứng dụng trong các lĩnh vực: truyền thông, ứng dụng thuộc hệ thống thông tin điện tử. Một số ưng dụng đựoc phát triển trên môi trường Mole: AIDA – Infrastructure for Mobile Agent, ASAP, ATOMAS, FESTIVAL (Mole office, Mole shopping), HAWK. Vói hệ thống mã nguồn mở của Mole, ta có thể tiến hành cải tiến, nâng cấp những chức năng hiện có, và bổ xung những chức năng mới như các chức năng về công cụ hỗ trợi lập trình agnet để Mole trở thành hệ thống agent hiện đại hỗ trợ tốt cho việc phát triển các ứng dụng dựa theo mô hình Agent. 2.2.3.4 Zeus Zeus là môi trường do British Telecommunication phát triển để hỗ trợ xây dựng các hệ thống đa agent. Ngoài các tính năng thông thường trong việc tạo lập và quản lý các agent, Zeus đặc biệt chú trọng việc hỗ trợ một phương pháp luận và một bộ công cụ mạnh để phát triển đa agent trong môi trường phân tán. Zeus định nghĩa một phương pháp luận để phân tích, thiết kế, triển khai hệ thống và còn kèm theo các công cụ cho phép người phát triển có thể bắt lỗi hệ thống cũng như phân tích sự thực hiện của mình. Hai giai đoạn phân tích và thiết kế được mô tả chi tiết trong [COL-99] nhưng chưa được hỗ trợ bởi các công cụ. Zeus Toolkit hỗ trợ hai giai đoạn cài đặt và bảo trì Zeus Toolkit qua các công cụ Zeus Agent Generator và Zeus Agent Visualiser. Zeus cung cấp nhiều Editor để định nghĩa agent và các thuộc tính của agent. Code Generator sẽ tự động phát sinh mã nguồn cho agent từ những thuộc tính đã đặc tả. Hai đặc tính quan trọng của các Zeus agent là tính tự trị và cộng tác. Bộ phận Planner trong mỗi agent sẽ hỗ trợ agent thể hiện tính tự trị. Khả năng thương lượng và cộng tác giữa các agent cũng được Zeus tích hợp vào trong Toolkit thông qua một thư viện các giao thức, cùng các chiến lược thương lượng và cộng tác. Do có mã nguồn mở, người dùng có thể thêm vào thư viện này các chiến lược riêng phù hợp với ứng dụng của mình. Các Zeus agent truyền thống theo point-to-point socket TCP/IP với mỗi message là một chuỗi các kí tự mã ASCII. Ngôn ngữ truyền thông Zeus sử dụng là FIPA ACL. Nhằm cung cấp khả năng “hiểu” lẫn nhau giữa các agent, Zeus cung cấp các công cụ cho việc định nghĩa các ontology-cơ sở khái niệm chung cho cộng đông agent. Các agent của Zeus được phân tán qua mạng và có thể thực hiện các tác vụ đồng thời. Chính vì thế, việc quản lý các agent cũng là một vấn đề mà môi trường đặt ra. Visualiser của Zeus cung cấp các công cụ để kiểm tra các quan hệ giao tiếp giữa các agent, trạng thái tác vụ những agent đang thực hiện và trạng thái bên trong của agent. Đồng thời, Zeus Statistic Tool cho phép người dùng so sánh các thống kê khác nhau về cộng đồng agent, chẳng hạn những loại thông điệp nào agent đã gửi và tỉ lệ là bao nhiêu, một cách trực quan dưới những dạng đồ thị khác nhau. Cũng nhằm quản lý agent, Zeus cung cấp những agent tiện ích như Agent Name Server hoạt động như một Yellow Page, Facilitator như một White Page, Visualiser và Database Proxy. Một hạn chế của Zeus là tuy được liệt kê vào một trong những môi trường Mobile Agent nhưng hiện hướng nghiên cứu về tính di động của Zeus mới ở bước đầu, chưa được cài đặt. Do đó mà tính bảo mật của Zeus cho các Agent hầu như không có. Điều này có thể sẽ được khắc phục trong các phiên bản sau. Zeus đã và đang được triển khai trong một số ứng dụng như Agent Based Workflow Management, PTA: Personal Travel Assistance, Personal Computer Manufacture, Agent-based Electronic Commerce, Network Management (VPNP), Home Shopping. 2.2.4 Ứng dụng của Mobile Agent 2.2.4.1 Giảm tải mạng Kỹ thuật mobile agent cho phép người dùng đóng gói cuộc trao đổi, gửi nó đến máy đích và thực hiện xử lý dữ liệu, trao đổi cục bộ tại đó. Như thế sẽ góp phần làm giảm những dòng dữ liệu thô trên mạng; và như thế, tải mạng sẽ giảm đáng kể. Phương châm thực hiện của kỹ thuật mobile agent là: mang xử lý đến nơi chúng chứa dữ liệu hơn là mang dữ liệu về chỗ xử lý. 2.2.4.2 Khắc phục sự trễ mạng Việc điều khiển các hệ thống với quy mô lớn thông qua mạng sẽ phải chấp nhận một sự trễ nhất định. Nhưng điều đó lại không được phép xảy ra trong các hệ thống thời gian thực như điều khiển robot, quy trình sản xuất Khi đó, giải pháp mobile agent tỏ ra hữu ích trong việc khắc phục độ trễ nhờ vào việc các agent có thể gửi đi từ một trung tâm điều khiển và hành động cục bộ, tự trị, trực tiếp thi hành các chỉ dẫn của người điều khiển. 2.2.4.3 Đóng gói các giao thức Khi dữ liệu được trao đổi trong hệ thống phân tán, việc truyền và nhận dữ liệu phải được mã hoá bởi các giao thức cần thiết. Các giao thức này được sở hữu bởi một máy trong hệ thống. Tuy nhiên, một khi các giao thức phải tiến hoá để phù hợp với những yêu cầu mới về sự bảo mật hoặc tính hiệu quả, chúng bắt đầu trở nên cồng kềnh, nặng nề và trở thành vấn đề nan giải. Riêng với giải pháp mobile agent, các agent có thể mang trên mình các giao thức thích hợp và di chuyển tới các máy ở xa để thiết lập kênh truyền nhận thông tin tương ứng. 2.2.4.4 Thi hành không đồng bộ và tự trị Thông thường, các thiết bị di động thường phụ thuộc vào các kết nối mạng đắt tiền nhưng rất yếu ớt. Vì thế, những tác vụ cần có kết nối liên tục giữa thiết bị di động và mạng cố định có thể sẽ không có tính kinh tế hoặc không khả thi về mặt kỹ thuật. Giải pháp mobile agent giải quyết vấn đề này bằng cách nhúng tác vụ cần thực hiện vào agent, rồi gửi lên mạng. Sau khi được gửi đi, agent trở nên độc lập thi hành không đồng bộ và có khả năng tự trị. Các thiết bị di động sau đó có thể kết nối trở lại để đón agent về. 2.2.4.5 Thích ứng nhanh Các agent có khả năng cảm nhận những thay đổi của môi trường thi hành và tác động trở lại những thay đổi ấy một cách tự động. 2.2.4.6 Khắc phục tình trạng không đồng nhất Việc xử lý tính toán trên mạng cơ bản là không đồng nhất vì sự đa dạng về phần cứng và phần mềm được sử dụng. Do mobile agent độc lập với máy tính (phần cứng và hệ điều hành) và tầng vận chuyển, chỉ phụ thuộc vào môi trường thi hành, nên chúng cung cấp một điều kiện tối ưu cho việc liên kết các hệ thống không liên quan gì lại với nhau. 2.2.4.7 Mạnh mẽ và có khả năng chế ngự lỗi cao Với khả năng phản ứng năng động với các sự kiện và thay đổi bất lợi, mobile agent giúp cho việc xây dựng hệ thống mạnh mẽ và chịu lỗi cao được dễ dàng hơn. 2.2.5 Các lĩnh vực nghiên cứu tiềm năng của mobile agent Hiện nay, theo các nghiên cứu về agent, chưa có một ứng dụng nào có thể được xem như là ứng dụng đặc trưng (kill application) dành cho công nghệ mobile agent. Với tất cả những kết quả đạt được hiện nay với mobile agent, người ta đều đạt được bằng công nghệ truyền thống. Tuy nhiên, trong một vài trường hợp, mobile agent có thể là giải pháp tối ưu. Mobile agent có thể được áp dụng trong nhiều lĩnh vực như: 2.2.5.1 Thương mại điện tử Các ứng dụng thương mại điện tử cho phép người dùng thực hiện các giao dịch trong kinh doanh trên mạng. Một giao dịch có thể bao gồm sự thương lượng với các thực thể ở xa và đòi hỏi truy cập nguồn thông tin liên tục thay đổi. Từ thực tế đó nảy sinh nhu cầu thay đổi hành vi của các thực thể để đạt được một nghi thức chung trong việc thương lượng. Hơn nữa, việc di chuyển các thành phần của một ứng dụng tiến gần đến nguồn thông tin thích hợp cho giao dịch cũng được quan tâm. Vì thế công nghệ mobile agent là một giải pháp rất hấp dẫn. 2.2.5.2 Thu thập thông tin phân tán Trong trường hợp có nhu cầu truy vấn phức tạp, chuyên biệt, liên quan tới nhiều nguồn dữ liệu phân tán, không đồng nhất, việc cử các mobile agent di chuyển đến các nguồn để khai thác tại chỗ và cuối cùng là quay về với những thông tin cần thiết sẽ cho phép giảm tải mạng và giải quyết tốt hơn bài toán tương thích. Mobile Agent for WWW Distr.DB Access (University of Cyprus), và Distributed Query Processing via Mobile Agents (University of Maryland), DBMS là những dự án thuộc loại ứng dụng này. 2.2.5.3 Theo dõi và thông báo tin cập nhật Ứng dụng cổ điển này làm nổi bật bản chất không đồng bộ của các mobile agent. Các agent có thể được gửi đi, đến nơi có nguồn thông tin và hoạt động theo dõi nguồn thông tin ngay cả khi người dùng ngắt kết nối. Sau đó, khi nguồn tin có sự thay đổi, agent sẽ quay về báo cho chủ nhân. Weather Alarm (University of Tromso) và JobFinder, Mole Office là một trong những đại diện của loại ứng dụng này. Các agent có thể được gửi đi để chờ một dạng thông tin nào đó xuất hiện, rồi sau đó báo cho người dùng hoặc tự nó có những hành động thích hợp với thông tin đó. 2.2.5.4 Giám sát và phổ biến thông tin Các mobile agent là một minh hoạ cho mô hình Internet push. Các agent có thể phổ biến tin tức và cập nhật phần mềm tự động cho các nhà sản xuất. Các agent mang các software components cũng như các thủ tục cần thiết đến các máy cá nhân của khách hàng và tự cập nhật phần mềm trên máy đó. Mô hình này giúp cho nhà sản xuất chủ động hơn trong việc phục vụ khách hàng để đảm bảo chất lượng dịch vụ của mình. Mặt khác, các ứng dụng thuộc loại này cũng tỏ ra hiệu quả đối với các mạng cục bộ hay các chương trình quản lý qui trình hoạt động, sản xuất để giúp người quản trị giám sát các hệ thống con. Có thể thể tìm thấy những loại ứng dụng này trong các dự án Banking Dartflow, Autopilot 2.2.5.5 Xử lý song song Vì các mobile agent tạo ra nhiều bản sao của nó trên mạng, một ứng dụng đầy tiềm năng của mobile agent là quản trị các tác vụ song song. Một ứng dụng đòi hỏi quá nhiều tài nguyên bộ xử lý có thể được phân bổ cho các mobile agent mang đi thực hiện trên nhiều máy tính khác nhau để tận dụng các tài nguyên rảnh rỗi và cân bằng tải. Hệ mobile agent không đồng nhất là một minh hoạ khai thác ưu điểm này của mô hình mobile agent. 2.2.5.6 Quản trị hệ thống mạng Đối với những hệ thống mạng lớn, việc chuẩn đoán lỗi, duy trì sự ổn định của hệ thống là công việc rất khó khăn. Việc ứng dụng mobile agent vào quản trị mạng sẽ giúp cho các công việc chuẩn đoán lỗi và duy trì từ xa sự ổn định của hệ thống được dễ dàng hơn. 2.2.5.7 Hỗ trợ các thiết bị di động Do đặc điểm tài nguyên hạn chế và không kết nối thường xuyên, việc xây dựng các ứng dụng dựa trên mobile agent với khả năng di chuyển đến các máy tính có cấu hình mạnh hơn để hoạt động (truy vấn cơ sở dữ liệu, tìm tin) rồi trả kết quả về sẽ là một giải pháp tốt cho người dùng các thiết bị di động. Trong số các đề án về loại ứng dụng này có thể kể đến Sony Magic Link PDA (xây dựng trên Telescript), TACOMA, Mobile Agent Middlerware tại Darmouth College và đề án Docking Laptop tại University of Maryland. 2.2.6 Nguyên lý hoạt động 2.2.6.1 Kỹ thuật Pull Code Áp dụng trong mô hình Client – Server, bắt đầu từ khi Client gửi yêu cầu đến Server, Server sẽ gửi code đến Client và code thực thi, cho ra kết quả ở Client. Code Request code Server Client Bước 1: Client gửi yêu cầu đến Server Code Request code Server Client Code Bước 2: Code được Server gửi đến Client Code Server Client Code Execute Bước 3: Code được thực thi ở Client Hình 2.3: Các bước của kỹ thuật Pull Code Ví dụ: các Java Applet thực thi theo kỹ thuật này Chú ý: Trong mô hình này, một bản sao của code được Server gửi tới Client để thực thi, Server sẽ vẫn giữ lại code. 2.2.6.2 Kỹ thuật Push Code Khi người dùng có yêu cầu, một máy (1 node) trong mạng sẽ gửi code tới máy khác trong mạng và thực thi ở đó. Quá trình này gồm 2 bước: Bước 1: Tự bản thân máy A gửi yêu cầu đến máy B mà không có yêu cầu từ phía B. Trong mô hình này, máy A chỉ đóng vai trò là máy có nối mạng với B chứ không cần A là Server. Bước 2: Sau khi gửi yêu cầu đến máy B, code được thực thi ở máy B. Code Node A Node B Code Remote exec Bước 1: Code được gửi tới máy Code Node A Node B Code Execute Bước 2: Code được thực thi ở máy B Hình 2.4: Các bước của kỹ thuật Push Code Chú ý: Ở A vẫn lưu trữ một bản sao của Code 2.2.6.3 Kỹ thuật Autonomous Code Code sẽ tự quyết định đi đâu và thực thi ở đâu. Node A Node B Code Execute Code migrate Bước 1: Code sau khi thực thi ở A sẽ tự động đóng gói và di chuyển tới B. Node A Node B Code Execute Bước 2: Code thực thi ở máy B, lúc này code không còn ở máy A nữa. Hình 2.4: Các bước của kỹ thuật Autonomous Code Ví dụ: mobile agent hoạt động theo phương pháp này Tự động di trú và đóng gói là điểm khác biệt của phương pháp này so với 2 phương pháp trên. Chương III ỨNG DỤNG MOBILE AGENT TRONG WORKFLOW Tổng quan về Workflow Các mô hình Workflow Phương pháp ứng dụng Mobile Agent trong Workflow Trong chương này sẽ trình bày một cách tổng quan về Workflow, các mô hình workflow, phương pháp ứng dụng Mobile Agent trong Workflow, các ích lợi mà phương pháp đó mang lại, các hướng nghiên cứu về ứng dụng Mobile Agent trong Workflow Công việc quản lý workflow xuất phát từ những công việc đòi hỏi tính tự động trong những văn phòng doanh nghiệp, trong đó mọi tài liệu phải được số hoá và lưu chuyển giữa các nhóm làm việc. Ngày nay công việc quản lý workflow thu hút rất nhiều sự quan tâm dựa vào khả năng của nó trong mô hình hoá, thực thi và quản lý tiến trình. Tiến trình công việc không phải là tiến trình trong quản lý kinh doanh mà còn là bất kỳ một tiến trình nào đó cần được điều khiển và quản lý. Nhưng điểm chính trong quản lý workflow là ứng dụng nó trong quản lý kinh doanh. Workflow giúp nhà quản trị lên kế hoạch, quản lý một cách tự động các nhiệm vụ, giám sát tiến trình công việc, đưa thông tin đến từng thành viên đúng lúc, có được cái nhìn tổng quan về tiến trình công việc. Có hai cách hiểu về workflow: Theo nghĩa rộng là một mô hình nghiệp vụ trong đó các công việc được phân công rõ ràng, thực hiện theo thứ tự sắp đặt sẵn. Khái niệm workflow theo cách hiểu này đã có từ lâu và được ứng dụng rộng rãi trong các ngành công nghiệp. Khái niệm về workflow trong khoa học máy tính ứng dụng vào tiến trình quản lý kinh doanh. 3.1 Khái niệm Là quá trình điện toán hoá hay tự động hoá một phần hoặc toàn bộ quá trình quản lý công việc Ý nghĩa của workflow khi này đơn giản chỉ là một luồng công việc. Hệ thống quản trị các luồng công việc: quản lý và thực thi các mô hình luồng công việc thông qua việc thực thi các công đoạn phần mềm. Gồm 2 thành tố: Bộ phận hỗ trợ đặc tả mô hình luồng công việc Bộ phận vận hành các mô hình đã đặc tả. 3.2 Ích lợi của áp dụng workflow Tiến trình quản lý công việc được vạch ra rõ ràng vì thế trách nhiệm và những mối quan hệ được định rõ. Dễ dàng tối ưu hoá các mục đích trong công việc Tiến trình công việc được chia nhỏ thành các module và các module này có thể được tổ chức lại theo mô hình workflow để thích ứng với tiến trình công việc chung, vì thế dễ dàng thích nghi với những thay đổi không đoán trước được trong yêu cầu và điều kiện kinh doanh. Workflow có thể theo dõi hàng ngày Workflow tích hợp với những ứng dụng hay những hệ thống khác vào tiến trình công việc Workflow phân định rõ trách nhiệm và công việc do nó tạo ra trong những phần công việc riêng. Theo dự đoán workflow sẽ tạo nên những phương pháp, kỹ thuật từ nhiều nguồn khác nhau trong khoa học máy tính cũng như quản trị tin học. Ví dụ kỹ thuật workflow liên quan đến quản trị cơ sở dữ liệu, tính toán client – server, giao diện 3.3 Các dạng workflow 3.3.1 Dạng đơn giản 3.3.1.1 Tuần tự (sequence) Mô tả: hoạt động trong luồng công việc được kích hoạt ngay sau khi một hành động khác kết thúc trong 1 tiến trình VD: hành vi gửi hoá đơn được thực hiện ngay sau khi gửi hàng hóa Cài đặt: dạng tuần tự được cài đặt để sử dụng để mô hình hoá các bước liên tiếp trong cùng 1 tiến trình của luồng công việc. Mô hình: Công việc A Công việc B Hình 3.1: Mô hình Workflow tuần tự Chú thích: công việc B được thực hiện ngay sau khi công việc A hoàn thành. 3.3.1.2 Phân luồng song song (Parallel Split) Mô tả: 1 điểm trong tiến trình luồng công việc là nơi 1 công việc được tách thành nhiều công việc con. Các công việc con có thể được tiến hành đồng thời cùng lúc (song song nhau) VD: Khi tiến trình nhận tiền kết thúc thì tiến trình xuất hàng và viết hoá đơn có thể được tiến hành cùng lúc. Mô hình: Công việc A Công việc B Công việc C Hình 3.2: Mô hình Workflow song song 3.3.1.3 Đồng bộ hoá Mô tả: một điểm trong luồng công việc là nơi các tiến trình hay các công việc con nhập lại làm một tiến trình hay công việc đơn. Trong mô hình này các luồng đi vào phải chờ nhau ở điểm đồng bộ hoá. VD: sau khi hành vi gửi hàng và viết hoá đơn được thực hiện, hành vi lưu trữ mới được kích hoạt Mô hình: Công việc A Công việc B Công việc C AND Hình 3.3: Mô hình Workflow đồng bộ hoá Chú thích: A, B phải được hoàn thành thì C mới được kích hoạt 3.3.1.4 Phép chọn loại trừ (Exclusive choice) Mô tả: tại một điểm trong luồng công việc sẽ diễn ra sự lựa chọn công việc nào sẽ được kích hoạt tiếp theo trong các loạt công việc kế tiếp. VD: Sau khi công đoạn kiểm thử phần mềm được tiến hành, dựa vào kết quả công việc sẽ quyết định tiếp theo là quá trình đóng gói hay lập trình. Mô hình: Công việc A Công việc B Công việc C Lựa chọn B hay C Hình 3.4: Mô hình Workflow chọn loại trừ Chú thích: chỉ có B,C được thực hiện, không thể tiến hành đồng thời cả 2. 3.3.1.5 Trộn đơn giản (simple merge) Mô tả: 1 điểm trong luồng công việc là nơi 2 hay nhiều nhánh gặp nhau, không có sự đồng bộ hoá giữa các nhánh. VD: Công việc lưu trữ được thực hiện sau khi công việc nhận hoá đơn hoặc gửi hoá đơn được thực hiện Công việc A Công việc B Công việc C Hình 3.5: Mô hình Workflow trộn đơn giản Chú thích: chỉ cần 1 trong 2 công việc A, B được hoàn thành thì C được kích hoạt. 3.3.2 Các dạng nâng cao 3.3.2.1 Chọn đa nhánh (multi-choice) Mô tả: 1 điểm trong tiến trình là nơi mà một trong nhiều nhánh sẽ được chọn theo một quyết định hoặc dựa trên dữ liệu của nghiệp vụ. Mô hình này khác với phép chọn loại trừ có thể chọn 1 hoặc nhiều nhánh được chọn ra và thực thi, tương tự như phép XOR VD: sau khi thực hiện hành vi đánh giá thiệt hại, hành vi liên hệ phòng cứu hoả hoặc liên hệ công ty bảo hiểm sẽ được thực hiện. Ít nhất 1 trong 2 hành vi được thực hiện, tuy nhiên có thể cả 2 hành vi sẽ được cùng thực hiện. Mô hình: Hình 3.6: Mô hình Workflow chọn đa nhánh 3.3.3.2 Trộn đồng bộ hoá Mô tả: 1 điểm trong tiến trình là nơi mà nhiều nhánh hội tụ lại thành một tiến trình duy nhất. Nếu có nhiều hơn 1 nhánh thực thi việc đồng bộ hoá (đợi nhau giữa các nhánh sẽ được thực hiện). Nếu chỉ có một nhánh thực thi các nhánh khác có thể hội tụ mà không cần đồng bộ hoá. Trong mô hình này nếu một nhánh đã được kích hoạt, thì nó không thể kích hoạt lẫn nữa trong khi đang đợi các nhánh khác hoàn tất. Mô hình này khác với mô hình đồng bộ hoá ở chỗ nó đồng bộ dựa trên số nhánh thực sự được kích hoạt lúc thực thi. Còn mô hình đồng bộ hoá bắt buộc các nhánh đi ra khỏi nút AND phân luồng (AND - Split) đều phải được thực hiện. Mô hình: Công việc A Công việc B Công việc C Hình 3.7: Mô hình Workflow trộn đồng bộ hoá VD: Tiếp tục với ví dụ trên, sau khi một hoặc cả 2 hành vi: liên hệ phòng chữa cháy hoặc liên hệ công ty bảo hiểm đã được hoàn tất (dựa trên việc nó có được thực thi hay không), hành vi trình báo cáo phải được thực hiện (chỉ một hành vi duy nhất). 3.3.2.3 Trộn đa nhánh Mô tả: 1 điểm trong tiến trình là nơi 2 hay nhiều nhánh hội tụ lại nhưng không được đồng bộ hoá. Nếu nhiều hơn 1 nhánh được kích hoạt, ngay lập tức hành vi sau điểm trộn sẽ bắt đầu đối với mỗi kích hoạt của mỗi nhánh vào. Mô hình này chính là thể hiện cơ chế trộn phục vụ cho mục đích dùng chung cho tất cả các thành phần trong qui trình. VD: Thỉnh thoảng 2 hay nhiều nhánh có cùng điểm kết thúc. Thay vì lặp lại tiến trình này cho mỗi nhánh (có thể phức tạp), ta dùng mô hình trộn đa nhánh. VD đơn giản là qui trình kiểm tra đơn xin việc và xử lý đơn xin việc cùng thực hiện song song và trước hành vi đóng trường hợp Mô hình: Công việc A Công việc B Công việc C Hình 3.8: Mô hình Workflow trộn đa nhánh 3.3.2.4 Discriminator Mô tả: Mô hình Discriminator là một điểm trong tiến trình làm nhiệm vụ đợi cho một trong các nhánh hoàn tất sau đó mới kích hoạt hành động tiếp theo. Từ đó trở đi nó vẫn cho phép các nhánh còn lại hoàn tất nhưng “phớt lờ” chúng. Trong trường hợp tất cả các nhánh đều kết thúc nó sẽ trở về trạng thái ban đầu để được kích hoạt lại. VD: Để làm tăng tốc độ phản hồi 2 yêu cầu tìm kiếm sẽ đựoc gửi đến 2 cơ sở dữ liệu trên Internet. Kết quả nào đến trước sẽ tiếp tục luồng công việc, cái còn lại không được quan tâm. Mô hình: Công việc A Công việc B Công việc C Hình 3.9: Mô hình Workflow Discriminator 3.3.2.5 Các vòng lặp tuỳ ý Mô tả: Một điểm trong tiến trình là nơi các hành vi được lặp đi lặp lại nhiều lần. Mô hình này thể hiện cho cơ chế lặp cấu trúc. Trong mô hình này việc lặp thường được quyết định bởi điều kiện hoặc lựa chọn. VD: Trong tiến trình xem xét sản phẩm: trong tiến trình này vòng lặp các hoạt động: Make, Read, Note, Approve là một vòng lặp cấu trúc. Mô hình: Hình 3.10: Mô hình Workflow các vòng lặp tuỳ ý 3.3.2.6 Kết thúc không tường minh Mô tả: Một tiến trình phải được kết thúc khi không còn gì để hoạt động tiếp. Nói cách khác không còn hành vi nào thực hiện trong workflow và không có hành vi nào được kích hoạt (tuy nhiên workflow không ở trong tình trạng deadlock). Mô hình này thường được thể hiện trong các ngôn ngữ mô hình hoá không bắt buộc điều kiện: “mọi tiến trình hoặc tiến trình con phải có nút qui định cuối cùng trong mô hình”. Mô hình này gọi là kết thúc không tường minh, bởi vì ràng buộc kết thúc của nó không bắt buộc tiến trình công việc phải được thực hiện đến điểm cuối cùng, mà chỉ dựa trên số công việc còn có khả năng được thực hiện. VD: Trong một công việc có nhiều hoạt động được thực hiện, giả sử đang thực hiện đến công việc kế cuối. Nếu ta áp dụng mô hình widthdraw thì trong tiến trình đang làm sẽ không còn hoạt động phải làm tiếp. Khi đó tiến trình công việc sẽ kết thúc mà không cần phải đợi thực hiện hoạt động cuối cùng (đã bị huỷ). 3.3.2.7 Đa thể hiện không đồng bộ Mô tả: Mô hình này mô tả một hành vi có thể có nhiều thể hiện. Nếu các hành vi có thể kích hoạt các thể hiện của nó, thì mỗi thể hiện của hành vi này sẽ tạo một tiến trình (một thể hiện luồng) riêng biệt được điều khiển độc lập với các thể hiện luồng khác phát sinh từ hành vi này. Hơn nữa, không cần thiết phải đồng bộ các thể hiện luồng này. VD: Một khách hàng đặt mua một quyển sách ở quầy điện tử amazon có thể mua các quyển sách khác ở cùng thời điểm. Rất nhiều hành vi (lập hoá đơn, cập nhạt thông tin khách hàng) được thực hiện khi khách hàng đặt hàng. Tuy nhiên cần phải có nhiều thể hiện để điều khiển các hoạt động thuộc về một cá nhân đặt hàng (cập nhật hàng dự trữ, giao hàng). Mô hình này có thể sử dụng trong trường hợp các hoạt động đặt hàng không cần phải đồng bộ. 3.3.2.8 Đa thể hiện với thông tin biết trước ở thời điểm thiết kế Mô tả: Trong một thể hiện của tiến trình, hành vi có thể được kích hoạt nhiều lần. Số các thể hiện của một hành vi trong một tiến trình cho trước biết được ở thời điểm thiết kế. khi các thể hiện hoàn tất thì các hành vi mới được bắt đầu. VD: việc cấp giấy phép đối với chất liệu nguy hiểm yêu cầu phải có 3 loại giấy phép khác nhau. Điều này có nghĩa là hoạt động cấp giấy phép được xác định trước số lần thực hiện là 3. 3.3.2.9 Đa thể hiện với thông tin biêt trước ở thời điểm thực thi Mô tả: Là trường hợp một hành vi được kích hoạt nhiều lần. Số các thể hiện của một hành vi có thể biến đổi, tuy nhiên có thể xác định ở thời điểm thực hiện, trước khi các thể hiện của các hành vi được tạo ra. Một khi tất cả các thể hiện đã được hoàn tất, thì các hành vi khác sẽ được bắt đầu. VD: Trong kiểm tra tiến độ thực hiện phần mềm, số lần kiểm tra phụ thuộc vào độ phức tạp của từng đề án cụ thể, nguồn nhân lực, mức độ rủi ro. Hoạt động kiểm tra hoàn toàn không thể xác định lúc thiết kế qui trình phần mềm, mà chỉ được quyết định việc kiểm tra bao nhiêu lần khi đã vào giai đoạn triển khai quy trình nghiệp vụ cho một phần mềm xác định. 3.3.2.10 Đa thể hiện không biết trước thông tin Mô tả: Dùng trong trường hợp hành vi được kích hoạt nhiều lần. Số thể hiện của hành vi cho trước không biết được trong thời điểm thiết kế và trong thời điểm thực thi - trước khi thể hiện được tạo ra. Các thể hiện của hành vi có thể được tạo ra một cách tuỳ ý. Một khi tất cả các thể hiện hoàn tất, hành vi kế tiếp mới được bắt đầu. Sự khác biệt giữa mô hình này với mô hình 3.3.1.4 là khi có một vài thể hiện được thực thi hoặc đã hoàn tất, những thể hiện mới vẫn có thể được tạo ra. VD: để xử lý một trường hợp bảo hiểm, có thể có hoặc không có bản tường trình của nhân chứng được xử lý. Số lượng bản tường trình là có thể thay đổi. Thậm chí khi đang xử lý các bản tường trình nhân chứng mới lại xuất hiện và số lượng bản tường trình lại tăng lên. Như vậy việc xử lý các bản tường trình là không thể biết trước được số lần thực hiện dù ở mức thiết kế (mô hình hoá) hay thực thi. Chỉ khi triển khai nghiệp vụ, bao giờ không còn công việc xử lý bản tường trình nào thì hoạt động xử lý tường trình mới kết thúc. 3.3.2.11 Chọn lựa bị trì hoãn Mô tả: Một điểm trong tiến trình là nơi một trong các nhánh được chọn. Không giống như tách – XOR, nhánh được chọn không thực hiện ngay (dựa trên dữ liệu hoặc quyết định) mà có nhiều nhánh tương tự được tạo ra. Tuy nhiên chỉ có một nhánh được thực thi. Khi môi trường thực hiện kích hoạt một nhánh, các nhánh khác sẽ bị huỷ. Việc chọn nhánh bị hoãn cho đến khi việc xử lý một trong các nhánh tương tự thực sự bắt đầu. Đó là thời điểm huỷ các nhánh còn lại. Mô hình này tường tự như Discriminator tuy nhiên có 2 điểm khác biệt: Discriminator dùng trong cơ chế trộn Discriminator vẫn cho phép thực hiện các công việc của những nhánh còn lại, nhưng việc thực hiện các nhánh này sẽ không dẫn đến việc kích hoạt các hoạt động kế tiếp. VD: các chuyển công tác cần được phê chuẩn trước khi thực hiện.. Có 2 cách để phê chuẩn một nhiệm vụ: hoặc là trưởng phòng phê chuẩn nhiệm vụ (hành vi A) hoặc là cả quản lý dự án (hành vi B) phê chuẩn nhiệm vụ. Hai hành vi này được thực thi duy nhất chỉ một, và việc lựa chọn giữa A và B là không tường minh, nghĩa là ở cùng thời điểm các hành vi A và B được gửi đến cả trưởng phòng và quản lý dự án. Tại thời điểm mà một trong hai hành vi được hoàn tất thì hành vi còn lại sẽ biến mất. 3.3.2.12 Đường vào song song Mô tả: Một tập các hành vi được thực hiện theo thứ tự tuỳ ý sau: đối với mỗi hành vi trong tập, việc thực thi được xác định vào thời điểm chạy, và không có hành vi nào được thực hiện cùng lúc (có nghĩa là không có hai hành vi nào cùng thực hiện trong cùng một thể hiện của workflow ở cùng thời điểm). VD: Vào cuối mỗi năm ngân hàng thực hiện 2 hoạt động cộng lãi tức và tính tiền vay trên mỗi tài khoản. Các công việc được thực hiện theo bất ký thứ tự nào. Nhưng vì chúng được thực hiện trên cùng tài khoản nên không được thực hiện đồng thời. 3.3.2.13 Cột mốc Mô tả: việc kích hoạt một hành vi dựa vào một trạng thái cụ thể nào đó, ví dụ như hành vi đựoc kích hoạt chỉ khi đi đến một cột mốc còn hoạt động. Ví dụ như xem xét các hành vi A, B và C. Hành vi A chỉ được kích hoạt khi hành vi B đã được thực thi còn C thì chưa, có nghĩa là A không được kích hoạt trước khi B thưc thi hoặc sau khi C thực thi, trạng thái giữa B và C được mô hình bằng điểm m, điểm này là cột mốc cho A VD:Trong 1 cty du lịch các vé máy bay, xe và phòng khách sạn có thể được đặt trước miễn là hoá đơn chưa in ra Khách hàng có thể huỷ đơn mua hàng trước 2 ngày khi có kế hoạch phân phối Khách hàng có thể yêu cầu các chứng nhận bay sáu tháng sau khi bay 3.3.2.14 Widthdraw Mô tả: Mô hình này mô tả việc một hoạt động đợi kích hoạt bị loại khỏi danh sách hoạt động. Ví dụ: Một bản thiết kế phần mềm được kiểm tra bởi nhiều nhóm kỹ sư vói các hoạt động kiểm tra khác nhau. Tuy nhiên, nhiều khi để có một kết quả đúng hạn thì chỉ cần một hoạt động kiểm tra. Khi đó, ở thời điểm có nhiều hoạt động kiểm tra đang sẵn sàng thực hiện, cho phép huỷ một số thể hiện kiểm tra hiện tại để kịp tiến độ thực hiện. 3.3.2.15 Huỷ trường hợp Mô tả: Một thể hiện của nhánh thực hiện bị loại bỏ hoàn toàn kể cả các hoạt động được thực hiện nhiều lần trên nhánh đó VD: Trong quá trình thuê người làm, các ứng viên tự rút đơn của mình thì các thể hiện cho việc xét ứng viên đó hiện tại sẽ bị huỷ. Các thể hiện hoạt động của việc xét ứng viên thường được đặt trên một nhánh luồng công việc. Khi đó tất cả các hoạt động ứng với nhánh xét cho ứng viên này được huỷ. 3.4 Kết hợp kỹ thuật Mobile Agent và Workflow 3.4.1 Ích lợi Ưu điểm của Mobile Agent: có thể hoạt động trong khi ngắt mạng, khả năng tự trị cao, tự xử lý các vấn đề xảy ra trên đường di chuyển, hoạt động tốt trong môi trường mạng bất đồng bộ, uyển chuyển linh hoạt Ưu điểm của Workflow: giúp người quản trị tiết kiệm thời gian và công sức quản lý qui trình nghiệp vụ, dễ dàng thay đổi cơ chế trên máy tính khi có sự thay đổi trên thực tế. Từ trước đến nay các phần mềm quản lý workflow vẫn hoạt động theo mô hình Client – Server. Khuyết điểm của hệ thống dạng này là: Khi có sự cố mạng xảy ra, mọi công việc sẽ bị ngưng lại Người quản trị hệ thống sẽ phải giải quyết tât cả các lỗi xảy ra như thay đổi đường đi hoặc huỷ công việc khi có một Client gặp sự cố. Khi thay thế mô hình Client – Server bằng Mobile Agent sẽ giải quyết được những vấn đề trên. Ngoài ra, hệ thống còn có một số các ưu điểm như: các chương trình agent sẽ tự đốc thúc người thực hiện công việc hoàn thành công việc đúng thời hạn, giảm lưu lượng đường truyền do không phải liên lạc với Server trong khi hoạt động 3.4.2 Phương pháp ứng dụng Mobile Agent trong Workflow Ứng dụng sẽ được xây dựng và điều khiển workflow nhằm trao đổi, thực thi các văn bản tài liệu trong một doanh nghiệp. Ứng dụng là một khâu khép kín từ chỉnh sửa workflow cho đến điều khiển thực thi Mobile Agent theo workflow đã thiết kế. Doanh nghiệp Phòng 1 Phòng 1 Phòng 1 Phòng 1 Tổ 1 Tổ 2 Role 1 Role 2 NV 1 NV 2 NV 3 Hình 3.11: Sơ đồ tổ chức của một doanh nghiệp Trong doanh nghiệp, để bộ máy vận hành liên tục, hiệu quả thì tồn tại nhu cầu lớn đòi hỏi cần có sự liên lạc, trao đổi giữa các phòng ban với nhau bằng những báo cáo, văn bản, tài liệu theo những quy trình cụ thể. Do các quá trình trao đổi này thường xuyên thay đổi theo những tình trạng và yêu cầu khác nhau của doanh nghiệp nên không thể xây dựng một phần mềm theo cách truyền thống. Do đó, sử dụng workflow là thích hợp hơn cả. Trong đó: - Đứng đầu doanh nghiệp là giám đốc - Đứng mỗi phòng ban là trưởng phòng - Đứng đầu mỗi tổ là tổ trưởng - Dưới tổ là các Role như tổ phó, nhân viên Giả sử, mỗi nhân viên có một máy tính nối trong mạng LAN có địa chỉ IP riêng. Các phòng ban khác nhau có thể thuộc những LAN khác nhau nhưng vẫn chung trong một doanh nghiệp. Khi đó mô hình Workflow sẽ được xây dựng theo đó có rất nhiều Node, mỗi Node tương ứng với những chức năng riêng. Phòng A Phòng B Trưởng phòng NV 1 NV 2 NV 3 đầu ra đầu vào Hình 3.12: Ví dụ về workflow + Sử dụng nhân công Để thực hiện chuỗi công việc trong doanh nghiệp mà không cần hệ thống máy tính hỗ trợ, thì cần một nhân viên chuyên đưa mẫu báo cáo đánh giá đến từng phòng ban, từng nhân viên, sau đó lại đi thu lại, tổng hợp kết quả để báo cáo. Khi có sai sót thì lại thực hiện lại công việc từ đầu. Ưu điểm của hệ thống dạng này là không tố chi phí trang bị máy móc trang thiết bị. Nhưng khuyết điểm là tốn thời gian, dễ nhầm lẫn, khó chỉnh sửa, quá trình cứng nhắc không linh hoạt + Sử dụng mô hình Client – Server Khi đó, Server sẽ lưu các mẫu báo cáo, khi cần thiết các Client sẽ lấy các mẫu đó về thực hiện, sau khi làm xong sẽ gửi lại cho Server. Sau đó các Client khác sẽ tiếp tục công việc Ưu điểm của mô hình này là công việc được quản lý một cách tập trung Nhược điểm là khi nhiều Client cùng truy nhập vào Server sẽ gây nghẽn mạng, khi thực hiện ở Client bị lỗi rồi gửi kết quả về Server thì Server cũng không phát hiện ra. + Khi kết hợp Mobile Agent vào trong Workflow Khi đó Mobile Agent trong hệ thống sẽ di trú trên mạng, gửi mẫu báo cáo đến các Node trên mạng. Khi công việc tại Node đó hoàn thành agent sẽ kiểm tra lỗi, nếu báo cáo không hoàn chỉnh sẽ yêu cầu Client thực hiện lại cho đến khi đạt yêu cầu. Các agent cứ tiếp tục như thế cho đến khi hoàn thành công việc và đưa kết quả về Server. Các công việc khi đó có thể được chia thành nhiều công việc con để thực hiện tuần tự hoặc song song, sau đó tổng hợp kết quả lại 3.5 Các hướng nghiên cứu khi tích hợp Mobile Agent và workflow 3.5.1 Agent Enhanced Workflow Với mô hình tích hợp này một engine workflow sẽ làm trung tâm điều khiển mọi hoạt động, còn các agent sẽ hoạt động như những service được cung cấp bởi hệ thống quản lý workflow. Workflow engine sẽ quản lý việc khởi tạo và huỷ các agent. Do đó, trong mô hình này các agent chủ yếu là các Interface agent, không cần phải là một agent thông minh. Thực tế, trong những phần mềm được thương mại hoá dựa trên mô hình này như IBM MQSeries Workflow, InConcert thì chức năng của agent chỉ như một phần mềm bình thường. 3.5.2 Agent Based Workflow Đây là một hệ thống phân tán với nhiều các agent. Các agent có công việc riêng, nó tôn tại hoàn toàn độc lập với nhau và tồn tại cho đến khi hoàn thành xong công việc của mình. Trong mô hình này tiến trình kinh doanh được thể hiện trên hệ thống mạng theo mô hình mobile agent. Các công việc sẽ được giao cho agent và các agent sẽ di trú trên mạng theo workflow đã định sẵn để hoàn thành công việc. Mô hình này rất thực tế, đòi hỏi các agent phải thông minh, có khả năng liên lạc và giao tiếp với các agent khác để hoàn thành công việc. Hiện nay vẫn chưa có phần mềm theo mô hình này được thương mại hoá. Tuy nhiên đã có một số nghiên cứu thử nghiệm như ADEPT (Jennings et al, 1996), FireFlow System (Yan, 1999) 3.6 Mô phỏng ứng dụng 3.6.1 Mô tả bài toán Giả sử đặt ra bài toán là xây dựng hệ thống thiết kế và điều khiển workflow nhằm mục đích trao đổi, thực thi các văn bản, tài liệu trong một tổ chức, đoàn thể hay doanh nghiệp. Hệ thống ở đây được xây dựng dựa trên hệ nền (flatform) Aglets của IBM. Nếu sau khi cài đặt thì có thể chạy được Aglets server có tên gọi Tahiti. Đây là chương trình giúp người dùng có thể quản lý server, tạo huỷ các agent... 3.6.2 Agent host Agent không tồn tại một mình mà nó phải dựa trên một phần mềm khác được gọi là host hay AgentOS để sống và hoạt động. Chính host sẽ tạo ra các agent từ đọan code đã có, thực thi agent, chuyển nó đến các host khác hay huỷ agent đi. Khi host bị huỷ thì agent đang hoạt động trên host cũng bị huỷ theo. 3.6.3 Cấu trúc hệ thống Gồm 3 thành phần chính: Workflow Document Designer Cho phép Administrator thiết kế các mẫu báo cáo dành cho user. Chương trình này được thiết kế dựa trên những đối tượng đồ hoạ có sẵn. Chương trình sẽ chuyển đổi các đối tượng đó và bố trí chúng thành các file văn bản và các file này sẽ được đính kèm vào từng nút trên workflow và được mang đi bởi mobile agent. Workflow Designer Chương trình cho phép Administrator thiết kế các Workflow. Chương trình được xây dựng trên nền graphic có sẵn cho phép người dùng chọn đối tượng và kéo qua phần thiết kế, đính kèm các văn bản cần thiết vào từng node trên đường đi. Các đối tượng có trong chương trình gồm: - Node: 1 node trong workflow đại diện cho một máy tính nối mạng. Khi chọn node người dùng phải nhập đầy đủ thông tin cho node như IP, tên... - Đường đi: thể hiện bằng mũi tên, thể hiện công việc đi từ node này sang node khác. - Trạm trung chuyển: có nhiều loại trạm trung chuyển thể hiện qua các dạng khác nhau của workflow Agent Manager Hoạt động trên nền Aglets của IBM, làm nhiệm vụ tạo mới và quản lý các agent. Người dùng cần đưa vào câc thông tin như: workflow cần thực hiện, thời gian sống của agent. Hệ thống sẽ sinh ra các loại agent sau: Wfagent (Workflow agent): agent mang các mẫu văn bản đến các node (người dùng) trong workflow đã thiết kế. Wfagent sẽ chuyển thông tin ở dạng mã hoá sang đối tượng đồ hoạ giúp người dùng dễ thao tác. Sau khi người dùng đã cung cấp đầy đủ các thông tin cho agent, agent sẽ chuyển các đối tượng đồ hoạ về dạng mã hoá, tổng hợp lại và đi đến các node tiếp theo trong workflow đã đinh và gửi trả kết quả về cho Agent Manager. Uagent (Update Agent): khi có thay đổi các thông tin từ Agent Manager, nó sẽ gửi uagent mang các thông tin mới cần sửa đổi đến các agent đang chạy trên hệ thống và cập nhật thông tin mới hơn hoặc gặp agent đã tiếp xúc với uagent mới hơn nó sẽ tự huỷ. Nagent (Notifier Agent): cứ mỗi khi workflow agent tiếp xúc với một người dùng mới, nó sẽ gửi thông tin cập nhật về cho Agent Manager thông qua nagent. wfagent nagent wfagent wfagent nagent wfagent nagent Người dùng A Người dùng B Agent host Agent host Agent host Agent Manager CSDL WF CSDL DOC CSDL LT Workflow designer Workflow document designer Hình 3.13: Kiến trúc hệ thống Đường đi của Mobile Agent Truy cập có sở dữ liệu Wfagent Workflow Agent Uagent Updater Agent Nagent Notifier Agent CSDL WF Lưu trữ các Workflow thiết kế từ trước CSDL DOC Lưu trữ các mẫu báo cáo được thiết kế từ trước CSDL LT Lưu các mẫu báo cáo được wfagent mang về Mỗi người dùng cài sẵn Agent host là Server Tahiti. Chương trình này giúp cho các agent đến các máy có thể hoạt động được. 3.6.4 Quá trình hoạt động Sử dụng chương trình Form Designer thiết kế ra các mẫu báo cáo. Chương trình Workflow Designer sử dụng các mẫu báo cáo này để thiết kế ra các workflow. Agent Manager sau khi load workflow sẽ được tạo ra wfagent, wfagent dựa trên Workflow được cung cấp sẵn sẽ lần lượt tạo ra các bản sao để đi đến các máy và yêu cầu các user thực hiện đúng mẫu báo cáo ứng với từng máy theo Workflow đã định sẵn. Khi đến một máy, wfagent sẽ tạo ra một nagent gửi về để báo cho Agent Manager biết được nó đang ở máy nào. Khi có lỗi xảy ra hoặc khi có sự cập nhật về Workflow, Agent Manager sẽ tạo ra một uagent mang thông tin cần cập nhật đến với từng wfagent đang chạy. Wfagent sau khi hoàn thành nhiệm vụ sẽ trở về Agent Manager mang theo các mẫu báo cáo được hoàn thành và lưu vào thư mục đã định sẵn. 3.6.5 Các đối tượng sử dụng - Administrator Mở chương trình thiết kế workflow, tạo workflow mới. Mở chương trình tạo mobile agent, chọn các workflow cần thực hiện và thi hành Trường hợp có lỗi thì xác định xem node gây lỗi có liên lạc được không. Nếu được thì chạy lại workflow từ node đó, nếu không thì thiết kế lại workflow từ node gây lỗi và chạy lại. - User Nhận mobile agent, mở văn bản, điền các thông tin. Trong trường hợp nếu user điền sai thông tin, mobile agent sẽ báo lỗi để user sửa lại. Nếu user chậm thực hiện mobile agent sẽ liên tục nhắc nhở. Sau khi điền xong thông tin, user sẽ lưu văn bản lại, báo đã kết thúc nhiệm vụ. Mobile agent sẽ kiểm tra văn bản đã hoàn thành đúng chưa, nếu chưa sẽ đòi hỏi điền thêm thông tin. Sau đó mobile agent đóng gói và di trú đến node khác. 3.6.6 Các lỗi có thể xảy ra Khi một Workflow đi vào hoạt động sẽ có một số lỗi phát sinh - Thay đổi toàn bộ chuỗi công việc: Khi đó workflow cũ sẽ không còn giá trị, các agent hoạt động trên workflow đó sẽ được lệnh tự huỷ mà không cần thu hồi - Thay đổi một phần công việc: Do mỗi khi thi hành nhiệm vụ ở một node, agent sẽ gửi thông báo về cho Agent Manager là đã hoàn thành nhiệm vụ ở node đó. Do đó, nếu phần việc thay đổi nằm ở node mà agent chưa tới thì chấp nhận được. Khi đó một Uagent mới sẽ mang thông tin cập nhật đến agent đang hoạt động và cập nhật lại đường đi mới cho các agent. Nếu phần thay đổi liên quan đến những node đã có agent chạy qua thì sự thay đổi đó không được chấp nhận. Nếu admin thực sự muốn thay đổi thì huỷ workflow cũ đi và sẽ thiết kế lại workflow mới. KẾT LUẬN VÀ ĐÁNH GIÁ KẾT LUẬN Xét trên góc độ lý thuyết công nghệ agent cũng như mobile agent có nhiều ưu điểm rất hứa hẹn cho việc phát triển một thế hệ các hệ thống ứng dụng mới. Tuy nhiên, các nghiên cứu chỉ mới dừng lại ở mức độ lý thuyết, nghiên cứu về mobile agent thì chỉ tập trung vào phát triển hệ thống có tính di động và những vấn đề của môi trường này như tính an toàn, cơ chế tự di chuyển... Việc vận dụng mô hình mobile agent vào thực tế gần như vẫn dừng lại ở mức độ thử nghiệm mà chưa có đựơc sản phẩm thương mại hoàn chỉnh. Cũng tương tư như thế việc ứng dụng workflow trên công nghệ mobile agent cũng chưa được chú ý nhiều. ĐÁNH GIÁ - Báo cáo lý thuyết: Đã nêu lên được tương đối đầy đủ cơ sở nền tảng lý thuyết. Nêu lên được khái niệm, ứng dụng của công nghệ agent. Nêu lên được khái niệm, tính năng và lợi ích của mobile agent. Đưa ra các môi trường có thể áp dụng công nghệ mobile agent như: thương mại điện tử, thu thập thông tin phân tán... Nêu lên được khái niệm workflow, các dạng workflow, khả năng cũng như nhu cầu đòi hỏi sự kết hợp giữa workflow và công nghệ mobile agent - Xây dựng ứng dụng mô phỏng: Đã xây dựng một mô phỏng ứng dụng cụ thể dựa trên những cơ sở lý thuyết thu lượm được - Hạn chế: Về mặt lý thuyết do agent, mobile agent còn tương đối mới mẻ nhất là đối với sinh viên, cộng thêm với việc khó khăn trong thu thập tài liệu Do đó, lý thuyết trình bày chưa được sâu và còn một số thiếu Hiện nay việc xây dựng ứng dụng mới chỉ dừng lại ở mức độ mô phỏng - Hướng nghiên cứu tiếp tục: Tiếp tục nghiên cứu sâu hơn về cơ sở lý thuyết, xây dựng được một ứng dụng cụ thể có thể triển khai được trên thực tế. TÀI LIỆU THAM KHẢO 1) Tác tử - Công nghệ phần mềm hướng tác tử - Khoa Công nghệ Thông tin - Trường ĐH Bách khoa Hà Nội 2) Tổng quan về Mobile Agents - Bộ môn Công nghệ Phần mềm – Khoa Công nghệ Thông tin - Trường ĐH Khoa học Tự nhiên Tp.HCM 3) Workflow Management – i3 Network System’s Wiki 4)Agents-based Network Management System– Huawen Luo– the University of British Columbia 5) www.wikipedia.org 6) Một số tài liệu khác trên Internet