Luận văn Nghiên cứu kiến trúc hướng dịch vụ(Service-Oriented Architecture) và ứng dụng

ể có thể thực hiện tách biệt giữa thành phần giao tiếp và thành phần thực thi của service. • Tích hợp tiến trình ► Giải pháp đó là tạo ra các tiến trình nghiệp vụ bằng cách tích hợp các tài nguyên có sẵn (dữ liệu, thành tố, ứng dụng và dịch vụ). Và sau đó là tập trung vào việc quản lý các tiến trình nghiệp vụ một cách độc lập với một ứng dụng riêng biệt nào đó. Vấn đề gặp phải đó là đạt được sự “thỏa thuận” giữa các tổ chức về việc định nghĩa các tiến trình nghiệp vụ và một kiến trúc tích hợp hoàn chỉnh nhằm hỗ trợ việc tích hợp những tài nguyên của các hệ thống được thực hiện một cách dễ dàng. • Tích hợp thành phần giao tiếp người dùng ► Giải pháp này thường có hai cách thực hiện khác nhau: o Sử dụng hệ giao tiếp người dùng của các hệ thống cũ như là các thành phần giao tiếp để truy cập dữ liệu từ các ứng dụng hay các giao tác đang thực hiện. Cách này rất không bền vững, đặc biệt là khi hệ giao tiếp người dùng của ứng dụng cần lấy dữ liệu bị thay đổi o Việc tích hợp được thực hiện ở tầng thể hiện như là desktop hay portal. Trang 78 5.2 Phân tích một số kỹ thuật tích hợp sử dụng Middleware 5.2.1 Khái niệm middleware Middleware được sử dụng trong rất nhiều ngữ cảnh, và trong mỗi ngữ cảnh như thế lại có một ý nghĩa khác nhau. Trong ngữ cảnh của chúng ta ở đây, integration, thì middleware là một phần mềm hỗ trợ trong việc tạo ra môi trường trao đổi dữ liệu giữa các hệ thống. Middleware che dấu đi sự phức tạp trong giao tiếp của các hệ thống hay dịch vụ, làm đơn giản hóa sự phát triển những hệ thống, dịch vụ này. Hình 5-1 thể hiện rõ vai trò cơ bản của middleware trong kiến trúc của một hệ thống tích hợp. Hình 5-1 – Vai trò cơ bản của middleware. 5.2.2 Các sản phẩm Middleware sử dụng trong tích hợp hệ thống 5.2.2.1 Adapter Mỗi nguồn dữ liệu trong một hệ thống (có thể là một database hay một ứng dụng) được truy cập thông qua một thành phần gọi là adapter. Một vài hệ thống không được xây dựng sẵn cho mình những thành phần adapter như thế. Vì vậy, khi những hệ thống được tích hợp vào một hệ thống khác thì đòi hỏi phải thiết kế một adapter cho nó. Hầu hết các hệ thống hay hệ quản trị cơ sở dữ liệu đóng gói ngày nay đều đi kèm với những bộ adapter cho nó. Những bộ adapter này có thể được viết bởi chính hãng cung cấp gói sản phẩm đó, và cũng có thể là từ một hãng khác. Trang 79 5.2.2.2 Message Oriented Middleware (MOM) MOM là phần mềm hỗ trợ trao đổi dữ liệu giữa hệ thống dưới hình thức những gói tin rời rạc gọi là thông điệp. Cơ chế thông điệp đã xây dựng và sử dụng từ những năm 1970, và là một trong những cơ chế đầu tiên được dùng trong trong quá trình giao tiếp giữa các hệ thống phân tán. Nhưng khi đó, các cơ chế này được thiết kế “cứng” để thỏa mãn một yêu cầu nào đó. Còn các cơ chế thông điệp bây giờ được xây dựng dựa trên các chuẩn chung. Hầu hết các sản phẩm MOM đều cung cấp rất nhiều tính năng, bao gồm: truyền nhận thông điệp thông qua hàng đợi, đảm bảo an toàn cho dữ liệu truyền, hỗ trợ xử lý đồng bộ và bất đồng bộ và cho phép gửi một lúc đến nhiều nơi thông qua cơ chế publish/subscribe. • Cơ chế hàng đợi thông điệp: ► Các sản phẩm “hàng đợi thông điệp” cho phép gửi một thông điệp từ ứng dụng này đến ứng dụng khác thông qua hàng đợi. Một thành phần được gọi là “quản lý hàng đợi” sẽ quản lý chuyện nhận thông điệp vào và gửi thông tin xác nhận cho đối tượng đã gửi. Hầu hết các thành phần quản lý hàng đợi đều cung cấp một dịch vụ “chuyển dữ liệu an toàn” để đảm bảo dữ liệu đã được nhận đầy đủ trước khi gửi xác nhận cho đối tượng gửi. Hình 5-2 – Cơ chế hàng đợi • Cơ chế Publish/subscribe: ► Cơ chế giao tiếp publish/subscribe tách rời mối liên kết giữa phía gửi và phía nhận. Đối tượng gửi thay vì gửi trực tiếp thông tin đến đối tượng nhận sẽ gửi thông điệp đến một thành phần gọi là pub/sub. Thành phần này sẽ Trang 80 nhận dạng tiêu đề của thông điệp và chuyển đến cho những đối tượng nào đã đăng ký nhận loại thông điệp này. Hình 5-3 – Cơ chế Publish/Subscribe 5.2.2.3 Remote Procedure Call (RPC) RPC được xây dựng nhằm hỗ trợ gọi thực thi các dịch vụ từ xa một cách đơn giản giống như gọi một thủ tục cục bộ bằng cách dấu đi cơ chế phức tạp của mạng. RPC về cơ bản sẽ hoạt động theo cơ chế đồng bộ, nghĩa là đối tượng gọi sẽ bị tình trạng blocked cho tới khi kết quả được trả về. Nhưng cũng có thể hỗ trợ cơ chế xử lý bất đồng bộ cho RPC thông qua kỹ thuật đa luồng. Hình 5-4 - Remote Procedure Call Một đặc trưng quan trọng của RPC đó là cách thiết kế thành phần giao tiếp độc lập với phần thực thi. Trang 81 5.2.2.4 Distributed Object Technology (DOT) Đây là phiên bản hướng đối tượng của RPC. Một ứng dụng có thể sử dụng DOT để định nghĩa một tập các đối tượng có thể gọi thực thi thông qua môi trường mạng. Hình 5-5 – Distributed Object Model Object Broker sẽ cung cấp môi trường để quản lý, giám sát quá trình giao tiếp cũng như là chu kỳ sống của tất cả các đối tượng. DOT dùng một tập tin giao tiếp gọi là IDL file (Interface Description Language). IDL là một ngôn ngữ cấp cao dùng để mô tả thông tin về thuộc tính và phương thức của những đối tượng. • Common Object Request Broker Architecture (CORBA) ► Đây là một tập các đặc tả được phát triển bởi Object Management Group (OMG). Phần thực thi của CORBA còn được gọi là ORBs (Object Request Brokers). CORBA được thiết kế để giải quyết các yêu cầu về tính toán, hỗ trợ tính dễ mở rộng và khả năng chịu lỗi. Một ưu điểm của CORBA đó là nó hoàn toàn không phụ thuộc vào hãng phát triển, cho phép sử dụng nhiều ngôn ngữ lập trình để tạo các đối tượng CORBA. • Enterprise JavaBeans (EJB) ► EJB là kỹ thuật được phát triển bởi Sun Microsystem nhằm đáp ứng các yêu cầu của các nhà phát triển Java trong việc xây dựng các ứng dụng phân tán. EJB được phát triển trên nền J2EE, với mục tiêu là xây dựng các ứng dụng có khả năng dễ mở rộng, hỗ trợ quản lý giao tác và đáp ứng yêu cầu về bảo mật. Trang 82 • Microsoft Distributed Component Object Model (DCOM) ► DCOM là một tập các khái niệm, giao diện lập trình do Microsoft đưa ra vào năm 1995, nhằm hỗ trợ việc giao tiếp với các đối tượng COM thông qua môi trường mạng. DCOM sử dụng cơ chế RPC để thực hiện trừu tượng hóa quá trình gửi và nhận thông tin giữa các đối tượng COM. 5.3 SOA và web service giải quyết vấn đề tích hợp như thế nào 5.3.1 Công nghệ XML và web service Những nghiên cứu gần đây cho thấy rằng: các khó khăn trong việc tích hợp các hệ thống có thể được khắc phục bằng cách định nghĩa thêm một tầng trừu tượng cho các hệ thống tin học hiện có và mới xây dựng. Tầng này sẽ được xây dựng dựa trên các chuẩn của web service. Một số giải pháp chung trong việc dùng web service cho vấn đề tích hợp: • Tích hợp hướng dữ liệu: ► Xác định thông tin dữ liệu nào cần được chia sẻ (các bảng dữ liệu, các định dạng file và thông điệp) ► Xây dựng các lược đồ mô tả XML (Xml Schema) cho các thông tin này. ► Sử dụng SOAP như là định dạng của thông điệp. • Tích hợp hướng chức năng/hàm APIs: ► Xác định các phương thức từ xa nào sẽ được thể hiện ra ngoài như các web service. ► Định nghĩa kiểu dữ liệu XML cho đối số của các phương thức này. ► Sử dụng SOAP như là định dạng thông điệp. • Tích hợp hướng thành phần giao tiếp: ► Định nghĩa thông tin mô tả web service (WSDL). Trang 83 ► Tạo ra các đối tượng bọc và thực hiện ánh xạ tương ứng giữa thành phần giao tiếp vừa định nghĩa với dữ liệu, thông điệp và các lời gọi hàm APIs (cần được chia sẻ) của hệ thống hiện hành. Hình 5-6 – Sử dụng web service trong vấn đề tích hợp. Với sự hỗ trợ kỹ thuật của web service, dữ liệu trao đổi giữa các hệ thống được tự động chuyển đổi sang dạng chuẩn (XML) mà mọi hệ thống đều hiểu được. Tại mỗi hệ thống sẽ chịu trách nhiệm xử lý chuyển đổi dữ liệu từ dạng chuẩn thành những kiểu đặc thù của nó trong quá trình nhận thông điệp và thực hiện xử lý ngược lại (chuyển dữ liệu từ định dạng riêng sang dạng chuẩn chung-XML) trong quá trình gửi thông điệp. Tuy nhiên, các quá trình chuyển đổi này không thật sự lúc nào cũng cần thiết. Đó là khi cả hai phía của kênh giao tiếp đều sử dụng những định dạng dữ liệu, kỹ thuật, công nghệ … giống nhau. Trong những trường hợp như thế, giải pháp tích hợp của ta cần có những xử lý linh họat nhằm không phải thực hiện những quá trình chuyển đổi không cần thiết, như vậy sẽ nâng cao hiệu quả cũng như là hiệu suất hoạt động của hệ thống hơn. Trang 84 5.3.2 Web services integration (WSI) và Service-oriented integration (SOI) WSI và SOI hiện đang là hai giải pháp giành được nhìều sự quan tâm của các tổ chức doanh nghiệp cũng như là các nhà quản trị hệ thống trong việc giải quyết các vấn đề tích hợp hợp hệ thống. 5.3.2.1 Web services integration (WSI) Một dự án WSI thường được xây dựng chỉ để giải quyết vấn đề trao đổi dữ liệu giữa một số lượng nhỏ các hệ thống (hai hay bốn). Đầu tiên nhóm phát triển sẽ định nghĩa những thông điệp SOAP căn cứ theo những cơ sở sau: - Dữ liệu cần trao đổi giữa các hệ thống - Các định dạng thông điệp mà các hệ thống hiện hành có thể hiểu và làm việc trên đó. - Khả năng truy cập vào các dữ liệu này trong hệ thống thông qua tập các phương thức hay hàm APIs mà các hệ thống này hỗ trợ. Tiếp theo, nhóm sẽ định nghĩa các thông tin mô tả service, bao gồm thông tin về cách thức giao tiếp, tập các phương thức, và các mẫu trao đổi thông điệp sao cho đáp ứng được các yêu cầu của dự án (hiện tại). Bên cạnh đó, các vấn đề liên quan đến chất lượng dịch vụ như là bảo mật, an toàn đường truyền, quản lý giao tác, khả năng xử lý lỗi… sẽ được xử lý sau (xem như phần mở rộng, cần đến đâu thì thực hiện đến đó.) Một vài ưu điểm của giải pháp WSI: • Thời gian triển khai nhanh, đặc biệt khi số lượng các hệ thống không nhiều. • Chi phí đầu tư thấp Một số hạn chế của giải pháp này: • Không quan tâm, đầu tư nhiều cho việc xây dựng các mô hình xử lý về dữ liệu, dịch vụ… nhằm mục đích có thể tái sử dụng trong các dự án sau. Trang 85 • Các hệ thống gửi thông điệp SOAP một cách trực tiếp thông qua tầng vận chuyển hay dùng các APIs của các middleware. Điều này sẽ gây khó khăn khi có nhu cầu chuyển đổi sang một tầng vận chuyển hay một sản phẩm middleware khác. • Vấn đề bảo mật chỉ được giải quyết không triệt để, nghĩa là không đưa ra một kiến trúc hoàn chỉnh để có thể dùng chung cho nhiều dự án. Vì thế sẽ gặp nhiều khó khăn sau này khi cần thực hiện liên kết, phối hợp hoạt động giữa các hệ thống. Hình 5-7 – Web services integration (WSI) 5.3.2.2 Service-oriented integration (SOI) SOI là giải pháp tích hợp sử dụng web service với những nguyên tắc thiết kế của kiến trúc hướng dịch vụ (SOA). SOI là giải pháp có tính chất chiến lược và thích hợp cho các dự án mà có quan tâm đến lợi ích lâu dài. SOI bắt đầu bởi giai đoạn “khởi tạo” • Xây dựng một nền tảng cho kiến trúc hướng dịch vụ (SOA), các qui trình, nguyên tắc xử lý, mô hình và công cụ hỗ trợ. Trang 86 • Xác định mô hình về tập các dịch vụ sẽ được sử dụng. Các mô hình này không cần phải thật toàn diện, chỉ cần xác định rõ ràng thông tin về kiểu dữ liệu, thông tin về dịch vụ, và các qui trình cần chia sẻ với các hệ thống khác. • Thực hiện liệt kê và phân lọai toàn bộ các dịch vụ được dùng trong các dự án nhằm hỗ trợ việc tái sử dụng lại các dịch vụ trong các dự án sau. Hình 5-8 – Service-oriented integration (SOI) Một dự án SOI sẽ thực hiện các công việc sau: • Tinh chế lại các mô hình dữ liệu của các hệ thống sao cho phù hợp với dự án hiện tại. • Xây dựng các đặc tả dịch vụ dựa trên những gì có trong phần thông tin mô tả của dịch vụ, bao gồm nguyên tắc xử lý, yêu cầu về bảo mật, yêu cầu về quản lý… • Xây dựng các đối tượng bao bọc các hệ thống cũ dựa trên các đặc tả dịch vụ (thực hiện đóng gói lại thành phần xử lý bên trong của các hệ thông này). • Xây dựng các dịch vụ cần thiết cho dự án. Trang 87 • Xây dựng các bộ chuyển đổi dữ liệu nhằm thực hiện chuyển đổi dữ liệu giữa các mô hình dữ liệu khác nhau của các hệ thống. • Xây dựng môi trường thực thi cho web service nhằm hỗ trợ những tính năng mở rộng như quản lý giao tác, đảm bảo an toàn thông điệp truyền, khả năng xử lý lỗi… Các ưu điểm của giải pháp SOI: • Khả năng tái sử dụng lại các mộ hình dữ liệu, dịch vụ và qui trinh xử lý trong nhiều dự án tích hợp sau này. • Giảm sự lệ thuộc vào một hãng, hay một middleware nào đó thông qua việc xây dựng được một tầng trừu tượng dựa trên các chuẩn của web service. • Thừa hưởng được những lợi ích của web service như bảo mật, an toàn đường truyền, quản lý giao tác, xử lý lỗi.. • Hình thành được một kiến trúc bảo mật có khả năng mở rộng để đáp ứng được yêu cầu liên kết giữa các hệ thống, tổ chức. (hỗ trợ việc triển khai single-sign on, …) Một số giới hạn của giải pháp này: • Đòi hỏi chi phí ban đầu lớn • Thời gian triển khai ban đầu lớn • Nhóm phát triển đòi hỏi phải có kỹ năng và trình độ về kiến trúc hệ thống. • Đòi hỏi sự hỗ trợ của các nhà quản lý nghiệp vụ và quản lý kỹ thuật. 5.4 Ứng dụng SOA và web service để tích hợp các hệ thống được xây dựng trên .NET và J2EE Các web service được xây dựng nhằm hỗ trợ trong việc trao đổi dữ liệu giữa các ứng dụng hay dịch vụ, và cho phép cung cấp phương thức của một đối tượng để có thể được truy cập bởi các đối tượng phần mềm hay ứng dụng khác thông qua môi trường mạng. Trang 88 Hiện nay, .NET và J2EE là hai hệ nền được nhiều người sử dụng để triển khai các hệ thống lớn. Và nhu cầu cho việc tích hợp hay liên kết giữa các hệ thống này là có thực và ngày càng trở nên cấp thiết. Mọi người mong muốn và đang cố gắng có thể tạo được sự liên kết giữa các đối tượng được phát triển trên J2EE (Java Bean) và các đối tượng được phát triển trên nền .NET. Nhưng điều này không dễ dàng thực hiện vì kiến trúc của hai hệ nền này tương đối khác nhau nhiều. • .NET được thiết kế để có thể tương thích tốt với hệ điều hành Windows, và sử dụng lại phần lớn những tính năng nền tảng của Windows như đa luồng, quản lý bộ nhớ, truy cập hệ thống tập tin và tập những hàm APIs cấp hệ thống. • J2EE được xây dựng dựa trên những tính năng của máy ảo Java để hỗ trợ cho nhiều hệ điều hành. Các web service có thể dùng để thiết lập mối liên kết giữa các hệ thống, ứng dụng được phát triển dựa trên hai hệ nền này. Tuy nhiên, vẫn còn một vài hạn chế bởi các tính năng hiện đang được hỗ trợ (đến thời điểm hiện tại) của web service vẫn chưa thật sự là đầy đủ. Ngoài ra còn là sự khác biệt quá lớn về kiến trúc giữa hai hệ nền này. Hình 5-9 đặt các tầng của kiến trúc .NET và J2EE cạnh nhau để thể hiện rõ những sự khác nhau giữa hai hệ nền Hình 5-9 – Sự khác nhau giữa kiến trúc .NET và J2EE Với sự khác nhau cơ bản như thế, nên việc tích hợp, liên kết giữa hai hệ nền .NET và J2EE có một số giới hạn và chỉ có thể đạt được ở một mức độ trừu tượng khá cao. Giải pháp tốt nhất đó là xây dựng các đặc tả dịch vụ (như là các tập tin WSDL) để xác định gói các đối tượng sẽ được trao đổi hay gói các phương thức sẽ được gọi. Trang 89 - Ví dụ như, nếu các ứng dụng cần chia sẻ thông tin về khách hàng, thì ta có thể định nghĩa một lược đồ (Xml schema) mô tả loại thông tin trên, định nghĩa thông tin mô tả các phương thức dựa trên lược đồ này (trong các tập tin WSDL) và sau cùng là xây dựng các thông điệp SOAP dựa trên các nguồn thông tin vừa xây dựng. Ta thấy rằng, khi đó các tập tin WSDL và các lược đồ dữ liệu đóng vai trò rất quan trọng trong việc thực hiện mối liên kết này vì đây chính là các mô hình dữ liệu mà hai bên cùng chia sẻ. Hình 5-10 – Vai trò của WSDL trong liên kết các hệ thống. o Hình 5-10 cho thấy khi một hệ thống xây dựng trên nền .NET và một hệ thống xây dựng trên nền J2EE cùng chia sẻ và cùng hiểu một tập tin WSDL thì chúng có thể liên kết với nhau. Bởi vì web service không hỗ trợ đầy đủ các đặc trưng và tính năng của .NET và J2EE nên mức độ liên kết vẫn còn hạn chế. Cụ thể, các chức năng về quản lý chu kỳ sống của đối tượng, quản lý các phiên giao dịch … của .NET và J2EE không được hỗ trợ bởi web service. Hình 5-11 minh họa các trao đổi thông điệp SOAP giữa hai hệ thống sau khi đã thiết lập và chia sẻ cùng một đặc tả dịch vụ WSDL Hình 5-11 – WSDL mô tả cách các thông điệp SOAP được xử lý Trang 90 Vì các thông điệp SOAP là các tài liệu XML, nên đòi hỏi các bên phải có khả năng hiểu và xử lý các dữ liệu dạng XML. Ngoài ra, các thông điệp này được phát sinh dựa trên WSDL mà đã đạt được thỏa thuận của các bên, nên có thể xem như là một “ngôn ngữ chung” cho các hệ thống để có thể hiểu và xử lý trong quá trình liên kết. 5.5 Ứng dụng SOA và web service trong việc tích hợp các hệ thống cũ Công nghệ web service có thể được dùng để xây dựng cầu nối giao tiếp cho các hệ thống xây dựng trên những hệ nền, sử dụng những công nghệ hay chuẩn khác xa nhau, như là .NET, J2EE, CORBA, WebSphere MQ, hay các ứng dụng đóng gói. Thành phần giao tiếp này sử dụng ngôn ngữ XML và thể hiện các qui ước về trao đổi thông điệp giữa các hệ thống. Một trong các ưu điểm của một cầu nối giao tiếp được định nghĩa tốt đó là nó có thể được mở rộng để có thể bổ sung thêm các đặc tính mới của web service hay tích hợp thêm các hệ thống cũ. Khi đó, các hệ thống cũ sẽ được dịch vụ hóa bằng cách định nghĩa thêm các đặc tả dịch vụ cho chúng và xây dựng thêm các bộ xử lý thông điệp SOAP. Các bộ xử lý thông điệp SOAP này có khả năng nhận các thông điệp SOAP và chuyển đổi chúng sang dạng thông điệp hay lời gọi phương thức đặc thù của hệ thống cũ. Lợi ích đạt được của cách làm này là vô cùng lớn, nó cho phép các tổ chức có thể tái sử dụng lại các giá trị sẵn có và không phải thực hiện công việc gỡ-bỏ-và- thay-thế đầy tốn kém và rủi ro. Một số dạng hệ thống cũ có khả năng dịch vụ hóa, bao gồm: • Các hệ thống mainframe (ví dụ như CICS và IMS) • Các ứng dụng phân tán hướng đối tượng (như CORBA, DCOM, EJB) • Các hệ thống xử lý giao tác (như Tuxedo và Encina) • Các ứng dụng đóng gói (như các ứng dụng của SAP, PeopleSoft, Oracle). • Các hệ quản trị cơ sở dữ liệu (như Oracle, Sybase, DB2, SQL Server) • Các hệ thống B2B và xử lý thông điệp (như SWIFT, EDIFACT, X12, HL7, WebSphere MQ, JMS, MSMQ). Trang 91 ‰ Ví dụ : Service hóa một CORBA server: - IDL (Interface Definition Language) là ngôn ngữ chuẩn dùng để xây dựng phần giao tiếp cho các CORBA server. Tổ chức OMG đã định nghĩa một đặc tả để thực hiện ánh xạ từ IDL sang WSDL. Dựa trên cơ sở này ta có thể chuyển đổi một CORBA IDL sang một đặc tả dịch vụ WSDL, bao gồm các thông tin về: kiểu dữ liệu, các thông điệp, cổng giao tiếp, và các thông tin kết nối. - Bước đầu tiên trong việc dịch vụ hóa một CORBA server đó là phải chuyển đổi CORBA IDL sang WSDL. Sau đây là một ví dụ đơn giản về môt CORBA IDL với một thành phần giao tiếp và hai phương thức: interface HelloWorld { string sayHi (); string greetMe (in string user); }; - Và đây là một phần của đặc tả dịch vụ WSDL tương ứng, bao gồm một cổng giao tiếp và hai phương thức. <schema xmlns="" xmlns:wsdl=""> <output message="tns:HW.HelloWorld.sayHiResponse" name="sayHiResponse"/> <output message="tns:HW.HelloWorld.greetMeResponse" name="greetMeResponse"/> Trang 92 - Một file WSDL đầy đủ có thể nhúng vào một IDE (như là Microsoft Visual Studio) để xây dựng một đối tượng yêu cầu dịch vụ (proxy) Hình 5-12 – Dịch vụ hóa một CORBA server - Cơ chế vận hành sẽ như sau: o Đối tượng sử dụng dịch vụ sẽ gửi một thông điệp SOAP đến legacy service gateway thông qua nghi thức HTTP. o Legacy service gateway có nhiệm vụ chuyển đổi các thông điệp SOAP này sang một hay nhiều lời gọi các đối tượng trên CORBA server o Legacy service gateway cũng sẽ phải thực hiện chuyển các thông tin phản hồi từ CORBA server thành các thông điệp SOAP và trả chúng về cho phía yêu cầu dịch vụ - Tùy thuộc vào việc xây dựng, legacy service gateway có thể là một thư viện được nạp vào khi chạy các đối tượng yêu cầu dịch vụ, hay khi chạy CORBA server, và cũng có thể là một ứng dụng độc lập. - Đặc biệt, sẽ tốt hơn nếu legacy service gateway hỗ trợ việc quản lý cơ chế hoạt động của nó các thông qua thông tin cấu hình dựa trên đặc tả dịch vụ WSDL. Điều này thực hiện được nếu như đặc tả dịch vụ WSDL chứa thêm các thông tin như là cổng giao tiếp (portType) và kết nối (SOAP binding và CORBA/IIOP binding). Trang 93 o HelloWorld portType o SOAP binding <soap:binding style="document" transport=""/> <soap:body use="literal"/> <soap:body use="literal"/> ... o CORBA/IIOP binding Trang 94 ... Kỹ thuật này có thể được sử dụng cho những hệ thống cũ nào mà hỗ trợ IDL (như là Tuxedo FML) hay hỗ trợ các tính năng về reflection (Java, COM, lược đồ dữ liệu của các hệ quản trị cơ sở dữ liệu quan hệ.). Và dễ thấy rằng, kỹ thuật này sẽ đơn giản hơn khi có những chuẩn để thực hiện ánh xạ sang đặc tả dịch vụ WSDL. Trang 95 Chương 6 SOA VÀ QUẢN LÝ TIẾN TRÌNH NGHIỆP VỤ " Chương 6 sẽ trình bày một số khái niệm liên quan về quản lý tiến trình. Phân tích mối quan hệ kết hợp giữa quản lý tiến trình, SOA và Web services. Xem xét các vấn đề liên quan đến thiết kế tiến trình nghiệp vụ. Ngoài ra, chương này cũng sẽ giới thiệu về một số ngôn ngữ đặc tả tiến trình hiện đang được sử dụng phổ biến, như là Web Service Flow Language (WSFL), XLANG, Web Service Choreography Interface (WSCI) và Business Process Execution Language For Web Service (BPEL4WS) 6.1 Một số khái niệm cơ bản về Quản lý tiến trình nghiệp vụ 6.1.1 Tiến trình nghiệp vụ Tiến trình nghiệp vụ là hoạt động trong thế giới thực, trong đó bao gồm một chuỗi các tác vụ được liên kết, phối hợp và thực hiện theo một trình tự thích hợp, với những qui định, ràng buộc nhằm hướng đến một mục tiêu. Hình 6-1 – Minh họa một tiến trình nghiệp vụ Trang 96 Có hai loại tiến trình nghiệp vụ: • Tiến trình không trạng thái: là những tiến trình chỉ được thực thi trong bộ nhớ mà không lưu lại trạng thái vào cơ sở dữ liệu khi chúng ngừng hoạt động. Các tiến trình không trạng thái thích hợp cho những qui trình mà đòi hỏi thời gian xử lý ngắn (tương tác theo cơ chế đồng bộ), hiệu suất hoạt động cao và trong quá trình thực thi, không cần sự tác động của yếu tố con người. • Tiến trình có trạng thái: là những tiến trình mà được thực thi trong nhiều giao tác. Thông tin trạng thái của tiến trình được lưu trữ trong cơ sở dữ liệu mỗi khi ngừng hoạt động. Dạng tiến trình này thích hợp cho những qui trình phức tạp, đòi hỏi thời gian xử lý dài (hỗ trợ tương tác bất đồng bộ). Các tiến trình dạng này cũng phải đáp ứng được các yêu cầu về tính ổn định, độ tin cậy, khả năng xử lý lỗi và khôi phục trạng thái. Trong quá trình thực thi, có thể cần tương tác với yếu tố con người. 6.1.2 Quản lý tiến trình Quản lý tiến trình quan tâm đến cách xác định, mô hình hóa, phát triển, triển khai, và quản lý các tiến trình nghiệp vụ, bao gồm các tiến trình mà đòi hỏi sự hỗ trợ của các hệ thống tin học và tác động của yếu tố con người. Quản lý tiến trình ra đời từ rất lâu, bắt đầu là các hệ thống luồng công việc và phát triển cho tới bây giờ là các hệ thống phối hợp các web service. Những mục tiêu và lợi ích chính của BPM: • Giảm những khó khăn về sự không nhất quán giữa các yêu cầu nghiệp vụ và các hệ thống tin học bằng cách cho phép những đối tượng làm công tác nghiệp vụ đưa ra các mô hình về tiến trình xử lý và sau đó chuyển mô hình này cho bộ phận tin học để xây dựng cơ chế thực thi và quản lý cho các tiến trình này. • Tăng hiệu suất làm việc của các nhân viên bằng cách qui trình hóa và tự động hóa các thao tác nghiệp vụ. Trang 97 • Tăng tính linh hoạt và khả năng cơ động bằng cách tách biệt phần xử lý ra khỏi các qui tắc nghiệp vụ, biểu diễn các qui trình xử lý dưới một dạng mà nó có thể dễ dàng đáp ứng được các thay đổi của yêu cầu, của thị trường. 6.1.3 Hệ quản lý tiến trình: Một hệ quản lý tiến trình cung cấp các kỹ thuật để hỗ trợ việc định nghĩa, mô hình hóa, phát triển, triển khai, và quản lý các tiến trình nghiệp vụ. Hầu hết các hệ quản lý tiến trình đều cung cấp một bộ designer để mô hình hóa các tiến trình, trong đó mỗi nút sẽ tương ứng với một tác vụ và mỗi đường nối tượng trưng cho các luồng xử lý hay luồng dữ liệu liên kết các tác vụ với nhau. Tuy nhiên, một hệ quản lý tiến trình đầy đủ, phải có nhiều hơn thế nữa. Hình 6-2 – Các thành phần của một hệ thống quản lý tiến trình nghiệp vụ • Mô hình hóa tiến trình xử lý: ► Mô hình hóa các yêu cầu nghiệp vụ (trong giai đoạn phân tích) ► Mô hình hóa ràng buộc giữa các tác vụ: trình tự thực hiện, khi nào thì được kích hoạt, đối tượng nào sẽ thực hiện. ► Mô hình hóa các nguyên tắc kèm theo với tiến trình. Trang 98 • Thực thi tiến trình: ► Bao