ĐẠ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

và EJB. bao gồm cả trường hợp cả 2 bên không sử dụng ngôn ngữ Java. Kiến trúc phần mềm hiện nay 1. 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. 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. 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. cho phép gọi các phương thức từ xa và nhận kết quả trả về. 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.CHƯƠNG 1: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED-ARCHITECTURE) 1. 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. 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. 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. RMI. nhưng không giống như RMI. CORBA (Common Object Request Broker Architecture) Là một chuẩn công nghiệp được đưa ra bởi OMG (Object Management Group). DCOM. Đối tượng có thể có không gian địa chỉ bên ngoài ứng dụng. 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.1.1. Ư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ó.

phục vụ yêu cầu khách hàng tốt hơ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 . 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. nền tảng phần cứng. 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. đáp ứng tốt các thay đổi thường xuyên về nghiệp vụ. 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. khó học và cần một đội ngũ phát triển có kinh nghiệm. Vấn đề phát sinh. 1. Tuy nhiên CORBA có nhược điểm là nó là ngôn ngữ lập trình cấp thấp. 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. chi phí thấp. 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. được gọi là IIOP (Internet Interoperability Protocol). Tuy nhiên. Một giao thức được ORB dùng để liên lạc giữa nhiều tiến trình. Ngoài ra các đối tượng CORBA khó tái sử dụng. Các ứng dụng dựa trên CORBA hiện nay đang dần đi vào thoái trào. khai thác có hiệu quả các công nghệ có sẵn. Hình 1. DCOM (Distributed Component Object Model) DCOM là công nghệ độc quyền của Microsoft. 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.ORB).1: Mô hình tương tác của các đối tượng DCOM. quản lý kết nối hiệu quả và dễ mở rộng. khả năng tích hợp cao với các hệ thống bên ngoài… 3 . tính ổn định. DCOM mang đến nhiều ưu điểm như: dễ triển khai.1. Ư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.2. rất phức tạp. không phụ thuộc vào địa lý.

- - 4 . Đ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à bảo mật ngày càng cao đã làm gia tăng tính phức tạp cho hệ thống. 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. và hoạt động nghiệp vụ khác nhau. khó kết hợp hoạt động.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. tích hợp cùng với nhau. Không linh hoạt: Cùng với sự phức tạp trong chiến lược phát triển. cũng như cơ sở hạ tầng của các công ty. Vấn đề an ninh bảo mậ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. có khả năng trên các lĩnh vực khác nhau để phát triển. 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. 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. 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. Thêm đó là việc nâng cấp khó khăn. 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. mà không thể thay thế được. Không bền vững: Tiếp đó là sự không bên vững của hệ thống. tích hợp. Vấn đề tích hợp trở nên khó khăn hơn và tốn kém hơ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.

Mặc dù SOA hoạt động được là nhờ công nghệ. Kiến trúc hướng dịch vụ . Để 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 .2.1. 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ế. 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ệ.SOA 1. đượ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. 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. 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. 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.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.  Dịch vụ (service) là yếu tố then chốt trong SOA. 1. Thay vào đó. “Kiến trúc hướng dịch vụ” (Service Oriented Architecture . 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. Nói một cách ngắn gọn. 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 đó. 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. hay một bộ thư viện nào đó. 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.2. 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. 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. May mắn thay.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. 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. 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ó 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óm lại.với nền tảng hệ thống. các service không truyền các class và type. 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. đã 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. 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.  Share the Schema and Contract. Not the Class: Về mặt trao đổi dữ liệu. 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. 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ụ. Sự trừu tượng là cốt lõi của khái niệm dịch vụ. hoặc tạo một giao thức riêng.  Tính tự trị (Autonomous): Về mặt lý thuyết. Thay vào đó. Thoạt nhìn SOA và Web Service trông có vẻ 6 . các class và type sẽ được đặc tả hình thức (data được đặc tả trong schema.  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). 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. và có thể tái sử dụng. Nhưng từ năm 2001. Như vậy. mỗi service có tính độc lập cao. Chi tiết hiện thực của mỗi service sẽ không được thể hiện ra bên ngoài. behavior được đặc tả thành các contract). 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. 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). 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ề. chẳng hạn dùng các giao thức mạng có sẵn.

