ĐẠI HỌC THÁI NGUYÊN KHOA CÔNG NGHỆ THÔNG TIN ----------

----------

ĐỀ TÀI NGHIÊN CỨU KHOA HỌC CẤP SINH VIÊN 2010

Đề tài:

KIẾN TRÚC HƯỚNG DỊCH VỤ & ỨNG DỤNG (SERVICE-ORIENTED-ARCHITECTURE)
Mã số đề tài Chủ nhiệm đề tài Cố vấn khoa học : S2010-08-21 : Nguyễn Thị Dung : Th.s. Nguyễn Hồng Tân

Thái Nguyên 12/2010

i

MỤC LỤC
MỞ ĐẦU...........................................................................................................................1 CHƯƠNG 1: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTEDARCHITECTURE).........................................................................................................2

1.1. Kiến trúc phần mềm hiện nay................................................................2
1.1.1. Một số kiến trúc phần mềm phân tán hiện nay...................................2 1.1.2. Vấn đề phát sinh, nguyên nhân và giải pháp......................................3

1.2. Kiến trúc hướng dịch vụ - SOA.............................................................5
1.2.1. Khái niệm............................................................................................5 1.2.2. Nguyên lý SOA...................................................................................7 1.2.3. Tính chất của SOA..............................................................................8 1.2.4. Lợi ích của SOA...............................................................................10 1.2.5. Ưu nhược điểm của SOA..................................................................11 CHƯƠNG 2: PHÁT TRIỂN PHẦN MỀM DỰA VÀO SOA............................................................12

2.1. Mô hình hoạt động và kiến trúc chi tiết của hệ thống..........................12
2.1.1. Mô hình tổng thể của SOA...............................................................12 2.1.2. Mô hình giao tiếp bằng thông điệp (message) trong SOA...............13 2.1.3. Kiến trúc phân tầng chi tiết...............................................................14

2.2. SOA và ứng dụng Web Service...........................................................16
2.2.1. Giới thiệu về Web service.................................................................16 2.2.2. SOA và Web service trong vấn đề tích hợp hệ thống.......................16 2.2.3. Cấu trúc và chi tiết các thành phần của Web service........................18

2.3. Qui trình xây dựng hệ thống SOA.......................................................26
2.3.1. Thách thức khi xây dựng hệ thống...................................................26 2.3.2. Vòng đời của hệ thống......................................................................28

....................................................................................................................29
2.3.3. Các pha cơ bản xây dựng hệ thống SOA..........................................30 2.3.4. Các chiến lược xây dựng hệ thống....................................................31 CHƯƠNG 3: KẾT QUẢ VÀ THẢO LUẬN...............................................................36

3.1. Chương trình demo..............................................................................36
3.1.1. Chức năng chính của chương trình:..................................................36 3.1.2. Xây dựng chương trình.....................................................................36 .........................................................................................................................................41

ii

3.2. Đánh giá chương trình.........................................................................41
KẾT LUẬN....................................................................................................................42 TÀI LIỆU THAM KHẢO.............................................................................................43 CHỮ KÝ XÁC NHẬN..................................................................................................45

iii

MỞ ĐẦU
Sự phát triển của Internet đã thúc đẩy nhu cầu cộng tác, làm việc qua mạng và sử dụng các dịch vụ trực tuyến dần trở thành một nhu cầu thiết yếu trong cuộc sống của chúng ta. Điều đó đòi hỏi các ứng dụng không chỉ là những hệ thống hoạt động đơn lẻ trên một máy trạm (máy client) và chịu phụ thuộc vào một nền tảng cố định nào nữa, mà chúng phải là những hệ thống linh động giúp người dùng làm việc “mọi lúc, mọi nơi”. Điều đó đã làm nhà phát triển phải đối mặt với hàng loạt các vấn đề mới như làm sao tích hợp các thành phần phân tán lại với nhau; hay tái sử dụng những thành phần có sẵn; vấn đề triển khai và bảo trì… đang là một vấn đề làm điên đầu các nhà phát triển. Tuy nhiên, một thực tế hiện nay là phần mềm đang ngày càng trở nên phức tạp quá mức và dường như đang vượt khỏi khả năng kiểm soát của các mô hình phát triển hiện có. Nguyên nhân khiến cho hệ thống có độ phức tạp tăng cao là do sự xuất hiện của nhiều công nghệ mới tạo nên môi trường không đồng nhất, trong khi nhu cầu trao đổi, chia sẻ, tương tác giữa các hệ thống ngày càng tăng và không thể đáp ứng được trong môi trường như vậy. Cùng với đó là vấn đề lập trình dư thừa và không thể tái sử dụng gây tốn kém rất nhiều không những trong giai đoạn phát triển hệ thống mà trong cả vận hành bảo trì phần mềm. Giải pháp cho các vấn đề này là gì? “SOA” hay “Kiến trúc Hướng dịch vụ” là mô hình phần mềm không phải là mới, song đang rất phát triển hiện nay. Đây cũng được coi là giải pháp ưu việt cho các vấn đề đã đề cập ở trên. Kiến trúc này được phát triển từ đầu những năm 2000 đi đầu là IBM. Hiện nay SOA đang được ứng dụng rộng rãi với sự đầu tư nghiên cứu của rất các tập đoàn lớn như IBM, Oracle, SAP, Microsoft… Vậy thật sự SOA là gì ? Nó có thật sự hoàn hảo? Làm thế nào để triển khai SOA? Các vấn đề của hệ thống SOA là gì ? Đó cũng chính là những câu hỏi mà đề tài sẽ nghiên cứu và trả lời.

Thái Nguyên, năm 2010 Nguyễn Thị Dung

1

Nhưng nhược điểm là RMI chỉ thích hợp cho các ứng dụng viết trên ngôn ngữ Java.1. CORBA (Common Object Request Broker Architecture) Là một chuẩn công nghiệp được đưa ra bởi OMG (Object Management Group). bao gồm cả trường hợp cả 2 bên không sử dụng ngôn ngữ Java. Ưu điểm của kiến trúc đối tượng phân tán RMI là người lập trình chỉ cần lập trình các lời gọi phương thức vì đối tượng được gọi đã hiện diện trong máy ảo của nó. DCOM. CORBA được định nghĩa từ 2 thứ: 2 . nó có thể được sử dụng khi bên phía gọi và bên phía phương thức được gọi có thể sử dụng ngôn ngữ lập trình khác nhau.1. cho phép gọi các phương thức từ xa và nhận kết quả trả về. hoặc ở một máy khác so với máy chứa ứng dụng trong khi vẫn được tham chiếu sử dụng như một phần của ứng dụng. Kiến trúc phần mềm hiện nay 1. RMI cung cấp cho việc trao đổi truyền thông giữa các chương trình được viết bằng ngôn ngữ lập trình Java. nhưng không giống như RMI. RMI cho phép chạy các đối tượng trên môi trường JVM (Java Virtual Machine) triệu gọi với đối trượng chạy trên nền JVM khác thông qua việc sử dụng giao diện chung của các phương thức trên client và server. RMI. RMI (Remote Method Invocation): RMI là một phần của bộ J2SDK (Java 2 Platform Standard Development Kit) của Sun và là các hàm thư viện hỗ trợ cho các lời triệu gọi phương thức từ xa và trả về giá trị cho các ứng dụng tính toán phân tán.CHƯƠNG 1: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED-ARCHITECTURE) 1.1. và EJB. Đối tượng có thể có không gian địa chỉ bên ngoài ứng dụng. Các kiến trúc này là sự mở rộng của các hệ thống hướng đối tượng bằng cách cho phép phân tán các đối tượng trên mạng. Một số kiến trúc phần mềm phân tán hiện nay Một số mô hình kiến trúc phân tán đang sử dụng phổ biến nhất hiện nay là: CORBA.

DCOM hỗ trợ kết nối giữa các đối tượng và kết nối này có thể được thay đổi lúc đang chạy. nền tảng phần cứng.1: Mô hình tương tác của các đối tượng DCOM. Các đối tượng DCOM được triển khai bên trong các gói nhị phân chứa mã lệnh quản lý vòng đời của đối tượng và việc đăng ký đối tượng. phục vụ yêu cầu khách hàng tốt hơn. được gọi là IIOP (Internet Interoperability Protocol). Tuy nhiên CORBA có nhược điểm là nó là ngôn ngữ lập trình cấp thấp. chi phí thấp. quản lý kết nối hiệu quả và dễ mở rộng. Tuy nhiên. Hình 1. nguyên nhân và giải pháp Hiện nay áp lực đặt lên các doanh nghiệp ngày càng lớn như: giảm chi phí đầu tư cơ sở hạ tầng. tính ổn định. DCOM (Distributed Component Object Model) DCOM là công nghệ độc quyền của Microsoft.1. khó học và cần một đội ngũ phát triển có kinh nghiệm. Ngoài ra các đối tượng CORBA khó tái sử dụng. khai thác có hiệu quả các công nghệ có sẵn.• • Thực thể mà cho phép liên lạc giữa 2 tiến trình được gọi là 1 mô giới yêu cầu đối tượng (Object Request Broker . rất phức tạp.ORB). nó định nghĩa các thành phần của phần mềm được phân tán qua các mạng máy tính để truyền thông với các thành phần khác. không phụ thuộc vào địa lý. Các ứng dụng dựa trên CORBA hiện nay đang dần đi vào thoái trào.2. khả năng tích hợp cao với các hệ thống bên ngoài… 3 . 1. đáp ứng tốt các thay đổi thường xuyên về nghiệp vụ. Vấn đề phát sinh. Ưu điểm của CORBA: các lập trình viên có thể tùy chọn ngôn ngữ lập trình. giao thức mạng và công nghệ để phát triển mà vẫn thỏa mãn các tính chất của CORBA. các công nghệ của Microsoft có một nhược điểm lớn là bị giới hạn trên hệ nền Windows do chiến lược độc quyền của Microsoft. DCOM mang đến nhiều ưu điểm như: dễ triển khai. Một giao thức được ORB dùng để liên lạc giữa nhiều tiến trình.

