4.1.1 Khái niệm về kiến trúc hƣớng dịch vụ
Kiến trúc hƣớng dịch vụ (SOA) là một hƣớng tiếp cận với việc thiết kế và tích hợp các phần mềm, chức năng, hệ thống theo dạng module, trong đó mỗi module đóng vai trò là một “dịch vụ có tính loose coupling”, và có khả năng truy cập thông qua môi trƣờng mạng. Hiểu một cách đơn giản thì một hệ thống SOA là một tập hợp các dịch vụ đƣợc chuẩn hóa trên mạng trao đổi với nhau trong ngữ cảnh một tiến trình nghiệp vụ.
59
Hình 4.1. Sơ đồ cộng tác trog SOA
Nhà cung cấp dịch vụ (Service Provider) cần cung cấp thông tin về những dịch vụ của mình trong một dịch vụ lƣu trữ thông tin dịch vụ (Service Registry).
Ngƣời sử dụng (Service Consumer) tìm kiếm thông tin về dịch vụ cần thiết trong Service Regisstry sau đó xây dựng kênh giao tiếp với nhà cung cấp.
Nơi lƣu trữ thông tin dịch vụ(Service Registry) là nơi lƣu trữ các dịch vụ khi một dịch vụ của nhà cung cấp dịch vụ đƣa ra. Đây chính là nơi ngƣời sử dụng dịch vụ có thể tìm và triệu gọi các dịch vụ đƣợc cung cấp.
SOA cung cấp các giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay nhƣ: phức tạp, không linh hoạt và không ổn định. Một hệ thống triến khai theo mô hình SOA có khả năng dễ mở rộng, liên kết tốt. Đây chính là điều kiện cơ sở, nền tảng để tích hợp, tái sử dụng những tài nguyên hiện có.
Thật ra, tƣ tƣởng về một kiến trúc hƣớng dịch vụ không phải là mới mà CORBA, DCOM (mô hình của Microsoft), EJB (mô hình của java) đã thực hiện từ lâu, tuy nhiên cách tiếp cận này còn gặp nhiều hạn chế (nhƣ đã nói ở trên). SOA không chỉ cải tiến đáng kể mà còn đem đến nhiều ƣu điểm nổi trội hơn.
Ƣu điểm quan trọng nhất của SOA là khả năng kết nối mềm và tái sử dụng. các dich vụ có thể sử dụng với trình client chạy trên nền tảng bất kỳ và đƣợc viết ngôn ngữ bất kỳ,…
60
Modul hóa: Tách vấn đề lớn thành nhiều vấn đề nhỏ.
Đóng gói: che đi dữ liệu và Logic trong từng modul đối với truy cập từ ngoài.
4.1.2 Bốn nguyên tắc chính của hệ thống SOA
a. Sự phân định rạch ròi giữa các dịch vụ
Các dịch vụthực hiện quá trình tƣơng tác chủyếu thông qua thành phần giao tiếp. Thành phần giao tiếp này sẽ qui định về những định dạng thông điệp sử dụng trong quá trình trao đổi : thông điệp nào sẽ đƣợc chấp nhận và thông điệp nào sẽ không đƣợc xử lý. Và đây chính là cách duy nhất để các đối tƣợng bên ngoài có thể truy cập thông tin và chức năng của dịch vụ. Ta chỉ cần gửi các thông điệp theo các định dạng đã đƣợc định nghĩa trƣớc mà không cần phải quan tâm đến cách xử lý của dịch vụ nhƣ thế nào (môi trƣờng thực thi, ngôn ngữ lập trình...). Điều này đạt đƣợc do sự tách biệt giữa thành phần giao tiếp và thành phần xử lý trong kiến trúc của dịch vụ.
b. Các dịch vụ tự hoạt động
Các dịch vụ cần phải đƣợc triển khai và hoạt động nhƣ những thực thể độc lập mà không lệ thuộc vào một dịch vụ khác. Dịch vụ phải có tính bền vững cao, nghĩa là nó sẽ không bị sụp đổ khi có sự cố. Để thực hiện điều này, dịch vụ cần duy trì đầy đủ thông tin cần thiết cho quá trình hoạt động của mình để có thể tiếp tục hoạt động trong trƣờng hợp một dịch vụ cộng tác bị hỏng; và để tránh các cuộc tấn công từ bên ngoài (nhƣ gửi thông điệp lỗi, hay gửi thông điệp ồ ạt) bằng cách sử dụng các kỹ thuật về an toàn, bảo mật...
Đây chính là ý nghĩa của khái niệm „loose coupling service‟ mà ta đã đề cập trong định nghĩa SOA.
c. Các dịch vụ chia sẻ lược đồ
Các dịch vụ nên cung cấp thành phần giao tiếp của nó (interface) ra bên ngoài, và hỗ trợ chia sẻ các cấu trúc thông tin, các ràng buộc dữ liệu thông qua các lƣợc đồ dữ liệu (schema) chuẩn (độc lập ngôn ngữ, độc lập hệ nền.). Nhƣ thế hệ thống của ta sẽ có tính liên kết và khả năng dễ mở rộng.
61
d. Tính tương thích của dịch vụ dựa trên chính sách
Điều này nghĩa là, một dịch vụ khi muốn tƣơng tác với một dịch vụ khác thì phải thỏa mãn các chính sách (policiy) và yêu cầu (requirements) của dịch vụ đó nhƣ là mã hóa, bảo mật... Để thực hiện điều này, mỗi dịch vụ cần phải cung cấp công khai các yêu cầu, chính sách đó.
4.1.3 Các tính chất của một hệ thống SOA
a. Loose coupling
Mọi kiến trúc phần mềm đều hƣớng đến liên kết lỏng giữa các module. Mức độ kết dính của mỗi hệ thống ảnh hƣởng trực tiếp đến khả năng chỉnh sửa và mở rộng của chính nó. Kết dính càng chặt bao nhiều thì càng có nhiều thay đổi liên quan cần chỉnh sửa ở phía sử dụng dịch vụ mỗi khi có sự thay đổi nào đó xảy ra.
SOA hỗ trợ liên kết lỏng thông qua việc sử dụng hợp đồng và liên kết (contract and binding). Một ngƣời sử dụng truy vấn đến nơi lƣu trữ và cung cấp thông tin dịch vụ (registry) để lấy thông tin về loại dịch vụ cần sử dụng. Registry sẽ trả về tất cả các dịch vụ thỏa tiêu chuẩn tìm kiếm. Ngƣời dùng chỉ cần chọn dịch vụ mà mình cần, và thực thi phƣơng thức trên đó theo mô tả dịch vụ nhận đƣợc từ registry. Bên sử dụng dịc h vụ không cần phụ thuộc trực tiếp vào cài đặt của dịch vụ mà chỉ dựa trên hợp đồng mà dịch vụ đó hỗ trợ.
b.Sử dụng lại dịch vụ
Bởi vì các dịch vụ đƣợc cung cấp lên trên mạng và đƣợc đăng ký ở một nơi nhất định nên chúng dễ dàng đƣợc tìm thấy và tái sử dụng. Nếu một dịch vụkhông có khảnăng tái sử dụng, nó cũng không cần đến interface mô tả. Các dịch vụcó thể đƣợc tái sử dụng lại bằng cách kết hợp lại với nhau theo nhiều mục đích khác nhau. Tái sử dụng lại các dịch vụcòn giúp loại b ỏnhững thành phần trùng lắp và tăng độvững chắc trong cài đặt, nó còn giúp đơn giản hoá việc quản trị. Thực ra tái sử dụng dịch vụ lại dễ dàng hơn tái sử dụng thành tố hay lớp. Những dịch vụ đƣợc dùng chung bởi tất cả các ứng dụng của một hệ thống SOA gọi là những shared infrastructure service.
62 (adsbygoogle = window.adsbygoogle || []).push({});
c. Sử dụng dịch vụ bất đồng bộ
Trong phƣơng thức triệu gọi dịch vụ bất đồng bộ, bên gọi gửi một thông điệp với đầy đủ thông tin ngữ cảnh tới bên nhận. Bên nhận xử lý thông tin và trả kết quả về thông qua một “kênh thông điệp”, bên gọi không phải chờ cho đến khi thông điệp đƣợc xử lý xong. Khi sử dụng kết hợp thông điệp dạng coarse-grained với một dịch vụ chuyển thông điệp, các yêu cầu dịch vụcó thể đƣợc đƣa vào hàng đợi và xử lý với tốc độ tối ƣu. Do bên gọi không phải chờ cho đến khi yêu cầu đƣợc xử lý xong và trả về nên không bị ảnh hƣởng bởi việc xử lý trễ và lỗi khi thực thi các dịch vụ bất đồng bộ. Trên lý thuyết một hệ thống SOA có thể hỗ trợ gửi và nhận cả thông điệp đồng bộ và bất đồng bộ.
d. Quản lý các chính sách
Khi sử dụng các dịch vục hia sẻ trên mạng, tùy theo mỗi ứng dụng sẽ có một luật kết hợp riêng gọi là các policy. Các policy cần đƣợc quản lý các áp dụng cho mỗi dịch vụ cả khi thiết kế lẫn khi trong thời gian thực thi. Việc này tăng khả năng tạo ra các dịch vụ có đặc tính tái sử dụng.
e. Khả năng cộng tác
Kiến trúc hƣớng dịch vụnhấn mạnh đến khảnăng cộng tác (Interoperability), khả năng mà các hệ thống có thể giao tiếp với nhau trên nhiều nền tảng và ngôn ngữ khác nhau. Mỗi dịch vụ cung cấp một interface có thể đƣợc triệu gọi thông qua một dạng kết nối. Một kết nối gọi là interoperable chứa bên trong nó một giao thức và một định dạng dữ liệu mà mỗi client kết nối đến nó đều hiểu. Interoperability is achieved bằng cách hỗ trợ các giao thức và định dạng dữ liệu chuẩn của dịch vụ và các client. Kỹ thuật này đạt đƣợc bằng cách ánh xạ mỗi tính chất và ngôn ngữ qua một đặc tả trung gian. Đặc tả trung gian sẽ chịu trách nhiệm ánh xạ giữa định dạng của dữ liệu khả kết (interoperable) đến định dạng dữ liệu tùy thuộc vào nền tảng hệ thống. Ví dụ WebService là một đặc tả trung gian cho giao tiếp giữa các hệ thống, JAX-RPC và JAXM chuyển đối tƣợng dạng Java thành SOAP.
63
e. Tự động dò tìm ràng buộc
SOA hỗ trợ khái niệm truy tìm dịch vụ(service discovery). Một ngƣời sử dụng cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên một số tiêu chuẩn khi cần. Ngƣời sử dụng chỉ cần hỏi một registry về dịch vụ nào thoả yêu cầu tìm kiếm.
g. Tự phục hồi
Với kích cỡ và độ phức tạp của những ứng dụng phân tán ngày nay, khả năng phục hồi của một hệ thống sau khi bị lỗi trở thành một yếu tố quan trọng. Một hệ thống tự hồi phục (self-healing) là một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà không cần sự can thiệp của con ngƣời.
4.1.4 Lợi ích của hệ thống SOA
Nói đến SOA là nói đến „tiết kiệm‟- cả tiết kiệm chi phí lẫn thu đƣợc giá trị nhiều hơn từ các hệ thống có sẵn. Hẳn cũng phải có lý do để hàng trăm tập đoàn đã chú ý đến SOA nhƣmột giải pháp tích hợp nhằm giảm giá thành của một đề án một cách rất ấn tƣợng.
Sử dụng lại những thành phần có sẵn
Một trong những lợi ích rõ ràng nhất của SOA là nó giúp các công ty thu đƣợc giá trị nhiều hơn bằng cách sử dụng lại những tài nguyên sẵn có; kết quả là giảm chi phí cho phần kiến trúc và tích hợp. Ngoài ra nó còn giúp giảm chi phí mua phần mềm mới. Thời gian viết chƣơng trình lấy dữ liệu từ máy chủ trƣớc đây đƣợc tính bằng tháng thì bây giờchỉcòn tính bằng phút ! Lợi ích của việc sử dụng lại có thểchia làm 2 phần :
• Lợi ích từ việc sử dụng lại những thành phần nhằm giảm tính dƣ thừa. • Lợi ích từ việc sử dụng lại những thành phần có sẵn khi thiết kế cung cấp một chức năng mới.
Đầu tiên nhƣ đã nói, nhiều phần mềm doanh nghiệp đã phát triển thành những nhóm phần mềm tách biệt (funtional silos), thông thƣờng là tƣơng ứng với mỗi đơn vị kinh doanh. Ví dụ một công ty bán lẻ có thể có một nhóm phần mềm cho hệ thống phân phối, một nhóm phần mềm cho hệ thống lƣu kho và một nhóm phần mềm cho những chức năng liên kết. Thông thƣờng những nhóm phần mềm này
64
đựơc phát triển trên nhiều nền tả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à sử dụng những thành phần có sẵn trƣớc đó mỗi khi có thể thì mỗi khi có lỗi xảy ra ta có thể giới hạn vào khu 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ể.
65
4.1.5 Xây dựng hệ thống SOA với bài toán mô hình trung tâm chăm sóc sức khỏe thông minh khỏe thông minh
Dựa trên mô hình SOA từ đó tham chiếu sang lĩnh vực y tế (bài toán cụ thể là trung tâm chăm sóc sức khỏe thông minh) tác giả mô tả lại các đối tƣợng tƣơng đƣơng trên mô hình SOA nhƣ sau: [8 Tr31 -45]
Service Rigistry - Nơi đăng ký và lƣu trữ dịch vụ: Trung tâm chăm sóc sức khỏe - trung tâm điều phối các dịch vụ từ các cơ sở y tế: Dịch vụ đăng ký KCB qua mạng, dịch vụ đặt lịch, dịch vụ theo dõi chăm sóc, dịch vụ chẩn đoán từ xa, dịch vụ xét nghiệm,...) với nhiều dịch vụ.
Service Provider – Nhà cung cấp dịch vụ: Bệnh viện hay cơ sở y tế - nơi có các sản phẩm dịch vụ y tế muốn cung cấp tới bệnh nhân qua mô hình trung tâm chăm sóc sức khỏe. (adsbygoogle = window.adsbygoogle || []).push({});
Service consumer – Ngƣời sử dụng dịch vụ: Bệnh nhân ngƣời có nhu cầu dịch vụ, ngoài việc đến trực tiếp bệnh viện để yêu cầu dịch vụ họ có thể thông qua trung tâm CSSK để đăng ký yêu cầu dịch vụ từ xa qua mạng.
Sơ đồ cộng tác mô tả dựa trên SOA nhƣ hình sau:
Hình 4.2. Sơ đồ mô tả CSSK dựa trên SOA
Để trực quan ta mô tả một yêu cầu dịch vụ đặt lịch khám tại bệnh viên/ phòng khám qua trung tâm chăm sóc sức khỏe thông minh từ phía bệnh nhân nhƣ sau:
66
Hình 4.3. Sơ đồ mô tả đặt lịch khám
* Bệnh nhân: truy cập vào công thông tin của trung tâm chăm sóc sức khỏe để yêu cầu một dịch vụ đặt lịch khám (Bệnh nhân này đã đăng ký có tài khoản trong trung tâm CSSK )
* Trung tâm CSSK: Sẽ chuyển đến service đặt lịch và tìm đến bác sỹ theo yêu cầu chuyên khoa mà bệnh nhân đăng ký. Nó sẽ kiểm tra lịch của bác sỹ trên hệ thống và gửi yêu cầu đến bệnh viện/ phòng khám để đặt lịch tại bệnh viện hoặc phòng khám. Nểu lịch BS trống thì sẽ sếp lịch và chuyển yêu cầu đến BS, nếu không trống thì chuyển sang bác sỹ khác, trong trƣờng hợp yêu cầu đúng Bs mà bệnh nhân chọn thì phải chờ Bs phản hồi sau đó trả lại yêu cầu cho Bệnh nhân bằng mail hoặc tin nhắn...
Các bƣớc thiết kế tổng thể và chi tiết quy trình nghiệp vụ của toàn bộ hệ thống CSSK sẽ đƣợc trình bày phần sau.
4.2 Kiến trúc tổng thể cho mô hình trung tâm chăm sóc sức khỏe thông minh.
Trở lại với bài toán thực tế đặt ra tại Bệnh viện Hữu nghị Việt Đức về việc khám, điều trị và chăm sóc bệnh nhân trƣớc và sau phẫu thuật đặc biệt là những bệnh phải điều trị lâu dài, theo dõi diễn biến thƣờng xuyên tác giả tập trung nghiên cứu và xây dựng một mô hình trung tâm chăm sóc sức khỏe thông minh với trung tâm điều phối là bệnh viện HN Việt Đức, các bệnh viện tuyến dƣới là bệnh viện vệ tinh của bệnh viện HN Việt Đức, các phòng khám, cơ sở y tế là vệ tinh của bệnh