2: Mô hình cơ bản của SOA. 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.giống nhau nhưng chúng không phải là một. 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. Chúng ta sẽ tìm hiểu rõ hơn về các Web Service trong các phần tiếp theo.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. Phối hợp tiến trình nghiệp vụ giữa nhiều nhà cung cấp. 7 . 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. Để 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. 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. Dựa trên nguyên lý. 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. Hình 1. 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. nhiều đối tác thậm chí có thể với cả khách hàng. hệ thống SOA có những tính chất cơ bản. 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. - - Nói cách khác.

Mỗi hệ thống có thể tự quản lý độc lập nhằm tăng năng xuất.3.3. 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.2.2. 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. 1. nó còn giúp đơn giản hóa việc quản trị. và ít xảy ra sự cố.1. 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. 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. khả năng mở rộng và khả năng đáp ứng cao. Có 2 loại kết nối là lỏng lẻo và chặt chẽ. 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 . 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ý. Nếu một dịch vụ không có khả năng tái sử dụng. Kết nối lỏng lẻo làm cho sự phụ thuộc ở mức tối thiểu. Những thay đổi cài đặt cúng được che dấu đi. 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. Khi đó.1. 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. 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.3.2. 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. 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. 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ẽ. Tính chất của SOA 1. 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. nó cũng không cần đến giao diện mô tả. Ngược lại. 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.2. Tối thiểu hóa sự phụ thuộc giúp hệ thống linh hoạt. 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. trung chuyển yêu cầu giữa các hệ thống đầu cuối.

2. 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ụ. Ngược lại. một hệ thống chuyển khoản. 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. 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. nếu sử dụng các chính sách. 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. Nếu không sử dụng các chính sách. Bởi vì các chính sách được thiết kế tách biệt. 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.3. Các mục đó chứa thông tin về dịch vụ. 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. Khi sử dụng các dịch vụ chia sẻ trên mạng. bao gồm cả chi phí giao dịch. Registry trả về một tập các danh mục thỏa mãn yêu cầu. 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ụ. 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.4. 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ề. Vậy với 9 .3. 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. Mối ràng buộc này là ràng buộc trong thời gian chạy. 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. Ví dụ. 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.3. 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. 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). 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. 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.hay lớp.2. 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ủ. 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. 1. thì các nhân viên phát triển phần mề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.

3.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. 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ụ. 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.SOA. 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. cũng như địa chỉ dịch vụ cho đến khi cần. 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. Độ 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. 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ì. Trong SOA. Lợi ích về mặt kỹ thuật: 10 . Ngoài ra. 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ề. nên có thể có nhiều cài đặt khác nhau cho cùng một giao diện.5. 1. Độ 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. 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. 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.2. 1. 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. . 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. 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.4.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ế.2. Đâ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). 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. Về mặt kinh tế: .

Ư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. bí mật và toàn vẹn dữ liệu. . Dễ dàng và nhanh chóng tạo ra các tiến trình nghiệp vụ từ các service đã có.2.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.Có khả năng tái sử dụng. 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 đó. .. nâng cấp hoặc mở rộng hệ thống. Khó miêu tả dữ liệu không cấu trúc trong header của message. Tuy nhiên.Cho phép dễ dàng triển khai chương trình. 11 . Khả năng tương tác của các service. 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. 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ể. 1. . Hệ thống phức tạp.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. Đặ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. phân quyền.5.

CHƯƠNG 2: PHÁT TRIỂN PHẦN MỀM DỰA VÀO SOA 2.. resource sử dụng. - 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.. Những thông tin này sẽ hỗ trợ thêm cho quá trình tìm kiếm của Service Consumer. Service Registry: Nơi lưu trữ thông tin về các service của các Service Provider khác nhau.1. giá cả dịch vụ. 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.1.1. 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. Mô hình tổng thể của SOA Hình 2. 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ả.).. bầu chọn từ các khách hàng đã sử dụng service. Mô hình hoạt động và kiến trúc chi tiết của hệ thống 2. 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 khi có nhu cầu về một service nào đó sẽ tìm kiếm thông tin trên Service Registry.. Họ chỉ cần quan tâm dịch vụ đó là gì. 12 .. 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ụ.) vào Service Registry.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 đó. performance. Ngoài chức năng hỗ trợ tìm kiếm.. Khi đã xác định được Service Provider mong muốn. khả năng của hệ thống (resource.

đ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). 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. Đ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).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. 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 đó..). SMTP. FTP. Chính nhờ đặc điểm này. • 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..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. Đ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 đó. Hình 2. 13 . • 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.1.2.