Không bền vững: Tiếp đó là sự không bên vững của hệ thống. và hoạt động nghiệp vụ khác nhau. Trong quá trình kết hợp chắc chắn sẽ gặp những khó khăn: Không đủ khả năng quản lý quy trình nghiệp vụ Tốn chi phí tích hợp Quá nhiều định dạng dữ liệu Nhu cầu và yêu cầu của khách hàng thường xuyên thay đổi nhanh chóng nhằm tạo ra tính cạnh tranh liên tục. khó kết hợp hoạt động. - - 4 . và bảo mật ngày càng cao đã làm gia tăng tính phức tạp cho hệ thống. Đa phần những khó khăn trên là bắt nguồn từ các nguyên nhân sau: Phức tạp: Ngày nay mỗi doanh nghiệp công nghệ thông tin có nhiều những hệ thống trên các nền tảng khác nhau. Vấn đề tích hợp trở nên khó khăn hơn và tốn kém hơn. mà không thể thay thế được. tích hợp cùng với nhau. cũng như cơ sở hạ tầng của các công ty. tích hợp. Thêm đó là việc nâng cấp khó khăn. Bởi vậy một hướng đi mới cho các doanh nghiệp chính là tìm kiếm các giải pháp tích hợp các ứng dụng có sẵn hoặc kết hợp với ứng dụng của các doanh nghiệp khác sao cho thỏa mãn nhu cầu. Hầu như công ty nào cũng có những ứng dụng có sẵn nhưng khó nâng cấp.Xây dựng được hệ thống đáp ứng được tất cả các nhu cầu đó quả là vấn đề vô cùng khó khăn. có khả năng trên các lĩnh vực khác nhau để phát triển. Vấn đề an ninh bảo mật. Các phương pháp tiếp cận truyền thống trong việc xây dựng các hệ thống phần mềm thương dẫn đến rất nhiều những giải pháp khác nhau được lắp ghép. Không linh hoạt: Cùng với sự phức tạp trong chiến lược phát triển. triển khai và quản lý các ứng dụng và hệ thống mà bản thân chúng không đồng nhất. Các công ty phát triển phần mềm phải thuê các nhóm nhân viên giàu kinh nghiệm. Kết quả mỗi khi thay đổi về quy trình nghiệp vụ hay yêu cầu thì các công ty phải chấp nhận phát triển những dự án tốn kém hoặc thay thế các công nghệ không phù hợp.

