Luận văn Nghiên cứu ứng dụng kiến trúc SOA trong mô hình ứng dụng doanh nghiệp

ảng khác nhau, sử dụng nhiều ngôn ngữ lập trình khác nhau và thường có nhiều tính năng lặp lại giữa chúng. Một hệ thống SOA cho phép các công ty tránh tình trạng lặp dư thừa, tạo ra những đơn thể dịch vụ chia sẻ giữa các ứng dụng. Trong một hệ thống SOA, chỉ cần thay đổi duy nhất một phiên bản của dịch vụ cần được thay đổi và chỉ cần kiểm thử một lần, sử dụng những kỹ năng tương ứng với những kỹ năng đã dùng để phát triển dịch vụ. Lợi ích rõ ràng nhất là giảm chi phí bảo trì phần mềm. Ngoài ra điều này còn giúp doanh nghiệp chịu trách nhiệm nhiều hơn với những thay đổi về về mặt nghiệp vụ và cho phép doanh nghiệp cập nh ật những tính năng của nó nhanh hơn. Bằng cách phân rã một ứng dụng thành những đơn thể dịch vụ nghiệp vụ, sau đó cho những dịch vụ này liên kết lại với nhau, các hệ thống bây giờ có thể sử dụng lại được các thành phần có sẵn, giảm chi phí phát triển từng phần độc lập cho mỗi tính năng mới chưa có. Thay vì phải “ thay đổi” , với SOA ta chỉ cần tạo ra các “ cầu nối” liên hệ giữa những hệ thống và ứng dụng khác nhau, thay vì chỉnh sửa hoặc xây dựng lại từ đầu. Bởi vì có đa phần các dịch vụ mới sử dụng lại những dịch vụ sẵn có nên chi phí phát triển các thành phần mới được giảm đến mức tối thiểu. Nghĩa là :  Các công ty có thể triển khai những tiến trình xử lý mới nhanh hơn rất nhiều.  Chi phí dành cho phát triển và kiểm thử giảm đáng kể  Giảm rủi ro khi dịch vụ tạm ngưng hoạt động Lợi ích cuối cùng của việc tái sử dụng thường khó nhận thấy, đó là khi sử dụng những thành phần có sẵn, mỗi khi có lỗi xảy ra ta đều có thể giới hạn vào khu 32 vực có những thành phần đang được phát triển. Nhờ đó rủi ro về lỗi phần mềm giảm đi và tăng chất lượng dịch vụ. Giảm chi phí phát triển và kiểm thử, và tránh công việc trùng lặp là một trong những lợi ích mà SOA mang lại. Nhưng quan trọng vẫn là lợi ích từ việc tăng khả năng kinh doanh. Nếu những nhân tố này được đánh giá đúng mức thì lợi ích mang lại là rất đáng kể. 1.2.4.2. Giải pháp ứng dụng tổng hợp cho doanh nghiệp Cũng với ví dụ trên, SOA mang đến khả năng tổng hợp một lớp các ứng dụng mới bằng cách kết hợp chức năng từ những hệ thống có sẵn, cung cấp cho người cuối những chức năng liên kết. Ở đây một số tiến trình cũ có thể được kết hợp với nhau bên trong một cổng thông tin (portal) giúp cho người dùng cuối chỉ cần truy cập một lần mà vẫn có thông tin về hàng loạt sản phẩm của doanh nghiệp. Loại kết hợp này có thể khó khăn nếu không sử dụng SOA vì nó đòi hỏi việc tích hợp phức tạp, nỗ lực lập trình và kiểm thử. Nhưng với SOA , một ứng dụng tổng hợp có thể được tổng hợp dễ dàng, bất kể sự khác nhau về địa lý hoặc công nghệ phát triển các dịch vụ đó. Điều này cho phép doanh nghiệp phản ứng nhanh theo yêu cầu, giảm chi phí đến mức tối thiểu và tăng sức mạnh thoả mãn yêu cầu của người dùng cuối hiệu quả hơn. 1.2.4.3. Tính chất kết nối lỏng giúp tăng tính linh hoạt và khả năng triển khai cài đặt Lợi ích kế tiếp đến từ tính kết nối lỏng của SOA, trong đó phía triệu gọi dịch vụ không cần quan tâm đến địa chỉ hoặc công nghệ nền tảng của service. Nó mang đến khả năng linh hoạt cao và nhiều lợi ích khác. Trong một hệ thống SOA ta triệu gọi dịch vụ thông qua các interface theo một dạng thức chuẩn nên giúp lập trình viên tránh được việc phải lặp lại công việc tạo mới các service có khả năng hiểu tất cả những công nghệ được sử dụng bởi từng dịch vụ trong hệ thống. 33 Thứ hai, trong trường hợp cần kết nối với các đối tác thương mại thì những dịch vụ có tính kết nối lỏng, những interface chuẩn càng đem lại nhiều lợi ích hơn. Với một hệ thống SOA, thật dễ dàng khi cung cấp một loạt những dịch vụ ra bên ngoài cho một đối tác nào đó sử dụng. Nhờ tính độc lập địa chỉ và công nghệ của SOA, đối tác kia không cần quan tâm đến dịch vụ được cài đặt như thế nào, và nhờ các dịch vụ đã theo chuẩn giao tiếp nên đối tác đó chỉ cần một lượng thông tin nhỏ vừa đủ để sử dụng dịch vụ. Tương tự cho điều ngược lại, nếu đối tác đã xây dựng một hệ thống SOA thì việc đem sử dụng chức năng một số dịch vụ của họ vào sử dụng bên trong hệ thống của mình cũng trở nên dễ dàng và nhanh chóng. Đặc tính này của SOA hứa hẹn tăng hiệu suất và tự động hoá. Cuối cùng một lợi ích mà tính kết nối lỏng mang lại là tăng khả năng triển khai. Như đã phân tích ở trên, những thành phần có tính kết nối lỏng có thể được triệu gọi mà không cần biết chúng được cài đặt như thế nào mà chỉ cần biết cách thức triệu gọi chúng thông qua một interface chuẩn. Vì vậy chỉ cần bọc những thành phần sử dụng interface ứng dụng thành dạng dịch vụ, ta đã có một đơn thể thành phần được sử dụng trong hệ thống SOA như những dịch vụ bình thường khác. 1.2.4.4. Thích ứng với những thay đổi trong tương lai Các phương pháp tiếp cận truyền thống trong quy trình phát triển phần mềm có thể mô tả ngắn gọn là người dùng mô tả họ cần gì – công ty phát triển phần mềm – triển khai hệ thống theo yêu cầu. Quy trình này đôi khi gặp khó khăn khi gặp những tình huống thay đổi không định trước. Với SOA, công ty phát triển phần mềm có thể tạo nên những quy trình nghiệp vụ uyển chuyển, phức tạp biến đổi tùy “ theo yêu cầu” và theo “ thời gian thực“. 1.2.4.5. Hỗ trợ đa thiết bị và đa nền tảng. SOA cung cấp một tầng giao tiếp trừu tượng từ các nền tảng bên dưới. Điều này cho phép hỗ trợ nhiều loại thiết bị đầu cuối khác nhau bao gồm cả những trình duyệt và thiết bị di động như điện thoại di động, PDA và các thiết bị chuyên dụng 34 khác sử dụng cùng một chức năng mà vẫn có thông tin trả về tùy theo dạng thiết bị. Tính độc lập công nghệ này giúp cho các công ty tiết kiệm chi phí rất nhiều nhất là khi phải xử lý với vô số công nghệ hiện đang được sử dụng. 1.2.4.6. Tăng khả năng mở rộng và khả năng sẵn sàng cung cấp. Nhờ tính độc lập địa chỉ của SOA, ta có thể tăng khả năng mở rộng bằng cách thêm nhiều thể hiện (instance) của một service. Công nghệ chia tải (load-balancing) sẽ tự động tìm và định tuyến yêu cầu đến thể hiện service thích hợp. Tương tự, SOA có thể chuyển tiếp nội dung yêu cầu đến một thể hiện khác khi cần, nhờ đó tăng khả năng sẵn sàng phục vụ. 35 CHƯƠNG 2: MÔ HÌNH HÓA QUY TRÌNH NGHIỆP VỤ TRONG HTTT DOANH NGHIỆP THEO KIẾN TRÚC SOA 2.1. Quy trình nghiệp vụ 2.1.1. Khái niệm quy trình nghiệp vụ Quy trình nghiệp vụ là một quy trình xử lý các công việc của một cơ quan hay một tổ chức nào đó. Quy trình nghiệp vụ bao gồm các hoạt động, các công việc bên trong mỗi tổ chức, cơ quan cụ thể. Ví dụ : Quy trình học sinh hoàn thành một môn học trong một học kỳ như sau :  Học sinh phải đi học đầy đủ. Nếu học sinh nghỉ học quá ba buổi thì sẽ không được thi kết thúc môn học và sẽ không hoàn thành môn học đó. Ngược lại nếu học sinh đi học đầy đủ thì học sinh phải thi giữa học kỳ môn học đó.  Nếu như điểm thi giữa học kỳ lớn hơn hoặc bằng 5 thì học sinh đó sẽ được thi cuối kỳ. Ngược lại, nếu như điểm thi giữa kỳ của học sinh đó nhỏ hơn 5 thì học sinh đó không được thi cuối kỳ và sẽ không hoàn thành môn học đó. Khi học sinh thi cuối kỳ xong, nếu điểm tổng kết của học sinh đó lớn hơn hoặc bằng 5 thì học sinh đó hoàn thành môn học. Ngược lại nếu điểm tổng kết của học sinh nhỏ hơn 5 thì sẽ không hoàn thành môn học đó 36 Hình 2.1 Quy trình học sinh hoàn thành môn học 2.1.2. Mô hình hóa quy trình nghiệp vụ Mô hình hóa nghiệp vụ là một kỹ thuật để mô tả quy trình nghiệp vụ của tổ một chức, một đơn vị. Mô hình nghiệp vụ xác định các quy trình nghiệp vụ nào được hỗ trợ bởi hệ thống. Song song với quá trình khảo sát tìm hiểu về vấn đề hệ thống thì cách tiếp cận nghiệp vụ là phương pháp có hệ thống nhất để nắm bắt các yêu cầu của các ứng dụng nghiệp vụ. Khi những hệ thống ngày càng phức tạp, việc mô hình hóa trực quan và cách vận dụng các kỹ thuật mô hình hóa ngày càng trở nên quan trọng hơn. Có nhiều nhân tố bổ sung cho sự thành công của một dự án, nhưng việc có một tiêu chuẩn ngôn ngữ nghiệp vụ là tạo ra các mô hình nhằm để dễ hiểu hơn và để có thể thiết kế những chương trình máy tình bằng cách thông qua hiện tượng thế giới thực như người, nguyên liệu làm việc và cách thức chúng thực hiện những nhiệm vụ của họ. Như vậy, việc mô hình hóa nghiệp vụ là lập mô hình những tổ chức thế giới thực. Phạm vi ảnh hưởng của việc mô hình hóa nghiệp vụ có thể biến đổi tùy theo nhu cầu và hệ thống nghiệp vụ cụ thể. Có thể đơn giản chúng ta chỉ nhằm vào việc tăng năng suất bằng cách cải tiến những quy trình đã tồn tại, hoặc là đang tạo ra 37 những sự cải tiến có ảnh hưởng lớn bằng cách thay đổi đáng kể những quy trình nghiệp vụ dựa trên sựa phân tích kỹ lưỡng các mục tiêu và các khách hàng của tổ chức. Cho dù là bất kỳ trường hợp nào, những hệ thống thông tin hỗ trợ cho hệ thống nghiệp vụ đều bị ảnh hưởng. Trong quá trình phát triển hệ thống phần mềm một vấn đề tồn tại rất lớn là đội ngũ phát triển hệ thống thường hiếm khi có một kiến thức hiểu biết đầy đủ về nghiệp vụ của tổ chức mà chính họ là người xây dựng hệ thống phần mềm thực hiện trong môi trường nghiệp vụ đó. Trong khi đó, người sử dụng phần mềm chính là các đối tượng xử lý nghiệp vụ thường không am hiểu tường tận về các công nghệ và các kỹ thuật của phần mềm nhằm chọn lựa và áp dụng nó một cách phù hợp và hiệu quả với nhu cầu của mình. Khoảng cách này là một vấn đề rất lớn dẫn đến sự thất bại của quá trình tin học hóa hệ thống và thực tế đã có rất nhiều dự án đã thất bại và làm thiệt hại rất lớn về thời gian, công sức của những người tin học hóa. Do đó, làm thế nào để các đối tượng này có thể hiểu và thống nhất được tốt nhất về cách giải quyết hệ thống trong quá trình tin học hóa. Những mô hình nghiệp vụ đưa ra các cách thức diễn tả những quy trình nghiệp vụ dưới dạng những đối tượng và hành động tương tác giữa chúng. Nếu không mô hình hóa nghiệp vụ thì ta có thể gặp nhiều rủi ro do những người phát triển không có thông tin đầy đủ về cách thức mà nghiệp vụ được thực hiện. Họ chỉ làm những gì mà họ hiểu rõ, như là thiết kế và tạo ra phần mềm, mà không quan tâm đến những quy trình nghiệp vụ. Điều này gây ra một sự lãng phí do trước đó đã xây dựng các quy trình nghiệp vụ tốn kém. Rủi ro do những hệ thống được xây dựng không hỗ trợ các nhu cầu thực sự của tổ chức cũng có thể xảy ra rất cao. Việc hiểu rõ những quy trình nghiệp vụ là rất quan trọng để có thể xây dựng những hệ thống đúng và hài lòng khách hàng. Việc mô hình hóa nghiệp vụ có thể có mục tiêu chính là sự phát triển hệ thống, trong đó công việc thực sự là xác định đúng các yêu cầu hệ thống. 38 Cơ sở để xây dựng hệ thống là sử dụng những vai trò và trách nhiệm của con người cũng như định nghĩa những gì được xử lý bởi nghiệp vụ. Điều này được thể hiện trong một mô hình đối tượng nghiệp vụ, mà qua đó có thể thấy rõ các vai trò đối tượng sẽ được làm rõ. Với sự xuất hiện của e-commerce (thương mại điện tử) mô hình hóa nghiệp vụ cũng trở nên quan trọng hơn. Các ứng dụng e-commerce được xây dựng để tự động hóa những quy trình nghiệp vụ. Một khi xác định được các mô hình nghiệp vụ, chúng ta cần phải thiết lập những mối quan hệ giữa các ca sử dụng hệ thống và những mô hình nghiệp vụ. Điều này sẽ cho phép các nhà phân tích được thông báo khi có những thay đổi ở trong hệ thống. Tóm lại, mục đích của mô hình hóa nghiệp vụ là :  Hiểu được cấu trúc và các hoạt động của tổ chức được triển khai hệ thống.  Hiểu được các vấn đề hiện tại trong tổ chức và xác định các vấn đề cần cải tiến.  Để đảm bảo rằng các khách hàng, người dùng cuối, và các nhà phát triển có sự hiểu biết chung về tổ chức đang thực hiện tin học hóa.  Thiết lập các yêu cầu hệ thống nhằm hỗ trợ tổ chức. Để đạt được những mục đích trên, luồng công việc mô hình hóa nghiệp vụ mô tả một bức tranh tổng quát về tổ chức, từ đó xác định các quy trình (process), các vai trò (role), và các trách nhiệm của tổ chức này trong mô hình ca sử dụng nghiệp vụ (business use-case-model) và mô hình đối tượng nghiệp vụ (business object model). 39 2.1.3. Một số công cụ hỗ trợ việc mô hình hóa quy trình nghiệp vụ theo kiến trúc SOA Hiện nay, có rất nhiều các công cụ hỗ trợ cho việc mô hình hóa do tính cần thiết của quá trình mô hình hóa các quy trình nghiệp vụ trong các HTTT doanh nghiệp. Tuy nhiên, chính vì có nhiều công cụ hỗ trợ việc mô hình hóa quy trình nghiệp vụ mà các công cụ này lại sử dụng những kí pháp riêng để mô tả nghiệp vụ nên người sử dụng các công cụ khác nhau đôi khi khó hiểu khi đọc các bản mô hình hóa khác nhau. 2.1.3.1. UML Đầu tiên, chúng ta phải kể đến biểu đồ hoạt động của UML. UML cung cấp các loại biểu đồ khác nhau như biểu đồ ca sử dụng, biểu đồ tuần tự v..v... Sự ra đời từ khá sớm đã khiến mọi người quan tâm và sử dụng UML làm ngôn ngữ mô hình hóa cho các hệ thống thông tin. Trong UML, để mô hình hóa các quy trình nghiệp vụ người ta thường sử dụng biểu đồ hoạt động (Activiti diagram). Tuy nhiên, biểu đồ hoạt động của UML lại không hỗ trợ nhiều các trong các mô hình nghiệp vụ phức tạp và đòi hỏi tính thực tế cao, chính vì thế mà đã có nhiều công cụ hỗ trợ việc mô hình hóa nghiệp vụ đã ra đời. 2.1.3.2. BPEL BPEL ( viết tắt của Web Services Business Process Execution Language - BPEL4WS) là ngôn ngữ thực thi quy trình nghiệp vụ, hỗ trợ các dịch vụ tương tác với nhau nhằm thực hiện một nhiệm vụ nào đó. BPEL là ngôn ngữ dựa trên XML, nó là sự kết hợp của hai ngôn ngữ WSFL - Web Services Flow Language của IBM và XLANG của Microsoft. BPEL chỉ định chính xác thứ tự thực thi của các web service theo một quy trình nghiệp vụ. BPEL cung cấp một nền tảng tự động hóa cho các quá trình nghiệp vụ, cho phép triển khai thực hiện song song các hoạt động không trùng nhau thực hiện để tiết kiệm thời gian và tăng hiệu suất. 40 2.1.3.3. BPMN 2.0 Công cụ này mới được phát triển từ năm 2004 nhưng đã đáp ứng được nhiều yêu cầu của người sử dụng trong việc mô hình hóa hệ thống. Đặc biệt BPMN 2.0 hỗ trợ rất mạnh các quy trình nghiệp vụ dạng thương mại, trong BPMN 2.0 không những hỗ trợ các mô hình hệ thống mà còn hỗ trợ mô hình hóa những quy trình nghiệp vụ thực tế. Chính vì điều này mà BPMN 2.0 được sử dụng rộng rãi và trở thành một chuẩn mô hình hóa các quy trình nghiệp vụ hệ thống cũng như các quy trình nghiệp vụ thực tế. Tóm lại, để hỗ trợ cho việc mô hình hóa các quy trình nghiệp vụ hiện nay có rất nhiều công cụ, tuy nhiên trong khuôn khổ luận văn này sẽ chủ yếu đề cập đến mô hình hóa quy trình nghiệp vụ bằng BPMN 2.0. Trong chương tiếp theo của luận văn sẽ tìm hiểu và tiến hành mô hình hóa một số quy trình nghiệp vụ bằng BPMN 2.0. 2.2. Giới thiệu BPMN 2.0 2.2.1. Khái niệm cơ bản BPMN là một mô tả đồ họa cho các quy trình nghiệp vụ cụ thể trong một mô hình nghiệp vụ. BPMN được phát triển bởi BPMI (Bussiness Process Management Intitinative), phiên bản 1.0 được phát hành vào tháng 5 năm