• 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. 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. có hành vi gần với những chức năng nghiệp vụ hơn.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 .1. 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. 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. Mỗi một công ty có một mô hình SOA khác nhau.3: Kiến trúc chi tiết của SOA .3. 2. giao tiếp với các ứng dụng khác.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ác web service… Vì vậy có thể coi đây là tầng vật lý của SOA. 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. 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.Tầng Connectivity: đây là tầng thấp nhất của SOA. • 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. . Đ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. Nhìn chung mô hình SOA có các đặc điểm sau: Hình 2.

15 .… Các thành phần khác: gồm có quy trình phát triển (development). portal. các ứng dụng client mở rộng (rich client). 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. 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ư 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ệ. SOA là tư duy hệ thống ưu việt cho giai đoạn công nghệ hiện nay. CORBA. Nếu hệ thống cần việc chạy nhanh cho một ứng dụng đặc biệt thì RMI. Hình 2. con người và quy trình nghiệp vụ. Nhưng hệ thống khó có thể thay đổi hoặc sử dụng lại. và quản lý con người (governance). Tầng này có thể là các website. quản lý các dịch vụ (service management). 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ệ.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. cơ sở hạ tầng. 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.- 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 thiết bị di động thông minh (smart device). DCOM là sự lựa chọn.

..2. Web Service cho phép truy cập thông qua định nghĩa giao thức-và-giao tiếp. các chương trình viết bằng các ngôn ngữ lập trình khác nhau. độc lập ngôn ngữ. 2. Với web service. 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.2.1.2. tên gọi “kiến trúc định hướng giao tiếp” thích hợp hơn cho SOA.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ì triển khai dịch vụ bằng Web service có thể nói là điều “tất nhiên”.2. Và đặc biêt trong quá trình internet hóa mọi dịch vụ hiên nay. Về cơ bản. thường theo cách thức yêu cầu . SMPT.đáp trả. SOA và ứng dụng Web Service 2. giao tiếp bằng cách sử dụng giao thức mở chứa đựng và mô tả chính nó. Đ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. (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. 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. 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. Do đó. Web service hoạt động dựa trên nền tảng là XML và HTTP. 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. Thực ra. 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. 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. 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. Dịch vụ và module phần mềm nghiệp vụ được truy cập thông qua giao tiếp. 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. 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. 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 . hiện thực giao tiếp và phương thức gọi giao tiếp. 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ụ. Giao tiếp là trung tâm của toàn bộ triết lý kiến trúc này.

Các giao thức HTTP là giao thức Internet được sử dụng nhiều nhất. Description.nhau và vẫn thể hiện thông điệp và chức năng phức tạp. 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ý. and Integration (UDDI).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). WSDL: Ngôn ngữ mô tả Web Service theo chuẩn. 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. 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. 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. Hình 2. - 17 . Service Broker: Lưu trữ thông tin về các service được cung cấp bởi các Service Provider. sử dụng một bộ các chuẩn công nghệ. Đó là: XML: Chuẩn định dạng dữ liệu và thông điệp.

Như vậy. Các Web Service đều phải được sử dụng thông qua giao diện này. Đó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. UDDI (Universal Description. 2. SOAP (Simple Object Access Protocol). Ngay sau đó. Bằng việc sử dụng UDDI và chức năng tìm kiếm của Service Broker.2. 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).. WSDL (Web Services Description 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.3. Mọi tương tác với dữ liệu đều phải thông qua Web Service. mức giá . - - 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. 18 .) và gởi cho Service Broker. resource cần thiết.- Service Requester: Dùng WSDL để đặc tả nhu cầu sử dụng (loại service. 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. 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. 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ể. Phần mềm phải cung cấp các kênh giao tiếp (adapter) cho Web service.. 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). thời gian sử dụng. Service Requester có thể tìm thấy Service Provider thích hợp.