1. chính sách bảo trì và thay đổi để đạt được các lợi ích về khả năng trưởng thành và đáp ứng.2. Mặc dù SOA hoạt động được là nhờ công nghệ.  Dịch vụ (service) là yếu tố then chốt trong SOA.SOA) là cách tiếp cận để xây dựng hệ thống công nghệ thông tin cho phép các doanh nghiệp tận dụng những gì đang có và dễ dàng thay đổi theo yêu cầu để hỗ trợ cho doanh nghiệp. hay một bộ thư viện nào đó. Kiến trúc SOA rất giống với cấu trúc của các phần mềm hướng đối tượng gồm nhiều module.2. được tích hợp lại với nhau để cùng cộng tác thực hiện các tác vụ nào đó theo yêu cầu của khác hàng. vẫn còn có một giải pháp để giải quyết khá toàn diện về mọi mặt khó khăn này và nó đã được triển triển khai trong thực tế. Để thực hiện điều đó SOA định ra một chuẩn giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập 5 . Có thể hiểu dịch vụ như là một loại module thực hiện một quy trình nghiệp vụ nào đó. Thay vào đó.Chính vì vậy mà các doanh nghiệp cần phải có một hướng tiếp cận mới để giải quyết vấn đề môi trường không đồng nhất và tốc độ chóng mặt của sự thay đổi công nghệ trong khi nguồn ngân sách bị hạn hẹp. nhưng khách hàng cần phải chuyển đổi từ chỗ chỉ việc tích hợp công nghệ SOA sang việc phải điều chỉnh các phương pháp thực hiện dự án. Kiến trúc hướng dịch vụ . bao gồm các phần mềm và các chức năng riêng lẻ lại thành một hệ thống hoàn chỉnh. mỗi module trong một ứng dụng SOA là một dịch vụ được cung cấp rải rác ở nhiều nơi khác nhau và có thể truy cập thông qua môi trường mạng. Một trong những mục đích của SOA là giúp các ứng dụng có thể “giao tiếp” được với nhau mà không cần biết các chi tiết kỹ thuật bên trong. May mắn thay.1. “Kiến trúc hướng dịch vụ” (Service Oriented Architecture . SOA được xem như là bước phát triển tiếp theo của nghành công nghệ phần mềm. một hệ thống SOA là một tập hợp nhiều dịch vụ được cung cấp trên mạng. Một trong những cách hiểu sai lầm nhất về SOA là coi SOA là một công nghệ. Khái niệm  SOA (Service Oriented Architecture) – Kiến trúc Định hướng Dịch vụ là một cách tiếp cận hay một phương pháp luận để thiết kế và tích hợp các thành phần khác nhau.SOA 1. Tuy nhiên khái niệm module trong SOA không đơn thuần là một gói phần mềm. Nói một cách ngắn gọn.

mỗi service có tính độc lập cao. các class và type sẽ được đặc tả hình thức (data được đặc tả trong schema. hoặc tạo một giao thức riêng. và có thể tái sử dụng. chẳng hạn dùng các giao thức mạng có sẵn. behavior được đặc tả thành các contract). Not the Class: Về mặt trao đổi dữ liệu.với nền tảng hệ thống. bất cứ nơi nào cũng có. SOA là cấp độ cao hơn của phát triển ứng dụng.  Share the Schema and Contract. nó giúp cho các doanh nghiệp có thể tích hợp các thành phần hiện có vào các ứng dụng mới và các thành phần này có thể được chia sẻ hoặc tái sử dụng trong nhiều lĩnh vực khác nhau của công ty đó mà không cần phải chỉnh sửa mã nguồn hay phải tái cấu trúc lại hệ thống. Tương thích về mặt cấu trúc dựa trên các đặc tả hình thức bao gồm contract (dựa trên Web Service Description Language (WSDL) hoặc Business Process Execution Language for Web Services (BPEL4WS)) và schema (XSD).  Tính tự trị (Autonomous): Về mặt lý thuyết.  Service Compatibility Is Based on Policy: Sự tương thích giữa các service được căn cứ vào các policy (chính sách). Sự trừu tượng là cốt lõi của khái niệm dịch vụ. Như vậy. chú trọng đến quy trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dưới. Tóm lại. một dịch vụ có các đặc điểm sau:  Có ranh giới rõ ràng (Boundaries Are Explicit): Mỗi service được xây dựng dựa trên các giao chuẩn hóa đã được sử dụng rộng rãi. Nhưng từ năm 2001. các dịch vụ web (Web service) được xây dựng dựa trên nền tảng web toàn cầu. Chi tiết hiện thực của mỗi service sẽ không được thể hiện ra bên ngoài. Thay vào đó. đã trở thành một phương pháp phổ biến cho việc kết nối các thành phần của hệ thống SOA với nhau. Mỗi service chỉ công bố một số các giao của nó cho người sử dụng có thể dùng để gởi các yêu cầu và nhận kết quả trả về. Thoạt nhìn SOA và Web Service trông có vẻ 6 . Sự tương thích dựa trên policy cung cấp khả năng phân tích cũng như đảm bảo sự tương thích giữa các service. có thể được xây dựng và đưa vào sử dụng mà không phụ thuộc vào các service khác. Có nhiều cách khác nhau để kết nối các dịch vụ. các service không truyền các class và type.

hệ thống SOA có những tính chất cơ bản.2.2. SOA nhấn mạnh việc hạ thấp các rào cản truyền thống tới khả năng tái sử dụng của ứng dụng. Nó cũng phải có khả năng kết nối tới các dịch vụ được đưa ra bởi các ứng dụng khác để tạo thành các dịch vụ cao cấp hơn hay còn gọi là ứng dụng tổ hợp. Nguyên lý SOA SOA tìm cách giải quyết một số vấn đề theo cách nhìn lấy ứng dụng làm trung tâm.2: Mô hình cơ bản của SOA. 7 . Có thể tóm gọn những phát biểu đó theo các nguyên lý như sau: Ứng dụng phải mở ra khả năng cho phép các ứng dụng mới hoặc ứng dụng đang tồn tại có thể sử dụng được. Phải chú ý tới việc quản lý và và đảm bảo khả năng có thể quản trị của hệ thống để đảm bảo tính linh hoạt do ba nguyên tắc đầu tiên không bị xáo trộn và xung đột với nhau. Để có thể xem xét hoạt động và xây dựng được hệ thống thì việc hiểu rõ tính chất của hệ thống đóng vai trò rất quan trọng. - - Nói cách khác. Phối hợp tiến trình nghiệp vụ giữa nhiều nhà cung cấp. Hình 1. 1. Tôn trọng nguyên tắc thiết kế này của SOA sẽ giải quyết được bài toán lớn về vấn đề tích hợp cũng như bảo trì hệ thống phần mềm đang là thách thức đối với các nhà phát triển công nghệ thông tin trong giai đoạn hiện nay. Chúng ta sẽ tìm hiểu rõ hơn về các Web Service trong các phần tiếp theo. Các chuẩn mở phải được thông qua để cho phép tích hợp giữa các doanh nghiệp. nhiều đối tác thậm chí có thể với cả khách hàng. Sự khác biệt về công nghệ không thành vấn đề và khả năng tương tác trở thành mục tiêu then chốt.giống nhau nhưng chúng không phải là một. Dựa trên nguyên lý.

2.2. Kết nối lỏng lẻo Vấn đề kết nối nói tới một số ràng buộc giữa các module lại với nhau. Tính chất kết nối lỏng lẻo đem đến sự độc lập giữa bên cung cấp và bên sử dụng nhưng nó đòi hỏi các giao diện phải theo chuần và cần một thành phần trung gian quản lý. 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 tốc độ vững chắc trong cài đặ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. Mức độ kết nối của hệ thống ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống. 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ố 8 . nó còn giúp đơn giản hóa việc quản trị. Tính kết nối lỏng lẻo giúp gỡ bỏ những ràng buộc điều khiển giữa những hệ thống đầu cuối. nếu bên sử dụng dịch vụ không cần biết mọi thông tin chi tiết của dịch vụ trước khi triệu gọi nó thì quan hệ giữa 2 bên càng có tính lỏng lẻo. Mức độ kết nối tăng dần khi bên sử dụng dịch vụ cần biết nhiều thông tin ngầm định của bên cung cấp dịch vụ để sử dụng dịch vụ được cung cấp.2. 1. nó cũng không cần đến giao diện mô tả.1. khả năng mở rộng và khả năng đáp ứng cao. và ít xảy ra sự cố. Hầu như mọi kiến trúc phần mềm đều hướng đến tính kết nối lỏng lẻo giữa các module. những sự thay đổi sẽ có ảnh hưởng ít nhất tới hệ thống và hệ thống vẫn có thể hoạt động khi có thành phần nào đó bị hư hỏng. Kết nối càng chặt bao nhiêu thì có nhiều thay đổi chỉnh sửa khi có sự thay đổi nào đó xảy ra. Ngược lại.3.1. Khi đó. Tính chất của SOA 1. Tối thiểu hóa sự phụ thuộc giúp hệ thống linh hoạt. Nếu một dịch vụ không có khả năng tái sử dụng. Các module có tính chất kết nối lỏng lẻo có một số ràng buộc được mô tả rõ ràng trong khi các module có tính kết nối chặt lại có nhiều ràng buộc không thể biết trước. Tái sử dụng dịch vụ Bởi vì các dịch vụ được cung cấp trên môi trường mạng và được đăng ký ở một nơi nhất định nên chúng dễ ràng được tìm thấy và sử dụng lại.3. Nghĩa là nếu bên sử dụng dịch vụ biết vị trí và chi tiết định dạng dữ liệu của bên cung cấp dịch vụ thì quan hệ sẽ càng trở nên chặt chẽ. Kết nối lỏng lẻo làm cho sự phụ thuộc ở mức tối thiểu. trung chuyển yêu cầu giữa các hệ thống đầu cuối.2.3. Mỗi hệ thống có thể tự quản lý độc lập nhằm tăng năng xuất. Có 2 loại kết nối là lỏng lẻo và chặt chẽ. Những thay đổi cài đặt cúng được che dấu đi.

Bên sử dụng sẽ chọn một dịch vụ có phí giao dịch thấp nhất trong danh sách các dịch vụ trả về. khách hàng yêu cầu một registry tìm tất cả các dịch vụ có khả năng kiểm tra thẻ tín dụng.2. bao gồm cả chi phí giao dịch. 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 chính sách. những nhân viên phát triển phần mềm chỉ cần tập trung vào quy trình nghiệp vụ trong khi nhóm điều hành và nhóm hỗ trợ tập trung vào các luật kết hợp. Nếu không sử dụng các chính sách. và tùy vào mỗi ứng dụng nên giảm tối đa các thay đổi phần mềm. bên sử dụng chỉ cần định dạng dữ liệu yêu cầu đúng theo mô tả và gửi đi.3. Registry trả về một tập các danh mục thỏa mãn yêu cầu. Việc đó làm tăng khả năng tạo ra các dịch vụ có đặc tính tái sử dụng.2. Các mục đó chứa thông tin về dịch vụ. Ngược lại. 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 dịch vụ chia sẻ cơ sở hạ tầng. Bởi vì các chính sách được thiết kế tách biệt. Người sử dụng chỉ cần hỏi một registry về một dịch vụ nào thỏa yêu cầu tìm kiếm. kết nối đến nhà cung cấp dịch vụ dựa trên thông tin địa chỉ registry đã cung cấp để sử dụng dịch vụ kiểm tra thẻ tín dụng. Trong phần mô tả dịch vụ kèm theo đã có tất cả các tham số cần thiết dùng để thực thi dịch vụ. Các chính sách cần được quản lý và áp dụng cho mỗi dịch vụ cả trong quá trình thiết kế và trong thời gian triển khai.3.4. Tự động dò tìm và ràng buộc động SOA hỗ trợ khái niệm khai thác dịch vụ (service discovery). nếu sử dụng các chính sách. thì các nhân viên phát triển phần mềm. Ví dụ.3. nhóm điều hành và nhóm hỗ trợ phải làm việc với nhau trong suốt thời gian phát triển để cài đặt và kiểm tra những chính sách. Mối ràng buộc duy nhất giữa bên cung cấp và bên sử dụng là bản hợp đồng được cung cấp bởi registry trung gian. Mối ràng buộc này là ràng buộc trong thời gian chạy. Tất cả thông tin cần thiết về dịch vụ được lấy về và sử dụng trong khi chạy. 1. 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. Vậy với 9 . Quản lý chính sách Tập các chính sách là tập tất cả các qui tắc chung mà mọi thành phần trong hệ thống đều phải tuân thủ.hay lớp. một hệ thống chuyển khoản. 1. Nhà cung cấp dịch vụ sẽ thực thi kiểm tra thẻ tín dụng và trả về một thông điếp có định dạng đúng như trong phần mô tả dịch vụ. Khi sử dụng các dịch vụ chia sẻ trên mạng.

Một kiến trúc hỗ trợ kết nối và thực thi động sẽ có khả năng tự phục hồi hơn một hệ thống không hỗ trợ những tính năng trên.3.4. Độ tin cậy là mức độ đo khả năng của một hệ thống xử lý tốt như thế nào trong tình trạng hỗn loạn.5. các dịch vụ luôn có thể hoạt động hay ngừng hoạt động bất cứ lúc nào. nhất là đối với những áp dụng tổng hợp từ nhiều dịch vụ của nhiều tổ chức khác nhau. Hạ tầng mạng phải cho phép các kết nối động từ nhiều hệ thống khác nhau kết nối đến trong khi chạy. Ngoài ra. Một hệ thống tự phục hồi là hệ thống có khả năng tự phục hồi sau khi lỗi mà không cần sự can thiệp của con người. bên sử dụng dịch vụ không cần biết định dạng của thông điệp yêu cầu và thông điệp trả về.Thúc đẩy khả năng phát triển của hệ thống hiện có cũng như khả năng mở rộng của hệ thống trong tương lai. nên có thể có nhiều cài đặt khác nhau cho cùng một giao diện. Đây là một trong những tính chất cơ bản của hệ thống hướng dịch vụ (SOA). . Lợi ích về mặt kỹ thuật: 10 . 1. Khả năng tự hồi phục Với kích cỡ và độ phức tạp của những hệ thống phân tán ngày nay.2. Độ tin cậy phụ thuộc vào khả năng phục hồi của phần cứng sau khi bị lỗi. Trong SOA.Doanh nghiệp có điều kiện tập trung thời gian để tìm kiếm các giải pháp cho các bài toán liên quan đến kinh tế. cũng như địa chỉ dịch vụ cho đến khi cần.2. Khả năng này chỉ có được khi client tương tác với giao diện của dịch vụ chứ không tương tác trực tiếp cài đặt của dịch vụ. Một khía cạnh khác ảnh hưởng đến độ tin cậy là kiến trúc mà dựa trên đó những ứng dụng được xây dựng. những hệ thống dựa trên dịch vụ yêu cầu tách biệt giữa giao diện và cài đặt.SOA. Về mặt kinh tế: . 1. Lợi ích của SOA Sử dụng mô hình SOA trong việc thiết kế hệ thống mang lại rất nhiều lợi ích về cả mặt kinh tế và kỹ thuật. Nếu một thể hiện service nào đó không hoạt động thì một thể hiện khác vẫn có thể hoàn tất giao dịch cho khách hàng mà không bị ảnh hưởng gì. khả năng phục hồi của một hệ thống sau khi bị sự cố là một yếu tố rất quan trọng.

. 1. Dễ dàng và nhanh chóng tạo ra các tiến trình nghiệp vụ từ các service đã có. bí mật và toàn vẹn dữ liệu. Đặc biệt. khi xây dựng ứng dụng tổng hợp từ nhiều dịch vụ với tính tái sử dụng cao thì vấn đề bảo mật như: xác thực. Khó miêu tả dữ liệu không cấu trúc trong header của message.Cho phép dễ dàng triển khai chương trình.2.5. 11 . . phân quyền. Vậy SOA hoạt động như thế nào? Bằng cách nào để triển khai nguyên lý SOA vào hệ thống phần mềm thực tế và qui trình xây dựng hệ thống ra sao? Phần tiếp theo sẽ đi sâu hơn về SOA và trả lời các câu hỏi đó. môi trường chạy và quản lý service dễ dàng hơn..Độc lập hệ thống : những service không phụ thuộc vào hệ thống và mạng cụ thể. . bảo vệ quyền riêng tư… trở thành một bài toán hết sức phức tạp và đòi hỏi giải quyết bằng những hướng tiếp cận bảo mật hoàn toàn mới so với các phương pháp bảo mật truyền thống. Ưu nhược điểm của SOA SOA có thể được coi là một kiến trúc ưu việt trong thiết kế và xây dựng hệ thống phần mềm cho doanh nghiệp bởi: Hệ thống uyển chuyển và lâu dài thuận tiện cho việc chỉnh sửa. . Tuy nhiên.Khả năng hồi đáp thích nghi tốt và nhanh hơn để đáp ứng với sự thay đổi về yêu cầu giao dịch. Khả năng tương tác của các service.Những sự xác nhận và chứng minh của Service consumer về những tính năng security dựa trên giao tiếp Service tốt hơn cơ chế kết nối chặt chẽ. bên cạnh những ưu điểm SOA vẫn tồn tại một số yếu điểm như sau: Trên đây là những trình bày tổng quan và đặc trưng nhất của SOA. nâng cấp hoặc mở rộng hệ thống.Có khả năng tái sử dụng. Hệ thống phức tạp.

. Service Registry: Nơi lưu trữ thông tin về các service của các Service Provider khác nhau. resource sử dụng.... Mô hình tổng thể của SOA Hình 2. Những thông tin này sẽ hỗ trợ thêm cho quá trình tìm kiếm của Service Consumer. performance.CHƯƠNG 2: PHÁT TRIỂN PHẦN MỀM DỰA VÀO SOA 2. - Service Provider sẽ đăng ký thông tin về service mà mình có thể cung cấp (các chức năng có thể cung cấp. Khi đã xác định được Service Provider mong muốn. bầu chọn từ các khách hàng đã sử dụng service.1: Mô hình tổng quan của SOA Service Provider: Cung cấp các service phục vụ cho một nhu cầu nào đó. Service Consumer thiết lập kênh giao tiếp trực tiếp với Service Provider nhằm sử dụng service hoặc tiến hành thương lượng thêm (về mặt giá cả. Serive Consumer: khách hàng dịch vụ hay những user sử dụng service được cung cấp bởi Service Provider. 12 . khả năng của hệ thống (resource.) vào Service Registry. User (service consumer) không cần quan tâm đến vị trí thực sự mà service họ cần sử dụng đang hoạt động. Service Consumer dựa trên những thông tin này để tìm kiếm và lựa chọn Service Provider phù hợp.1. Họ chỉ cần quan tâm dịch vụ đó là gì. Mô hình hoạt động và kiến trúc chi tiết của hệ thống 2..1.1.. giá cả dịch vụ. Service Registry còn có thể xếp hạng các Service Provider dựa trên các tiêu chí về chất lượng dịch vụ. Service Consumer khi có nhu cầu về một service nào đó sẽ tìm kiếm thông tin trên Service Registry.). Ngoài chức năng hỗ trợ tìm kiếm.

1.2. • Quản lý luồng: Việc trao đổi thông điệp theo cơ chế bất đồng bộ giúp ứng dụng không cần ngừng thực thi để chờ một tác vụ kết thúc mà có thể tạo ra các luồng (thread) xử lý các công việc khác nhau.. 13 .). Cơ chế Store-and-Forward này đảm bảo các thông điệp sẽ không bị thất lạc trong trường hợp Receiver bị quá tải và không thể nhận thêm yêu cầu mới. • Giao tiếp tin cậy: các thông điệp từ bên gửi có thể được gửi đến một service trung gian có nhiệm vụ lưu trữ (store) các thông điệp. Các service hoạt động trên các platform khác nhau vẫn có thể giao tiếp với nhau nhờ vào các interface giao tiếp đã được chuẩn hóa để cộng tác xử lý một tác vụ nào đó. Hình 2. Service trung gian sẽ chuyển tiếp (forward) thông điệp cho bên nhận khi bên nhận có thể xử lý yêu cầu tiếp theo.2: Message được truyền nhận giữa các dịch vụ Sử dụng thông điệp (message) để giao tiếp có các lợi thế sau: • Độc lập nền: thông điệp (message) trở thành ngôn ngữ chung của các platform và các ngôn ngữ lập trình khác nhau. điểm khác biệt chính của SOA là cung cấp khả năng giao tiếp giữa các thành phần trong hệ thống sử dụng thông điệp (message) dựa trên các giao thức đã được chuẩn hóa (HTTP. hệ thống SOA trở nên độc lập với nền (platform independent).2. Điều này đảm bảo các service trên các platform khác nhau hoạt động với cấu trúc dữ liệu đặc thù của platform đó. Chính nhờ đặc điểm này. Điều này giúp cho người gửi và người nhận tiếp tục xử lý công việc sau khi gửi thông điệp mà không cần dừng thực thi để chờ thông điệp trả lời. Mô hình giao tiếp bằng thông điệp (message) trong SOA So với kiểu thiết kế Component-Based (hướng thành phần). SMTP.. FTP. • Giao tiếp bất đồng bộ: Người gửi và người nhận không cần phải chờ thông điệp trả lời sau khi đã gởi đi một thông điệp.

Những dịch vụ này sử dụng những dịch vụ của tầng kết nối và các dịch vụ orchestration khác để kết hợp những chức năng cấp thấp hơn thành những dịch vụ hoạt động ở cấp cao hơn. Mỗi một công ty có một mô hình SOA khác nhau. Kiến trúc phân tầng chi tiết Hiện nay chưa có một mô hình chính thức nào của SOA. giao tiếp với các ứng dụng khác. có nhiệm vụ giao tiếp trực tiếp với các thành phần khác như cơ sở dữ liệu. Điều này cung cấp khả năng điều khiển liên quan đến bảo mật như xác thực và phân quyền. Tầng orchestration chứa các thành phần đóng vai trò vừa là dịch vụ sử dụng vừa là những dịch vụ cung cấp. nguồn tài nguyên khác nhau trong mạng máy tính để trở thành một hệ thống nhất. Thật sự SOA là một phương pháp luận giúp chúng ta tận dụng sức mạnh của các nguồn lực. các web service… Vì vậy có thể coi đây là tầng vật lý của SOA. . Nhìn chung mô hình SOA có các đặc điểm sau: Hình 2.1.Tầng Connectivity: đây là tầng thấp nhất của SOA. 2.3.Tầng Composite Application: là các ứng dụng tổng hợp nhằm mục đích trình diễn (presentation) và hiển thị thông tin cho người dùng cũng như 14 . • Bảo mật end-to-end: Thông điệp có thể lưu trữ thông tin về hình thức bảo mật của kênh giao tiếp. .Tầng Orchestration: là các dịch vụ xử lý các quy trình nghiệp vụ và độc lập với tầng vật lý phía bên dưới. có hành vi gần với những chức năng nghiệp vụ hơn.• Giao tiếp từ xa: Các thông điệp lưu trữ thông tin về các đối tượng dữ liệu dưới dạng đặc tả hình thức thay thế việc phải serialization and deserialization các đối tượng dữ liệu truyền qua mạng khi ứng dụng thực hiện gọi từ xa một ứng dụng khác.3: Kiến trúc chi tiết của SOA .

Như vậy có thể thấy SOA không chỉ đơn thuần là về mặt công nghệ mà nó là tổng hòa của rất nhiều yếu tố: công nghệ. các ứng dụng client mở rộng (rich client). SOA là tư duy hệ thống ưu việt cho giai đoạn công nghệ hiện nay. 15 . Nếu hệ thống cần việc chạy nhanh cho một ứng dụng đặc biệt thì RMI.4: Các thành phần tham gia triển khai hệ thống SOA Vậy khi nào sử dụng SOA? Đó là khi thiết kế hệ thống đặt ra một câu hỏi lớn là việc cân nhắc giữa khả năng sử dụng lại và hiệu năng của hệ thống. Tầng này có thể là các website. DCOM là sự lựa chọn. Phần tiếp theo sẽ trình bày một công nghệ có thể nói là thể hiện tốt nhất cho SOA hiện nay – Web Service.- cung cấp một giao diện cho người dùng tương tác với hệ thống như là một phần mềm duy nhất.… Các thành phần khác: gồm có quy trình phát triển (development). và quản lý con người (governance). CORBA. quản lý các dịch vụ (service management). con người và quy trình nghiệp vụ. Nó dễ dàng sử dụng lại trong tương lai và cho phép các ứng dụng tương tự được thiết kế một cách nhanh chóng. Nhưng hệ thống khó có thể thay đổi hoặc sử dụng lại. các thiết bị di động thông minh (smart device). cơ sở hạ tầng. Hình 2. Nếu hệ thống dự định thay đổi thường xuyên mà không yêu cầu quá cao về tốc độ thì SOA là phương cách tiếp cận tốt nhất. Vậy làm cách nào để triển khai tư duy đó vào các ứng dụng thực tế? Đó là vấn đề về công nghệ. portal.

Trong đó: XML cung cấp một ngôn ngữ mà có thể được sử dụng giữa các nền tảng và ngôn ngữ lập trình khác 16 .đáp trả. Web service là một công nghệ triệu gọi từ xa có tính khả chuyển cao nhất hiện nay: mang tính độc lập nền. chạy trên các nền tảng (phần cứng & OS) khác nhau đều có thể trao đổi với nhau thông qua công nghệ này. Tầng transport của Web Service thường dùng những công nghệ truyền tải phổ dụng nhất như HTTP.. 2. có thể được phát hiện bằng cách sử dụng UDDI và có thể được sử dụng bởi ứng dụng khác khác nhau. SOA và Web service trong vấn đề tích hợp hệ thống Web services là những thành phần ứng dụng. Một tương tác định hướng dịch vụ luôn bao hàm một cặp đối tác: nguồn cung cấp dịch vụ và khách hàng sử dụng dịch vụ. Với web service. SOA và ứng dụng Web Service 2. Thực ra.2. SMPT..2. thì triển khai dịch vụ bằng Web service có thể nói là điều “tất nhiên”.2. Web service hoạt động dựa trên nền tảng là XML và HTTP. hiện thực giao tiếp và phương thức gọi giao tiếp. Về cơ bản. Dịch vụ và module phần mềm nghiệp vụ được truy cập thông qua giao tiếp.2. Giới thiệu về Web service Đặc điểm chính của SOA là tách rời phần giao tiếp với phần thực hiện dịch vụ. thường theo cách thức yêu cầu . Web Service cho phép truy cập thông qua định nghĩa giao thức-và-giao tiếp. Điều này cho phép chúng ta liên tưởng đến một công nghệ được đề cập nhiều hiện nay: Web Service. Mà SOA là kiến trúc kết nối lỏng lẻo các service và các service đó tương tác với nhau thông qua Web service. kiến trúc SOA sử dụng Web service như là một giải pháp chính để giải quyết vấn đề tích hợp nghiệp vụ giữa các hệ thống. SOA là kiến trúc phần mềm phát xuất từ định nghĩa giao tiếp và xây dựng toàn bộ mô hình ứng dụng như là mô hình các giao tiếp. giao tiếp bằng cách sử dụng giao thức mở chứa đựng và mô tả chính nó. Và đặc biêt trong quá trình internet hóa mọi dịch vụ hiên nay. tên gọi “kiến trúc định hướng giao tiếp” thích hợp hơn cho SOA. Giao tiếp là trung tâm của toàn bộ triết lý kiến trúc này. Ngay cả với yêu cầu dịch vụ một chiều thì nó vẫn là yêu cầu trực tiếp có chủ đích từ một phần mềm này đến một phần mềm khác. độc lập ngôn ngữ.2. các chương trình viết bằng các ngôn ngữ lập trình khác nhau. Do đó. (tuy hiện nay thường chỉ dùng HTTP) nên khả năng phân tán trên diện rộng như Internet là rất thuận tiện.1.

Description. SOAP: Giao thức dựa trên XML và HTTP cho phép giao tiếp trên môi trường mạng.nhau và vẫn thể hiện thông điệp và chức năng phức tạp. Service Broker: Lưu trữ thông tin về các service được cung cấp bởi các Service Provider. Web Service với mô hình hoạt động 3 bên tương ứng với mô hình hoạt động của SOA. UDDI: Một bộ khung chuẩn cho phép mô hình hóa và cụ thể hóa các Web Service đã được đăng ký. sử dụng một bộ các chuẩn công nghệ. Các giao thức HTTP là giao thức Internet được sử dụng nhiều nhất. and Integration (UDDI). WSDL: Ngôn ngữ mô tả Web Service theo chuẩn.5: Mô hình hoạt động của web service Hoạt động của mô hình Web Service như sau: Service Provider: Dùng Web Services Description Language (WSDL) để mô tả dịch vụ mà mình có thể cung cấp và xuất bản (đăng ký) với Service Broker (tương tự với Service Registry trong SOA). Thành phần chính của Service Broker là các kho lưu trữ được mô tả bởi Universal Discovery. Cung cấp chức năng tìm kiếm hỗ trợ Service Requester (Service Consumer trong SOA) trong việc xác định Service Provider phù hợp. Hình 2. - 17 . Đó là: XML: Chuẩn định dạng dữ liệu và thông điệp.

. Bằng việc sử dụng UDDI và chức năng tìm kiếm của Service Broker. Ngay sau đó. sử dụng Web Service cho việc tích hợp SOA giúp ứng dụng đạt được những mục tiêu theo nguyên lý SOA: Thông qua các chuẩn công nghiệp.- Service Requester: Dùng WSDL để đặc tả nhu cầu sử dụng (loại service. WSDL (Web Services Description Language). thời gian sử dụng. Phần mềm phải cung cấp các kênh giao tiếp (adapter) cho Web service. Như vậy. giữa Service Requester và Service Provider thiết lập kênh giao tiếp sử dụng SOAP để thương lượng giá cả và các yếu tố khác trong việc sử dụng service. Discovery and Integration). Cấu trúc và chi tiết các thành phần của Web service Nền tảng của các dich vụ web gồm các yếu tố: XML (eXtensible Markup Language). Sử dụng dữ liệu và tầng dữ liệu độc lập nằm giữa các ứng dụng để ẩn đi cấu trúc dữ liệu bên dưới. 2.) và gởi cho Service Broker. 18 . UDDI (Universal Description. resource cần thiết. SOAP (Simple Object Access Protocol). mức giá . Các chuẩn này gồm Web Service với các định nghĩa thành phần chuẩn công nghiệp cho XML.2. Service Requester có thể tìm thấy Service Provider thích hợp. Mọi tương tác với dữ liệu đều phải thông qua Web Service. Sử dụng được những phần mềm thương mại đã xây dựng sẵn nhiều nhất có thể.3.. Đóng gói các ứng dụng cho phép kế thừa với giao diện đúng theo chuẩn công nghệ chung. - - Làm thế nào Web Service có thể đạt được những mục tiêu trên? Chúng ta sẽ đi vào xem xét chi tiết các công nghệ và kỹ thuật thực hiện của Web Service. Các Web Service đều phải được sử dụng thông qua giao diện này.

Vì vậy XML là công cụ chính để giải quyết vấn đề này và là kiến trúc nền tảng cho việc xây dựng một Web Service.2. Về hình thức.eXtensible Markup Language XML là một chuẩn mở do W3C đưa ra và được phát triển từ SGML.Hình 2. nhưng không tuân theo một đặc tả quy ước như HTML. các thông tin mã hóa sẽ hoàn toàn phù hợp với các thông tin theo chuẩn của SOAP hoặc XML-RPC và có thể tương tác với nhau trong một thể thống nhất. XML là một ngôn ngữ mô tả văn bản với cấu trúc do người sử dụng định nghĩa. Khi đó. Trong khi HTML định nghĩa thành phần được hiển thị như thế nào thì XML lại định nghĩa những thành phần đó chứa cái gì. các thẻ có thể được lập trình viên tự tạo ra trên mỗi trang web và được chọn là định dạng thông điệp chuẩn bởi tính phổ biến và hiệu quả mã nguồn mở.1.0" encoding = “UTF-8” ?> 19 . nó được sử dụng để định nghĩa các thành phần dữ liệu trên trang web và cho những tài liệu B2B. Do Web Service là sự kết hợp của nhiều thành phần khác nhau nên nó sử dụng các tính năng và đặc trưng của các thành phần đó để giao tiếp. XML . tất cả dữ liệu sẽ được chuyển sang định dạng thẻ XML.3. Ví dụ về tài liệu XML: <?xml version="1.6: Các thành phần của Web service 2. XML hoàn toàn có cấu trúc thẻ giống như ngôn ngữ HTML. Với XML. người sử dụng hay các chương trình có thể quy ước định dạng các tag XML để giao tiếp với nhau.

SOAP là một giao thức để truy cập một Web Service. Tất cả các thông điệp SOAP đều được mã hóa sử dụng XML.2. nên người dùng có thể tạo ra các thẻ bất kì để sử dụng.<DOCUMENT> <GREETING> Xin Chào XML </GREETING> <MESSAGE> Đây là chương trình XML đầu tiên </MESSAGE> </DOCUMENT> Tài liệu XML chỉ chứa dữ liệu. cho nên không bị ràng buộc bởi bất kỳ ngôn ngữ lập trình nào hoặc công nghệ nào. SOAP (Simple Object Access Protocol) Là một giao thức dựa trên XML để cho phép các ứng dụng trao đổi thông tin qua HTTP. không nhắc đến cách trình bày. Hình 2. Tương tự. nó không quan tâm đến công nghệ gì được sử dụng để thực hiện miễn là người dùng sử dụng các message theo định dạng XML.2. Đơn giản. Nó chỉ cần tìm các thẻ và xác định đây là một tài liệu XML hợp lệ vì trình duyệt không cần phải hiểu ý nghĩa của các thẻ. Điều này có ý nghĩa đó là một XML parser. service có thể được thực hiện trong bất kỳ ngôn ngữ nào. miễn là nó có thể xử lý được những message theo định dạng XML. 20 .7: Mô hình gửi nhận thông điệp qua SOAP Bộ khung của một thông điệp SOAP bao gồm: Protocol Header: Cho biết thông tin về các chuẩn giao thức được sử dụng.3. một giao thức truyền thông hay một định dạng để gửi tin nhắn. được thiết kế đơn giản và dễ mở rộng. Vì những đặc trưng này. 2. không cần phải hiểu ý nghĩa của các thẻ.

8: Cấu trúc của một SOAP message Ví dụ: <?xml version="1.. 21 .0"?> <soap:Envelope xmlns:soap="http://www.. <soap:Fault> . Ngoài ra còn có trường lỗi được dùng để gởi các web service exception.org/2001/12/soapenvelope" soap:encodingStyle="http://www.. SOAP body: Thông tin về name và data được đặc tả dưới dạng XML.w3.- SOAP Envelop: Phần chính của thông điệp.. Hình 2..org/2001/12/soapencoding"> <soap:Header> .. Thông tin chính của message bao gồm: • • SOAP Header: Chứa các SOAP header.w3. </soap:Header> <soap:Body> .

Cả hai phần này sẽ được lưu trong 2 tập tin XML: • • Tập tin giao diện service (cho phần 1). Một WSDL hợp lệ gồm hai phần: • Phần giao diện: mô tả giao diện và giao thức kết nối. WSDL là một chuẩn của W3C.</soap:Fault> </soap:Body> </soap:Envelope> 2. tham số.3. WSDL định nghĩa cách mô tả Web Service theo cú pháp tổng quát của XML. • Loại thông tin: thao tác. 22 . bao gồm các thông tin: • Tên dịch vụ. Nó cung cấp một cách thức chuẩn để mô tả các kiểu dữ liệu được truyền trong các thông điệp thông qua Web Service. WSDL được dùng để mô tả các Web Service . • Phần thi hành: mô tả thông tin để truy xuất service. • Giao thức và kiểu mã hóa sẽ được sử dụng khi gọi các hàm của Web Service. các hoạt động được thực hiện trên các thông điệp và ánh xạ các hoạt động này đến giao thức vận chuyển. WSDL (Web Service Discription Language) WSDL là một ngôn ngữ dựa trên XML dùng để mô tả giao diện của Web Service.2. WSDL được dùng để xác định vị trí Web Service. những kiểu dữ liệu (có thể là giao diện của Web Service cộng với tên cho giao diện này).3. Tập tin thi hành service (cho phần 2). • • • • WSDL dựa trên XML.

. 23 ..9: Cấu trúc WSDL  Tập tin giao diện .Hình 2.Service Interface Một tài liệu WSDL mô tả một Web Service gồm các thành phần chính: Element <types> <message> <portType> <binding> Defines Các kiểu dữ liệu được sử dụng bởi các Web Service Các thông điệp được sử dụng bởi các Web Service Các hoạt động được thực hiện bởi các Web Service Các giao thức truyền thông được sử dụng bởi các Web Service Cấu trúc một tài liệu WSDL sẽ như sau: <definitions> <types> definition of types </types> <message> definition of a message </message> <portType> definition of a port </portType> <binding> definition of a binding..

.. và các yếu tố một dịch vụ mà làm cho nó nhóm lại với nhau để có thể định nghĩa của một số Web Service trong một tài liệu WSDL.  Tập tin thi hành . Dịch vụ (Service) Thực hiện những gì đã được định nghĩa trong tập tin giao diện và cách gọi web services theo thủ tục và phương thức nào đó: <wsdl: definitions . như thành phần mở rộng....... Giao diện của một Web Service được miêu tả trong phần này đưa ra cách thức làm thế nào để giao tiếp qua Web Service. nó định nghĩa như một tập hợp của binding và một địa chỉ mạng... > <wsdl: port name="nmtoken" binding="qname"> </wsdl: port> </wsdl: service> </wsdl: definitions> Ở đây chúng ta thấy rằng thuộc tính kết hợp tên là qname. > <wsdl: service .Service Implementation WSDL mô tả 2 loại thông tin chính bao gồm : service và port. > <wsdl: service name="nmtoken"> <wsdl: port .. Một cổng chứa đựng chính xác một địa chỉ mạng. Tên.</binding> </definitions> Một tài liệu WSDL cũng có thể có các yếu tố khác. <wsdl: definitions . Nó tham chiếu tới một mối kết hợp. 24 . bất kỳ cổng nào trong phần thi hành phải tương ứng chính xác với một tham chiếu trong phần giao diện.. giao thức liên kết và định dạng thông điệp yêu cầu để tương tác với Web Service được đưa vào thư mục của WSDL. /> </wsdl: service> </wsdl: definitions> Port Là một cổng đầu cuối.

Định nghĩa cơ bản của Web 25 . UDDI (Universal Description. Trên đây là mô tả bộ chuẩn công nghiệp mà Web Service sử dụng để triển khai mô hình hoạt động theo tư duy SOA. IBM đặc điểm của bộ đăng ký này là nó phân tán về mặt vật lý. ghi nhận thông tin về cách sử dụng và biết được đối tượng nào cung cấp dịch vụ. • UDDI truyền qua SOAP. Những thông tin về Web Service được sử dụng và công bố lên mạng sử dụng giao thức này. SOA và Web Service có vẻ giống nhau nhưng chúng không phải là một. 2.2. • UDDI là một thư mục để lưu trữ các thông tin về các Web Service. UDDI cung cấp một khung ứng dụng về các nghiệp vụ để xuất bản một Web Service. • UDDI được xây dựng trên Microsoft NET. Để có thể sử dụng các dịch vụ. khám phá các Web Service hiện hữu và xây dựng các đăng ký dịch vụ chung.4. • IBM Test Registry: bộ đăng ký cho những người phát triển để thử nghiệm công nghệ và kiểm tra những service của họ. • UDDI là một thư mục của các Web Service giao diện mô tả bởi WSDL. Discovery and Integration) UDDI là một dịch vụ thư mục nơi mà các công ty có thể đăng ký và tìm kiếm các Web Service.3.WSDL thường được sử dụng kết hợp với XML schema và SOAP để cung cấp Web Service qua Internet. UDDI định nghĩa một số thành phần cho biết các thông tin này. Những UDDI registry hiện có: • UDDI Business Registry: bộ đăng ký được bảo trì bởi Microsoft. Một client khi kết nối tới Web Service có thể đọc WSDL để xác định những chức năng sẵn có trên server. Sau đó. cho phép các client truy tìm và nhận những thông tin được yêu cầu khi sử dụng Web Service. • Private registries IBM ships: bộ đăng ký UDDI cá nhân. Nó sẽ kích hoạt các ứng dụng để tìm kiếm thông tin của Web Service khác nhằm xác định xem dịch vụ nào sẽ cần đến nó. client có thể sử dụng SOAP để lấy ra chức năng chính xác có trong WSDL. Thoạt nhìn. trước tiên client phải tìm dịch vụ.

theo định nghĩa thì Web Service là đặc tả công nghệ còn SOA là triết lý thiết kế phần mềm. 2. Rõ ràng. Theo thời gian. hiệu quả là giai đoạn quan trọng và đầu tiên trong một giải pháp hướng dịch vụ . Từ mô hình tính toán tập trung (mainframe) sang mô hình phân tán client/server. SOA và Web Service có mối quan hệ tương hỗ: sự phổ biến của Web Service giúp thúc đẩy sự phát triển của SOA.1. Tuy vậy.Service dựa trên các công nghệ XML. Chúng ta đang ở thời kỳ quá độ sang mô hình tính toán dựa trên dịch vụ là kiến trúc hướng dịch vụ (SOA). 26 .3. Thách thức khi xây dựng hệ thống Cũng như các phương pháp phát triển phần mềm khác. hiệu quả hơn hay ổn định hơn. WSDL. rồi sau đó là kiến trúc dựa trên nền tảng Web.3. để xây dựng được một ứng dụng hướng dịch vụ cũng phải trải qua các giai đoạn tương tự. các công nghệ này có thể hoàn thiện hay có thể được thay bằng công nghệ khác tốt hơn. dù những lợi ích đạt được từ hệ thống SOA là rất lớn nhưng việc triển khai một hệ thống SOA không phải là điều dễ dàng. Tuy vậy. Và ngày nay quá trình này vẫn tiếp tục. Nhưng để xây dựng và triển khai được hệ thống SOA thì vẫn phải gặp một số vấn đề trở ngại: Xác định dịch vụ • Dịch vụ là gì?chức năng nghiệp vụ nào cần được cung cấp bởi một dịch vụ? Độ mịn(granularity) của một dịch vụ thế nào là tốt? • Việc xác định dịch vụ và quyết định đối tượng cung cấp dịch vụ một cách thích hợp. Qui trình xây dựng hệ thống SOA 2. nhưng SOA cũng có thể thực hiện với các giải pháp kỹ thuật khác không phải Web Service (và không phải tất cả Web Service đều có kiến trúc SOA).Trong thực tế nhiều chức năng nghiệp vụ tương tự nhau có thể được cung cấp bởi nhiều hệ thống trong một tổ chức. Kiến trúc này ngày nay cũng đã và đang áp dụng và phát triển cho nhiều doanh nghiệp trên thế giới. UDDI và SOAP cho phép xây dựng các giải pháp lập trình cho vấn đề tích hợp ứng dụng và truyền thông điệp. và kiến trúc tốt của SOA sẽ giúp Web Service thành công. Web Service đưa ra giải pháp kỹ thuật để thực hiện SOA.

các thông tin này cần được chia sẻ và phân bố trong nhiều ứng dụng khác nhau.Các đối tượng này được lưu và quản lí trong hệ thống.Tuy nhiên các hệ thống cũ này trước đây được xây dựng theo mô hình kín. khi được tích hợp. • Nếu hệ thống khi được thiết kế đã quan tâm và hỗ trợ vấn đề tích hợp với các hệ thống mới thì vấn đề này sẽ dễ dàng hơn. điều khiển truy cập(access control).Vị trí của các thực thể này cũng là vị trí tốt nhất để đặt dịch vụ. - Đóng gói dịch vụ: • Làm sao có thể bao bọc các chức năng sẵn có của hệ thống cũ vào trong một dịch vụ.Tuy nhiên bởi đặc tính của hệ là phân tán nên các đối tượng này phân bố rải rác ở nhiều vị trí và có thể một đối tượng được quản lí ở nhiều nơi.Việc định nghĩa các miền như thế cũng ảnh hưởng đến nhiều khía cạnh khác của kiến trúc hệ thống như cân bằng tải(load balancing). - Xác định miền dịch vụ: • Làm sao gom nhóm các dịch vụ thành các miền luận lý(logic domain) • Việc phân loại gom nhóm các dịch vụ thành các miền luận lý sẽ đơn giản hóa kiến trúc bởi sẽ giảm được số lượng các thành phần cần xây dựng. đóng gói trong đó chứa toàn bộ các thông tin về nguyên tắc và qui trình xử lý thì nay.Trong môi trường như thế thì dịch vụ sẽ được đặt ở đâu.- Phân bổ dịch vụ : • • Ta nên đặt dịch vụ ở vị trí nào trong hệ thống? Các dịch vụ thường hoạt động dựa trên các thực thể nghiệp vụ. sự phân chia theo chiều sâu hay chiều rộng của xử lý nghiệp vụ.Vì vậy đồng bộ dữ liệu giữa các hệ thống trở nên là một yêu cầu quan trọng. - Kết hợp các dịch vụ: 27 .

Nhu cầu kết hợp nhiều dịch vụ để đáp ứng được yêu cầu phức tạp từ đối tượng sử dụng là có thực.3. - Định tuyến dịch vụ: • Làm sao để chuyển một yêu cầu từ một đối tượng sử dụng dịch vụ đến dịch vụ hay miền dịch vụ thích hợp? • Một hệ thống SOA phải có tính độc lập địa chỉ cho đối tượng sử dụng các service của hệ thống. xây dựng. việc tạo. Triển khai và Quản lý.2. 28 . 2. theo những qui trình với những rằng buộc phức tạp.Ngoài ra còn phải quan tâm đến vấn đề hiệu suất hoạt động của hệ thống vì việc định vị một dịch vụ là một quá trình cũng chiếm mất nhiều thời gian - Quản lý dịch vụ: • Vấn đề quản lý và bảo trì các dịch vụ. theo dõi và thay đổi các dịch vụ như thế nào cho có hiệu quả? • Làm sao để lựa chọn một chuẩn định dạng thông điệp trao đổi giữa các chuẩn? Làm sao có thể xây dựng một chuẩn định dạng dữ liệu mà mọi hệ thống đều có khả năng hiểu và xử lý? Ngoài các khó khăn trên mỗi tổ chức với mỗi đặc thù riêng của mình có thể sẽ phải đối diện với các ấn đề khác trong quá trình triển khai hệ thống. Vấn đề là làm sao kết hợp các dịch vụ này một cách hiệu quả. Vòng đời của hệ thống Hình vẽ dưới đây mô tả tổng quát các giai đoạn trong chu trình sống của một hệ thống SOA. Lắp ghép. Trong đó qui trình hệ thống đi qua 4 giai đoạn chính: Mô hình hóa. Các giai đoạn này đều dựa trên nền tảng của việc Quản trị và các thực nghiệm.• • Làm sao để có thể tạo ra các dịch vụ tổng hợp.

10: Vòng đời hệ thống SOA Pha Model . Mô hình hóa và mô phỏng hệ thống. Ở pha này.Hình 2. Giám sát các số liệu nghiệp vụ - Governance and best practice – Quản trị và các trải nghiệm thực tế: Đây là công việc xuyên suốt trong cả qui trình vòng đời hệ thống. 29 .mô hình hóa và thiết kế. Thiết kế từng dịch vụ ở mức cơ sở Pha Assemble – Lắp ráp các dịch vụ • • • Khai thác Xây dựng và thử nghiệm Tổ hợp các dịch vụ - Pha Deploy – Triển khai • • • Tích hợp các nguồn nhân lực Tích hợp các tiến trình Quản lý và tích hợp thông tin. - Pha Manage – Quản lí • • • Quản trị các ứng dụng và các dịch vụ Quản lí sự đồng nhất và tính tuân thủ. cần tập trung vào những mục tiêu chính như sau: • • • Thu thập các yêu cầu sử dụng dịch vụ.

3.• • • Tính toán về tài chính Sắp xếp nghiệp vụ/công nghệ thông tin Điều khiển các tiến trình Các thông tin thu thập được trong pha Manage sẽ được cung cấp trở lại qui trình phát triển và giúp cải thiện quá trình xây dựng hệ thống. Các pha cơ bản xây dựng hệ thống SOA Xây dựng hệ thống SOA trải qua 6 pha sau đây: Hình 2. Trong bước này là giai đoạn xây dựng thực tế. không quan tâm tới nó là loại dịch vụ nào. Ở đây vấn đề về nền tảng phát triển đi vào hoạt động.3. Một cách 30 . bao gồm hệ thống SOA sơ bộ. Bước 2: Thiết kế hướng dịch vụ (service-oriented design).11: Các bước cơ bản trong xây dựng hệ thống SOA Bước 1: Phân tích hướng dịch vụ (Service-oriented analysis). làm cho hệ thống hoàn chỉnh hơn. Trong pha này. Hệ thống gồm những dịch vụ nào? Tầng dịch vụ là được lược đồ hóa ra (mapped out). và chia dịch vụ ra thành các mô hình. Có nghĩa. làm cho người thiết kế dịch vụ phải đương đầu với giải quyết vấn đề then chốt đó là thiết lập nên những ranh giới thông qua các dịch vụ. qui trình là một vòng lặp cho tới khi hệ thống hoàn chỉnh theo nhu cầu thay đổi của doanh nghiệp và khách hàng. Đây là giai đoạn đầu để quyết định phạm vi của hệ thống SOA. Đây là giai đoạn có sự kết hợp chặt chẽ về sự thỏa hiệp của doanh nghiệp và nguyên lý hướng dịch vụ thành quy trình thiết kế dịch vụ. Các tầng dịch vụ là được thiết kế trong giai đoạn này có thể bao gồm tầng orchestrantion. 2. các kết quả của nó là trong sự xác định quy trình nghiệp vụ hình thức. Bước 3: Phát triển dịch vụ (Service development).

Các chiến lược xây dựng hệ thống Nhìn chung có hai phương pháp chính để xây dựng một hệ thống SOA. Cách thứ hai là xây dựng SOA dựa vào một bộ thư viện hay một nền tảng có sẵn. Bước 6: Quản trị dịch vụ (Service administration). chúng ta sẽ có được nhiều cái lợi như: thời gian phát triển và triển khai nhanh. Mỗi cách đều có những ưu nhược điểm riêng. vấn đề quản lý các ứng dụng trở thành hàng đầu. và các ứng dụng dựa trên các thành phần (component-based applications). top-down là chiến lược lấy xuất phát điểm là các yêu cầu ngiệp vụ. và việc xem xét chúng như các dịch vụ trong một tổng thể. bởi các hệ thống SOA thoạt nhìn bên ngoài rất đơn giản nhưng lại rất phức tạp ở bên trong. Cách đầu tiên là tự tay xây dựng từ đầu hệ thống theo mô hình SOA. sau đó xác định các yêu cầu chức năng. Bước 4: Kiểm thử dịch vụ (Service testing). Bước 5: Triển khai dịch vụ (Service deployment).4. là sự lựa chọn ngôn ngữ lập trình và môi trường phát triển sẽ quyết định những mẫu dịch vụ và quy trình nghiệp vụ orchestrantion nào phù hợp với thiết kế. nếu xây dựng SOA từ nền tảng có sẵn. các dịch vụ là được yêu cầu trải qua được sự nghiêm ngặt của việc kiểm thử trước khi được triển khai thành các sản phẩm.3. mối quan tâm cho hệ thống phân tán. được hỗ trợ tốt hơn. 2. các tiến 31 . Bù lại chúng ta sẽ không thể tự do chỉnh sửa và thay đổi theo ý muốn. Chiến lược top-down Trong xây dựng một hệ thống SOA. Nếu chúng ta tự tay xây dựng ngay từ đầu thì có thể dễ dàng kiểm soát và tối ưu nó. Để đưa ra những tiềm năng cho việc dùng lại và bao gồm cả những trạng thái không biết trước được. nhân lực và tiền bạc thì may ra mới có thể xây dựng được một hệ thống SOA hoàn chỉnh. 2. tuy nhiên chúng ta sẽ phải tốn rất nhiều thời gian. Giai đoạn thực thi này đưa đến việc cài đặt và cấu hình cho các thành phần phân tán.1. Sau khi các dịch vụ được triển khai. các giao diện dịch vụ.3. và nhiều sản phẩm trung gian (middleware products) kết hợp với nhau thành những server.cụ thể. Ngược lại.4.

các dịch vụ. Hình 2. Các kết quả này là các từ vựng phổ biến. phân loại các tập thông tin được xử lý bởi các cơ cấu tổ chức của hệ thống. Chiến lược này phổ biến để tạo ra những kiến trúc dịch vụ có chất lượng cao. của hệ thống. theo mỗi cách quản lý thì các nghiệp vụ chia ra một cách rõ ràng. trong quá trình tạo ra nhiều những nghiệp vụ được sử dụng lại và các dịch vụ ứng dụng khác. thì tại bước này nó sẽ được định nghĩa.12: Tiếp cận Top-down xây dựng hệ thống Chiến lược top-down hỗ trợ tạo ra các bước để hình thành tầng dịch vụ (service layers).. Một số lượng đáng kể các tập thông tin trước và kết quả phân tích nghiệp vụ ở mức cao có thể được yêu cầu.13: Các bước xây dựng hệ thống theo chiến lược top-down. như sự định nghĩa mối quan hệ giữa các tập thông tin này với tập thông tin khác là như thế nào. Bước 1: Define relevant ontology.trình nghiệp vụ và các tiến trình con. Các tổ chức có phạm vi rộng lớn hơn cùng với nhiều phạm vi nghiệp vụ có thể có vài ontology. Hình 2.. Nếu có nhiều từ vựng nghiệp vụ không tồn tại cho bất cứ các tập thông tin nào mà một giải pháp được yêu cầu thực hiện. các trường hợp sử dụng (use cases) và đi tới xác định các thành phần. Bước này là để xác định. 32 .

Đồng thời. Bước 5: Develop services Phát triển các dịch vụ theo yêu cầu.2. 2. Bước 3: Perform service-oriented analysis Xác định các dịch vụ và hướng tiếp cận cho các dịch vụ. mô hình hóa các dịch vụ. các dịch vụ sử dụng lại có thể mở rộng năng lực xử lý và cần có sự bảo mật. Các dịch vụ được phát triển theo những bản thiết kế kỹ thuật tương ứng với các đặc tả dịch vụ được tạo ra ở bước 4.3. Để tạo điều kiện cho nhiều người yêu cầu dịch vụ.4. sự tồn tại các mô hình nghiệp vụ có thể cần thay đổi (hay tạo ra) để thể hiện các từ vựng bằng cách cung cấp ontology trong các thuật ngữ mô hình nghiệp vụ. 33 . Các dịch vụ vượt qua được sự kiểm tra coi như đạt chất lượng và có thể tái sử dụng sau này. các tài nguyên có sẵn của hệ thống hiện có và tái sử dụng lại những thành phần này trong việc xây dựng các dịch vụ mới. Chiến lược bottom-up Chiến lược này dựa trên việc phân tích tình trạng. Sau khi có được các dịch vụ từ những thành phần đó. Bước 4: Perform service-oriented design Thực hiện thiết kế hướng dịch vụ. Mô hình thực thể chi tiết rất quan trọng. Bước 7: Deploy service Quan tâm tới vấn đề thực thi. xác định tiềm năng tương lai sử dụng lại của dịch vụ. ta có thể cải tiến chất lượng dịch vụ hoặc tổ hợp các dịch vụ lại để tạo ra những dịch vụ cao cấp hơn hay còn gọi là các dịch vụ tổ hợp.- Bước 2: Align relevant business models (including entity models) Sau khi ontology được thiết lập. cần phải cung cấp cả khả năng truy cập cho dịch vụ. Bước 6: Test service operations Giai đoạn kiểm thử được yêu cầu cho tất cả quá trình hoạt động của dịch vụ và quá trình kiểm tra phải thực hiện đảm bảo chất lượng.

Hình 2. Các dịch vụ ứng dụng cũng sẽ được mô hình hóa bao gồm các logic và quy tắc cho nghiệp vụ cụ thể. Các dich vụ có thể cung cấp thêm vào cho thiết kế. Hình 2. bao gồm có các dịch vụ tiện ích và nhân bản. Các dịch vụ ứng dụng tùy chọn sẽ cần đưa qua quá trình thiết kế. Các yêu cầu phổ biến khác sẽ dần xuất hiện để thay công nghệ truyền thông truyền thống bằng những framework truyền thông điệp SOAP. giống như hai tầng dịch vụ ứng dụng. ta thừa nhận các yêu cầu nghiệp vụ đã tồn tại.14: Tiếp cận Bottom-up xây dựng hệ thống Trong hướng tiếp cận này. Bước 1: Model application services Kết quả của giai đoạn này là sự định nghĩa của các yêu cầu ứng dụng được thỏa mãn thông qua việc sử dụng Web service. Bước 2: Design applicaion services Một vài các dịch vụ ứng dụng được mô hình hóa trong bước 1 có thể được trình bày thành bản thiết kế.15: Các bước xây dựng hệ thống theo chiến lược bottom-up. Các yêu cầu này bao gồm những thiết lập lên các kênh tích hợp point-to-point giữa hệ thống cũ (legacy system) hoặc giải pháp B2B (Business-to-Business). Trường hợp này. ở một khía cạnh 34 .

môi trường kết hợp của chúng.nào đó thì tồn tại những chuẩn thiết kế được áp dụng để đảm bảo mức độ bền vững. 35 . Và cả hai chiến lược xây dựng hệ thống top-down và bottom-up đều được áp dụng rộng rãi. Sự cân nhắc thực thi cho các dịch vụ ứng dụng thường bao gồm sự thực thi và các yêu cầu bảo mật. Kiểm tra bảo mật cũng là phần quan trọng của giai đoạn này. Còn hầu hết những hệ thống lớn hiện nay đi vào xây dựng đều theo định hướng SOA và áp dụng chiến lược top-down. Bước 3: Deploy application service Các dịch vụ ứng dụng được phát triển theo sự mô tả dịch vụ và bản thiết kế chi tiết ứng dụng. Một số hệ thống cũ muốn nâng cấp hay tích hợp thêm một số dịch vụ hoặc tổ hợp lại với nhau thành một hệ thống lớn thường sử dụng chiến lược bottom-up để tận dụng cơ sở hạ tầng có sẵn và tiết kiệm chi phí. Bước 5: Deploy services Những giải pháp và các dịch vụ ứng dụng của nó sẽ triển khai thành sản phẩm. Sự thực thi và tiêu chuẩn kiểm thử được nhấn mạnh thường là thiết lập lên các tham số cho hệ thống cũ thông qua các dịch vụ. Bước 4: Test service Các dịch vụ. Tùy vào từng hệ thống mà việc xây dựng kiến trúc hướng dịch vụ có thể sử dụng chiến lược phù hợp. nhằm mục đích đảm bảo khả năng mở rộng và thường xuyên thay đổi các yêu cầu với hệ thống. Hiện xu thế SOA đang phát triển rất mạnh. và logic của những hệ thống cũ sẽ được kiểm tra để đảm bảo chắc chắn rằng xử lý các yêu cầu là phù hợp.

#Ngay.CHƯƠNG 3: KẾT QUẢ VÀ THẢO LUẬN 3. Sql Server 2005 xây dựng Web Service. Xây dựng giao diện website gọi dịch vụ. Mota): cung cấp thông tin thời tiết các địa điểm. Chương trình demo Sử dụng công cụ: Visual studio 2008. TenTTP): cung cấp mã và tên các địa điểm trên cả nước. Nhietdo.1.1. Xây dựng dịch vụ phía nhà cung cấp(Service Provider) Dữ liệu của dịch vụ: Gồm 2 bảng dữ liệu: TinhThanhPho(#MaTTP. Xây dựng chương trình a.2. Tái sử dụng dịch vụ: Sử dụng giao diện gọi dịch vụ để lấy thông tin thời tiết các vùng miền của USA từ nhà cung cấp khác: http://www.asmx?WSDL 3. 36 . ThoiTiet(#MaTTP. 3.1.webservicex. Chức năng chính của chương trình: Xây dựng Web Service cung cấp thông tin thời tiết các tỉnh thành phố và vùng miền trong cả nước.1.net/WeatherForecast. đọc thông tin dạng XML trả về của dịch vụ và hiển thị thông tin.

Web. nhập vào mã tỉnh thành phố: 37 .- Mô tả dịch vụ: dịch vụ chứa một phương thức lấy input là mã tỉnh thành phố và trả về output là một đối tượng có các thuộc tính là thông tin thời tiết của tỉnh thành phố đó: public class ThoiTiet_TinhTP : System.asmx?WSDL - Chọn phương thức GetWeatherInfor.WebService { [WebMethod] public WeatherData GetWeatherInfor(string matinh){ } } - Publish dịch vụ trên localhost: IIS tự động sinh địa chỉ cổng cho dịch vụ: http://localhost:2359/WS_DuBaoThoiTiet/ThoiTiet_TinhTP.Services.

Xây dựng giao diện sử dụng dịch vụ (Service Consumer) Xây dưng giao diện website cho việc gọi dịch vụ và hiển thị kết quả trả về như sau: 38 .- Kết quả: thông tin của đối tượng WeatherData được chuyển đổi sang dạng XML b.

Thực hiện bằng cách thêm vào thêm một đường dẫn tham chiếu tới địa chỉ của Web service đã được public: http://localhost:2359/WS_DuBaoThoiTiet/ThoiTiet_TinhTP. ta phải tìm kiếm và đăng ký.- Để sử dụng được Web Service đã xây dựng.asmx?WSDL - Nhập mã tỉnh thành phố: - Kết quả: 39 .

nhập vào PlaceName.asmx?WSDL Tương tự ta thực hiện Add Web referrence là địa chỉ tìm kiếm dịch vụ: - Trên giao diện gọi dịch vụ.- Sử dụng dịch vụ từ một nhà cung cấp khác: http://www.webservicex.net/WeatherForecast. Kết quả trả về: 40 .

đăng ký dịch vụ. phân quyền…). các tiến trình nghiệp vụ và các vấn đề khác trong xây dựng hệ thống vẫn chưa được đề cập tới (tạo các tài liệu mô tả dịc vụ. xây dựng một hệ thống hoàn chỉnh theo tư tưởng SOA là quá trình rất phức tạp và đòi hỏi nhiều về kiến thức cũng như kinh nghiệm thực tế không chỉ về công nghệ thông tin mà còn là quản lý nghiệp vụ. 41 .3. Đánh giá chương trình Chương trình đã mô tả được cách thức sử dụng web service: Tạo ra một dịch vụ Sử dụng dịch vụ đã xây dựng Tái sử dụng một dịch vụ được cung cấp sẵn Chương trình chủ yếu tập trung vào mục đích đưa ra một giải pháp công nghệ chứ chưa quan tâm nhiều tới khía cạnh xử lý nghiệp vụ. Thực tế. nguồn nhân lực và tài nguyên của hệ thống… Phạm vi của đề tài chưa thể giải quyết hết các vấn đề. xử lý xác thực.2.

Trong khi SOA đã và đang làm kiến trúc ưu việt cho phát triển ứng dụng công nghệ thông tin trong giai đoạn hiện nay thì việc nghiên cứu để có thể áp dụng triết lý này cho các hệ thống phần mềm là một việc cần thiết. bài báo cáo chưa giải quyết được hết mọi góc cạnh của vấn đề. hãy kết hợp những linh kiện (dịch vụ) có sẵn và bổ sung những gì cần thiết để lắp ráp nhanh chóng chiếc xe đưa bạn đến đích!”. do kĩ năng nghiên cứu và kiến thức còn hạn chế. em sẽ tiếp tục nghiên cứu để tìm hiểu sâu hơn các vấn đề về SOA như: sử dụng một số công cụ hỗ trợ để định nghĩa và xây dựng dịch vụ. “Đừng tốn công chế tạo lại bánh xe.KẾT LUẬN SOA sẽ giúp cho công việc phát triển phần mềm trở nên dễ dàng và nhanh chóng hơn. Trong thời gian tới. Nguyễn Thị Dung 42 . Trong quá trình nghiên cứu đề tài. Sau quá trình nghiên cứu. cách thức đăng ký một Web Service với Service Broker. Em mong nhận được sự đóng góp của thầy cô để đề tài hoàn thiện hơn. đề tài của em đã đạt được một số kết quả sau: Hiểu và đưa ra được khái niệm và các vấn đề liên quan tới kiến trúc hướng dịch vụ SOA Ứng dụng công nghệ Web Service trong triển khai tư tưởng SOA Qui trình và các hướng tiếp cận phát triển ứng dụng theo hướng dịch vụ Xây dựng chương trình demo về Web Service Tuy nhiên. các kết quả tìm hiểu còn rất tổng quan. chương trình xây dựng chỉ mang tính mô phỏng nên còn khá đơn giản. các giải pháp bảo mật cho hệ thống SOA… Em xin chân thành cảm ơn! SV. Đó là triết lý của SOA.

Nghiên cứu về kiến trúc hướng dịch vụ và ứng dụng.TÀI LIỆU THAM KHẢO 1. Understanding SOA SecurityDesign and Implementation. Pattern: Service-Oriented Architecture and Web Services.vn/showthread.Luận văn cử nhân tin học khoa CNTT – ĐH KHTN Tp. 8.edu. 6. Douglas K. Loạt bài về SOA program model.html http://www. Barry (2003).networkworld. 7.0 http://www. 9.com. IBM Red Book Team (2007). Các bài viết liên quan: http://en. Ramarao Kanneganti.HCM.org/wiki/Service-oriented_architecture http://vovanhai. Nguyễn Trọng Dũng Trường ĐHSP Hà Nội. 3. IBM Red Book Team (2004).com/developerworks/vn/library/ws-soa-progmodel . .aspx http://www.com/news/2009/031209-soa-security-the. Hồ Bảo Thanh & Nguyễn Hoàng Long (2005) .php?t=2248 43 .php?topic=301. 5.ibm.phpvn.com. Phát triển Web Service với các công nghệ chuẩn của java.wikipedia. Kris Jamsa (2003).NET Web Services Solutions Sybex © 2003.erpsolution.vn/content/m18879/latest/ http://www. Ths.wordpress. 4.org/index. http://www. IBM Red Book Team (2004). Prasad Chodavarapu (2007). Web Services and Service-Oriented Architecture: The Savvy Manager's Guide. 2. 11. Systinet. Pattern: Implementing an SOA using Enterprise Service Bus.com/web-services/c-web-services/t%E1%BA %A1o-web-service-v%E1%BB%9Bi-c-step-by-step http://voer. SOA Security.quantrimang.vn/doanhnghiep/doanh-nghiep/58175_Xuhuong-ung-dung-SOA-o-Chau-A. A Practical Guide to SOA for IT Management 10.

vn/articles/quan-ly/nguonluc/2009/06/1194174/kien-truc-huong-dich-vu-soa-khong-con-la-khai-niem/ 44 .com.http://www.pcworld.

CHỮ KÝ XÁC NHẬN Ngày 15 tháng 12 năm 2010 Chủ nhiệm đề tài ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… ………………………………………… Ngày 15 tháng 12 năm 2010 Giáo viên hướng dẫn ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… ……………………………………… 45 .