1. nhưng không tuân theo một đặc tả quy ước như HTML. Khi đó. Ví dụ về tài liệu XML: <?xml version="1. 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ì. 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. 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. XML hoàn toàn có cấu trúc thẻ giống như ngôn ngữ HTML. 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.Hình 2.eXtensible Markup Language XML là một chuẩn mở do W3C đưa ra và được phát triển từ SGML.0" encoding = “UTF-8” ?> 19 . XML . Với XML.3. 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. Về hình thức. 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ở. 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.6: Các thành phần của Web service 2.2. 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. tất cả dữ liệu sẽ được chuyển sang định dạng thẻ XML.

20 . Đơn giản. Hình 2. một giao thức truyền thông hay một định dạng để gửi tin nhắn. 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 cần phải hiểu ý nghĩa của các thẻ. SOAP là một giao thức để truy cập một Web Service. 2. 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ẻ.<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. Điều này có ý nghĩa đó là một XML parser. miễn là nó có thể xử lý được những message theo định dạng XML. không nhắc đến cách trình bày. service có thể được thực hiện trong bất kỳ ngôn ngữ nào. được thiết kế đơn giản và dễ mở rộng.3. Tương tự. Tất cả các thông điệp SOAP đều được mã hóa sử dụng XML. Vì những đặc trưng này. nên người dùng có thể tạo ra các thẻ bất kì để sử dụng.2. 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.2. 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.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.

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

tham số. 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).3. • Loại thông tin: thao tác. bao gồm các thông tin: • Tên dịch vụ. • Phần thi hành: mô tả thông tin để truy xuất service.2. WSDL định nghĩa cách mô tả Web Service theo cú pháp tổng quát của XML. 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.</soap:Fault> </soap:Body> </soap:Envelope> 2. • 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. WSDL được dùng để mô tả các 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). • • • • WSDL dựa trên XML. WSDL được dùng để xác định vị trí Web Service. 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.3. WSDL là một chuẩn của W3C. Tập tin thi hành service (cho phần 2). 22 . 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. 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.

.9: Cấu trúc WSDL  Tập tin giao diện . 23 ..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..

> <wsdl: service name="nmtoken"> <wsdl: port .. Một cổng chứa đựng chính xác một địa chỉ mạ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. 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 . > <wsdl: service .. 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. 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...Service Implementation WSDL mô tả 2 loại thông tin chính bao gồm : service và port. <wsdl: definitions . /> </wsdl: service> </wsdl: definitions> Port Là một cổng đầu cuối.. Nó tham chiếu tới một mối kết hợp. 24 ....</binding> </definitions> Một tài liệu WSDL cũng có thể có các yếu tố khác..  Tập tin thi hành . Tê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: 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. như thành phần mở rộng. nó định nghĩa như một tập hợp của binding và một địa chỉ mạng...

• UDDI là một thư mục để lưu trữ các thông tin về các Web Service. • UDDI được xây dựng trên Microsoft NET. UDDI định nghĩa một số thành phần cho biết các thông tin này. trước tiên client phải tìm dịch vụ. UDDI cung cấp một khung ứng dụng về các nghiệp vụ để xuất bản một Web Service. 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. • 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ọ. 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. client có thể sử dụng SOAP để lấy ra chức năng chính xác có trong WSDL. khám phá các Web Service hiện hữu và xây dựng các đăng ký dịch vụ chung. IBM đặc điểm của bộ đăng ký này là nó phân tán về mặt vật lý. 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. 2.WSDL thường được sử dụng kết hợp với XML schema và SOAP để cung cấp Web Service qua Internet.2. • UDDI là một thư mục của các Web Service giao diện mô tả bởi WSDL. Thoạt nhìn. Những UDDI registry hiện có: • UDDI Business Registry: bộ đăng ký được bảo trì bởi Microsoft.3.4. SOA và Web Service có vẻ giống nhau nhưng chúng không phải là một. • Private registries IBM ships: bộ đăng ký UDDI cá nhân. 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. 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. Sau đó. 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. Để có thể sử dụng các dịch vụ. Định nghĩa cơ bản của Web 25 . 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ó.

Và ngày nay quá trình này vẫn tiếp tục. 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. 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ụ . Theo thời gian. để 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ự. Tuy vậy.3.Service dựa trên các công nghệ XML. 2.1. 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). 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. Từ mô hình tính toán tập trung (mainframe) sang mô hình phân tán client/server. 26 . WSDL. 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. hiệu quả hơn hay ổn định hơn.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. 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. Rõ ràng. 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). 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. Qui trình xây dựng hệ thống SOA 2. rồi sau đó là kiến trúc dựa trên nền tảng Web. và kiến trúc tốt của SOA sẽ giúp Web Service thành công. Tuy vậy.3. 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. 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. 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. Web Service đưa ra giải pháp kỹ thuật để thực hiện SOA.

• 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.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.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). - Kết hợp các dịch vụ: 27 .Trong môi trường như thế thì dịch vụ sẽ được đặt ở đâu. điều khiển truy cập(access control). - 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. khi được tích hợp.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.Vị trí của các thực thể này cũng là vị trí tốt nhất để đặt dịch vụ. sự phân chia theo chiều sâu hay chiều rộng của xử lý nghiệp vụ.- 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ụ. 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. - Đó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 các hệ thống cũ này trước đây được xây dựng theo mô hình kín. đó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.

việc tạo. 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. xây dựng. 2. - Đị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.2. 28 . 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. Vấn đề là làm sao kết hợp các dịch vụ này một cách hiệu quả. Triển khai và Quản lý. Lắp ghép. 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.3.• • Làm sao để có thể tạo ra các dịch vụ tổng hợp. Trong đó qui trình hệ thống đi qua 4 giai đoạn chính: Mô hình hóa. 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.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 những qui trình với những rằng buộc phức tạp.

29 .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. Mô hình hóa và mô phỏng hệ thống. Ở pha này.mô hình hóa và thiết kế. 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ụ. - 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ủ. 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.10: Vòng đời hệ thống SOA Pha Model .

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. Trong bước này là giai đoạn xây dựng thực tế.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). Bước 3: Phát triển dịch vụ (Service development). Trong pha này.3. các kết quả của nó là trong sự xác định quy trình nghiệp vụ hình thức. 2. Ở đây vấn đề về nền tảng phát triển đi vào hoạt độ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. không quan tâm tới nó là loại dịch vụ nào. làm cho hệ thống hoàn chỉnh hơn.• • • 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. bao gồm hệ thống SOA sơ bộ. Bước 2: Thiết kế hướng dịch vụ (service-oriented design). Một cách 30 . 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. 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ụ. 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. Đâ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ụ. Đây là giai đoạn đầu để quyết định phạm vi của hệ thống SOA.3.

vấn đề quản lý các ứng dụng trở thành hàng đầu.1.4.cụ thể.3. Ngược lại. Bước 5: Triển khai dịch vụ (Service deployment). tuy nhiên chúng ta sẽ phải tốn rất nhiều thời gian. 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ó. 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ác tiến 31 . được hỗ trợ tốt hơn. Mỗi cách đều có những ưu nhược điểm riêng. sau đó xác định các yêu cầu chức năng. Bù lại chúng ta sẽ không thể tự do chỉnh sửa và thay đổi theo ý muốn. 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. 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. 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. các giao diện dịch vụ. 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.4. Bước 6: Quản trị dịch vụ (Service administration). Để đư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. 2. 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ụ.3. 2. nếu xây dựng SOA từ nền tảng có sẵn. 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ế. và các ứng dụng dựa trên các thành phần (component-based applications). Cách đầu tiên là tự tay xây dựng từ đầu hệ thống theo mô hình SOA. Chiến lược top-down Trong xây dựng một hệ thống SOA. và việc xem xét chúng như các dịch vụ trong một tổng thể. 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. và nhiều sản phẩm trung gian (middleware products) kết hợp với nhau thành những server. 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. Bước 4: Kiểm thử dịch vụ (Service testing). mối quan tâm cho hệ thống phân tán. Sau khi các dịch vụ được triển khai.

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).13: Các bước xây dựng hệ thống theo chiến lược top-down. Bước này là để xác định. thì tại bước này nó sẽ được định nghĩa. Các kết quả này là các từ vựng phổ biến... 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. Bước 1: Define relevant ontology. các trường hợp sử dụng (use cases) và đi tới xác định các thành phần. theo mỗi cách quản lý thì các nghiệp vụ chia ra một cách rõ ràng. 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. 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. các dịch vụ. 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. 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.trình nghiệp vụ và các tiến trình con. 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. 32 . Hình 2. 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. Hình 2. của hệ thống.

2. 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. Bước 7: Deploy service Quan tâm tới vấn đề thực thi. 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ụ.3. Để tạo điều kiện cho nhiều người yêu cầu dịch vụ. mô hình hóa các dịch vụ.- Bước 2: Align relevant business models (including entity models) Sau khi ontology được thiết lập. Bước 4: Perform service-oriented design Thực hiện thiết kế hướng dịch vụ. Đồng thờ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. Mô hình thực thể chi tiết rất quan trọng. 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ụ. 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. 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. cần phải cung cấp cả khả năng truy cập cho dịch vụ.4. xác định tiềm năng tương lai sử dụng lại của dịch vụ. Sau khi có được các dịch vụ từ những thành phần đó. 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.2. 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. 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 5: Develop services Phát triển các dịch vụ theo yêu cầu. 33 .

ở một khía cạnh 34 . Trường hợp này.Hình 2. Hình 2.14: Tiếp cận Bottom-up xây dựng hệ thống Trong hướng tiếp cận này. bao gồm có các dịch vụ tiện ích và nhân bản. 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ế. Các dich vụ có thể cung cấp thêm vào cho thiết kế. 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ể. 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. 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. 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). 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.15: Các bước xây dựng hệ thống theo chiến lược bottom-up. Các dịch vụ ứng dụng tùy chọn sẽ cần đưa qua quá trình thiết kế.

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. 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ụ. 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. 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. Hiện xu thế SOA đang phát triển rất mạnh. 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. 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. Bước 4: Test service Các dịch vụ. 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. 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.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. 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í. Kiểm tra bảo mật cũng là phần quan trọng của giai đoạn này. 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. môi trường kết hợp của chúng. 35 .

#Ngay.net/WeatherForecast.2.webservicex. Sql Server 2005 xây dựng Web Service. 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. 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. đọc thông tin dạng XML trả về của dịch vụ và hiển thị thông tin.1. ThoiTiet(#MaTTP.1. Chương trình demo Sử dụng công cụ: Visual studio 2008. Nhietdo. 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. Xây dựng chương trình a. TenTTP): cung cấp mã và tên các địa điểm trên cả nước.1.asmx?WSDL 3. 36 . Xây dựng giao diện website gọi dịch vụ. 3. Mota): cung cấp thông tin thời tiết các địa điểm.1.CHƯƠNG 3: KẾT QUẢ VÀ THẢO LUẬN 3.

- 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.Services.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.Web. nhập vào mã tỉnh thành phố: 37 .

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.

- Để sử dụng được Web Service đã xây dựng. 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ý.asmx?WSDL - Nhập mã tỉnh thành phố: - Kết quả: 39 .

- Sử dụng dịch vụ từ một nhà cung cấp khác: http://www.net/WeatherForecast. nhập vào PlaceName. Kết quả trả về: 40 .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ụ.webservicex.

41 . phân quyền…). Thực tế. Đá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ụ. 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ụ.2. đăng ký dịch vụ.3. 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 đề. 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ử lý xác thực.

do kĩ năng nghiên cứu và kiến thức còn hạn chế. Sau quá trình nghiên cứu. 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!”. 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. Trong quá trình nghiên cứu đề tài. Em mong nhận được sự đóng góp của thầy cô để đề tài hoàn thiện hơn. Đó là triết lý của SOA. Nguyễn Thị Dung 42 . 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. “Đừng tốn công chế tạo lại bánh xe. đề 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. 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 đề. 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ụ. cách thức đăng ký một Web Service với Service Broker.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.

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

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

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 .

Sign up to vote on this title
UsefulNot useful