Giáo trình Tích hợp ứng dụng trên Web qua XML (Nghề Lập trình máy tính): Phần 2 cung cấp cho người đọc những kiến thức như chủ đề phát triển ứng dụng tích hợp trên nhiều nến tảng, trên các hệ thông tin hiện hành và trên các dòng thiết bị khác nhau và liên hệ giữa XML và .net. Mời các bạn tham khảo!
Trang 1BÀI 3 TÊN BÀI : CÁC CHỦ ĐỂ PHÁ TRIỂN ỨNG DỤNG TÍCH HỢP: TRÊN NHIỀU NỀN TẢNG, TRÊN CÁC HỆ THỐNG THÔNG TIN HIỆN HÀNH VÀ TRÊN CÁC DÒNG
THIẾT BỊ KHÁC
Mã bài : ITPRG3_15.03
Giới thiệu :
Trong nội dung này chúng ta tập trung nghiên cứu các nội dung về phát triển các ứng dụng
đa nền tảng và đa thiết bị
Mục tiêu thực hiện:
Học xong bài này học viên sẽ có khả năng:
- Tập trung theo 3 hướng quan trọng: Phát triển ứng dụng tích hợp trên nhiều nền tảng; trên
các hệ thông tin hiện đang hoạt động và trên các dòng thiết bị khai thác thông tin khác nhau
Nội dung chính:
I Cơ chế xác lập ứng dụng liên quan đến nhiều nền tảng
Như những hệ tính toán đã sống trên những mạng, ở đó là một nhu cầu (cho) những hệ thống đó để giao tiếp với lẫn nhau tại mức ứng dụng Những giao thức mạng như TCP và UDP được cung cấp một cách cho những lập trình viên để xây dựng trình khách/chủ và truyền thông từ tương đương tới tương đương Lập trình những giao thức này trực tiếp, tuy nhiên, đã có thể là một nhiệm vụ đe dọa, vì vậy những lớp xuất hiện ở trên những nghi thức này mà làm dễ nhiệm vụ của việc viết những ứng dụng phân tán Trong mục này chúng tôi tổng quan những riêng biệt của những lớp này mà hỗ trợ sự phát triển ứng dụng đa hệ, bao gồm những UNIX Socket, Môi trường tính toán phân tán (DCE) CORBA, Java RMI, Và DCOM
UNIX Sockets
UNIX Socket là tiêu chuẩn đầu tiên được dựa vào đỉnh của những giao thức cơ bản cung cấp một giao diện cho những lập trình viên để viết thành phần truyền thông của những ứng dụng khách/chủ tại một mức trừu tượng hơn Một lập trình viên đã có thể chỉ rõ một lỗ hướng kết nối khi một kết nối bền bỉ được cần, hoặc những lỗ không có kết nối cho việc gửi thông điệp, và lỗ thực hiện chức năng đúng với nghi thức nằm bên dưới
Thậm chí với những UNIX Socket, tuy nhiên, nhiều vấn đề ở lại cho thảo chương viên ứng dụng Dù những UNIX Socket giới thiệu một lớp trừu tượng hóa ở trên những nghi thức nằm bên dưới, giao diện lỗ vẫn còn yêu cầu mức thấp lập trình UNIX socket chỉ làm việc với các hệ thống UNIX
UNIX socket (và sự thi hành liên quan khác) chỉ cung cấp khả năng chuyển đổi dữ liệu thô, và thiếu những khả năng triệu gọi thủ tục từ xa hay những chức năng Bất kỳ sự xử lý nào của dòng dữ liệu đầu vào phải là những buộc dây vào trình khách Socket không cung cấp khả năng, chẳng hạn, chuyển phương thức hay những tham số hàm giữa các hệ thống Môi trường tính toán phân tán
Trong khi UNIX Socket cung cấp khả năng đi qua nguyên khối dữ liệu chảy giữa những
hệ thống, những người thiết kế những hệ thống phân tán cần một cơ chế độc lập nền tảng hơn mà hỗ trợ những sự gọi thủ tục từ xa thực tế Một sự nỗ lực để cung cấp khả năng RPC được biết như môi trường tính toán phân tán, hay DCE Môi trường này cung cấp một cơ sở
hạ tầng độc lập lý thuyết nền tảng cho sự thi hành và quản lý những ứng dụng phân tán Nó cũng cung cấp thư mục và những dịch vụ bảo mật, cũng như hệ tập tin và những khả năng RPC phân tán (Nó thậm chí cung cấp một cơ chế đồng bộ hóa thời gian cho những thành viên " tế bào ") DCE cũng chính xác được xử lý sắp xếp của RPC dữ liệu như giữ tới đúng định dạng dữ liệu của hệ điều hành gọi và nhận
DCE chỉ phụ thuộc nền tảng đối với phạm vi mà một cách tương đối phần mềm khách hàng phạm vị rộng tồn tại cho nền tảng đích Để can dự vào những dịch vụ này một nền tảng phải được định hình ( Lần nữa, Một thao tác tiềm tàng phức tạp) Vào trong một tế bào
Trang 2DCE Sau đó những sự thi hành DCE cho phép người sử dụng định hình những dịch vụ nhất định, như cơ chế RPC Tuy nhiên, sự đau đầu trong việc mua, định hình, và bảo trì một tế bào, cũng như thiếu tính sẵn sàng chung của phần mềm khách hàng, ngăn ngừa DCE từ sự trở thành Một giải pháp đa dụng cho sự tính toán phân tán
CORBA
CORBA cung cấp một cơ sở hạ tầng độc lập nền tảng và ngôn ngữ cho việc xây dựng những ứng dụng phân tán và kéo theo những sự gọi thủ tục từ xa từ những hệ thống khách hàng Những đối tượng phân tán có hạt nhỏ những hiện tại CORBA bên trong những mạng tính toán hỗn tạp Những ứng dụng có thể đồng nhất nhận ra và sử dụng những thành phần phần mềm kinh doanh sẵn có qua mạng toàn cầu Nhữn thành phần tiêu chuẩn ở sau CORBA, nhóm Quản lý Đối tượng (OMG), trước đấy được tin tưởng rằng những số lớn của những ORB tồn tại trên Internet
Những đối tượng CORBA độc lập ngôn ngữ Những máy chủ CORBA giới thiệu những giao diện của họ trong dạng IDL, định nghĩa những phương thức được hỗ trợ bởi những người phục vụ CORBA và lý lẽ kỳ vọng tới những phương thức đó Những chương trình Khách hàng tương tác với những đối tượng này qua mẩu những giao diện mà thực hiện một đối tượng là những phương pháp từ xa trên máy tiêu khiển phần mềm ORB đứng trong điểm giữa và gửi đi tất cả truyền thông intermachine Những ORB xung quanh Internet có thể chia sẻ thông tin về những đối tượng chúng quản lý IIOP được phát triển cho mục đích này
Java RMI
Giống như CORBA, hệ thống con RMI của Java cho phép những đối tượng phân tán ngang qua mạng Không giống CORBA, Java RMI có thể chuyên chở một toàn bộ lớp, phần mềm và mọi thứ, ngang qua những ranh giới ứng dụng (qua RMI hoặc những giao thức IIOP) Truyền thông này khả dĩ bởi vì tất cả các ứng dụng Java phải chạy trên Máy ảo Java Điều này cho phép những ứng dụng Java phân tán để an toàn tải xuống dòng byte được biên dịch và thực hiện chúng một cách cục bộ
DCOM
DCOM là một sự cài đặt Windows của một môi trường phát triển ứng dụng- phân tán được dựa vào COM của Microsoft DCOM sử dụng RPC DCE như đối tượng từ xa nằm bên dưới- cơ chế hỗ trợ
Không giống CORBA, một đối tượng DCOM có thể giới thiệu nhiều giao diện, mà lần lượt có thể cung cấp nhiều hành vi đối tượng Một trình khách COM triệu gọi một đối tượng COM bằng việc thu nhận một con trỏ trỏ tới giao diện của đối tượng Trình khách triệu gọi những phương thức thông qua qua con trỏ đó; từ viễn cảnh của trình khách, đối tượng xuất hiện cư trú trong vùng địa chỉ của khách hàng Vì DCOM chặt chẽ tổng hợp với hệ điều hành windows, DCOM chỉ cung cấp một giải pháp cho những ứng dụng phân tán trên nền Bảng
so sánh sau sẽ cho thấy rõ hơn:
Kiểu Nền tảng hỗ trợ Ngôn ngữ cấu hình Sự phức tạp khi Chi
phí Soc
RMI
Java (Java Virtual
g DC
g
Trang 3II Xây dựng ứng dụng liên quan đến nhiều nền tảng dựa vào Web service
vụ này tự động không? Nếu bạn đang phát triển trên một nền tảng Windows, bạn có thể vẽ trên những khả năng mạnh của Microsoft Visual Studio.NET việc xây dựng những ứng dụng dịch vụ web XML
Visual Sutdio NET cung cấp các ngôn ngữ phát triển web hiện đại, bao gồm VBScript, JScript, Visual Basic, C, C++, Visual C++, C#, Perl, Python, COBOL, PASCAL và Scheme
Nó cũng cung cấp một môi trường tích hợp cho việc phá triển các dịch vụ web XML tương ứng cho người phát triển từ các nền tảng phát triển khác nhau
Cuối cùng, Visual Studio NET cung cấp một phương thức phát triển nhanh cho các giao diện người sử dụng Có khả năng kiểm xem và giám sát các thông điệp SOAP giữa trình khách và máy chủ
API Diễn giải
JAXP: Java API
for XML processing
Cung cấp khả năng cho cả hai nền xử lý dựa trên cây (DOM) hay trên nền xử lý sự kiện (SAX) của dữ liệu XML API cũng cung cấp sự hỗ trợ XMLTs giúp chuyển đổi những tài liệu XML của chúng
ta vào trong từ vựng XML Bạn có lẽ đã muốn làm điều này để, chẳng hạn, thay đổi dữ liệu XML tới HTML cho màn hình trong một
bộ duyệt web, hay rút những thành phần của một tài liệu XML và áp dụng những gói WML cho màn hình trên màn ảnh của một thiết bị
từ một thể hiện tài liệu XML Từ một tài liệu XML bạn có thể tạo ra một cái cây đối tượng Java để xử lý bởi người dịch vụ web của chúng ta
JAXM: Java
API for messaging
Cung cấp khả năng để tạo ra những tài liệu SOAP để chuyển thông điệp giữa các hệ thống trong định dạng SOAP API quản lý những chi tiết như cú pháp SOAP và sự nhận ra thông báo
Trang 4API Diễn giải
điệp đa phần, và sự xác minh giao hàng
Các nền tảng khác
Về mặt lý thuyết, bất kỳ thiết bị tính toán nào mà có thể chấp nhận những yêu cầu HTTP đầu vào, thao tác dữ liệu đầu vào bởi một phương thức, những kết quả vào trong một tài liệu XML, và chuyển tài liệu XML kết quả tới khách hàng qua HTTP có thể được dùng làm một dịch vụ Web Những biến trong chọn thực hiện những nhiệm vụ này trên một nền tảng phi Windows hay phi UNIX bao gồm bản chất của dịch vụ Web và tính sẵn sàng của những công cụ để hỗ trợ cung cấp cơ sở hạ tầng cho dịch vụ web Chẳng hạn, tối thiểu nền tảng cần phải hỗ trợ một bộ phân tích XML để tạo ra hồ sơ kết quả XML
Những nền tảng Thay thế có sự hỗ trợ J2EE có lẽ đã là những ứng cử viên hợp lý cho các máy chủ dịch vụ web Cách khác, triển khai một máy chủ dịch vụ web trên, Chẳng hạn, một thiết bị cầm tay, có lẽ đã là một bài tập trong sự phát triển ứng dụng không truyền thống,
ít nhất là trong thời gian tới
Xây dựng trình khác
Xây dựng những trình khách cho những ứng dụng phân tán đã chưa bao giờ dễ dàng hơn Bởi vì những dịch vụ web được dựa vào những tiêu chuẩn mở như HTTP Và XML, Mọi thứ là cực tiểu yêu cầu của một khách hàng dịch vụ Web là khả năng để tạo ra và sự chuyển qua tới người phục vụ một HTTP GET hay POST tài liệu yêu cầu hay một XML SOAP Khả năng này có thể được thực hiện trong một sự đa dạng của những cách Đơn giản nhất, bất
kỳ khách hàng nào mà hỗ trợ một bộ duyệt Mạng thích hợp HTML 3.2- và nghi thức HTTP
có thể tham gia khi một dịch vụ mạng khách hàng Thậm chí những khách hàng mà không phải bộ duyệt thích hợp hỗ trợ HTML 3.2- có thể sử dụng sự hỗ trợ ứng dụng gắn sẵn của riêng mình để tạo ra điều kiện cần thiết hay không những hồ sơ XML cho sự truyền qua HTTP tới máy chủ dịch vụ Web
Nền tảng Window
Visual Studio NEt cung cấp một môi trường phát triển hoàn chỉnh để xây dựng, triển khai và kiểm tra các dịch vụ Weg XML Chúng ta có thể phát triển cả trình chủ và trình khách trực tiếp trong ứng dụng Các trình khách chạy trên Windows NT, Windows 2000 hay Windows XP có thể là HTML hay các web form Trên nền tảng Windows, Visual Studio NET
có thể lưu web for như là một DLL
UNIX và Linux
Chúng ta có thể xây dựng trực tiếp trình khách dịch vụ web HTML 3.2 từ Visual studio NET Bởi vì giao diện khách hàng tới một người phục vụ những dịch vụ Web duy nhất một phương thức HTTP GET hay POST hay một XML hồ sơ, chúng ta có thể thiết kế trình khách dịch vụ web của riêng mình Ngôn ngữ mà bạn sử dụng và mẫu dạng của trình khách dịch
vụ web không thích hợp miễn là trình khách có thể sắp xếp khổ dữ liệu bản ngữ của nó trong một hồ sơ XML, gởi dữ liệu qua HTTP, nhận tài liệu kết quả thông qua HTTP và sắp xếp lại tập kết quả
Các nền tảng khác
Một lần nữa, Visual Studio NET cung cấp khả năng để phát triển các trình khách dịch
vụ web trên các nền tảng khác
III Tích hợp các hệ thông tin hiện có
Trong nội dung này, chúng ta bàn luận về các chướng ngại khi tích hợp các hệ thống thông tin hiện có
Tài liệu
Sự thật không may về những hệ thống hiện tại thường thì kém cỏi trong việc lấy tài liệu, rời bỏ những người phát triển và những người những doanh nghiệp giống nhau miễn cưỡng
để làm những sự thay đổi Mọi người sợ hãi mà vì thế sẽ gãy là hệ thống trong cách nào đó
Để thêm vào vấn đề, bản chính những người phát triển hay những chủ nhân (của) những hệ thống này có lẽ đã không sẵn sàng để làm việc với một đội mới hơn bởi vì những lý do bình thường như những bảo mật bên trong
Trang 5Mễn cưỡng hay không có khả năng để thay đổi những hệ thống là một trong những lý
do sơ cấp tại sao sự hợp nhất được xem xét cần thiết trong chỗ đầu tiên Không có trợ giúp chuyên gia tài liệu, những dự án hợp nhất của các chúng ta phải đối mặt một sự chết khốn khổ
ví dụ, được thiết kế thường xuyên với một yêu cầu đóng cửa bảo trì tuần hoàn ứng dụng của chúng ta sẽ làm gì Khi những hệ thống thừa kế không có sẵn? Nó sẽ xử lý không phải hiện thân có khả năng để truy nhập dữ liệu nó cần vận hành như thế nào? Nó cần phải duyên dáng báo động những người sử dụng của hoàn cảnh như thế nào?
Những câu hỏi này cần được trả lời khi xây dựng ứng dụng của chúng ta, nhưng danh sách của những câu hỏi có thể dài nhiều hơn khi nói về một ứng dụng đặc biệt Chúng ta phải biết và hiểu tất cả các sự liên quan của tính sẵn sàng của hệ thống thừa kế, hay ít nhất cũng nhiều như khả dĩ, khi quyết định làm sao để sử dụng nó Bất kỳ hệ thống nào chúng ta phát triển ý định thừa kế những sự hạn chế này
Tính Chuyển đổi
Với nhiều dự án tích hợp thừa có lẽ đã là thách thức lớn nhất đơn Đa số những hệ thống thừa kế được thiết kế không phải để xử lý những âm lượng lớn của những giao dịch thời gian thực mà những hệ thống hôm nay phải đối mặt Những hệ thống thừa kế thường được thiết kế hỗ trợ một vài kiểu in mà có sự truy nhập tới chỉ một một nhúm những máy Nhiều hệ thống thừa kế này cũng hướng lô và sẽ không có khả năng để xử lý những câu hỏi
và những giao dịch trực tuyến Nhiều ứng dụng, thứ một cách đặc biệt trên nền Web, hiện thân có thể xử lý một thể tích lớn và không thể đoán trước của trực tuyến những giao dịch
là một yêu cầu
IV Tạo các giao diện giữa các hệ thống hiện hành
Chúng ta có thể tạo giao diện với hệ thống thừa kế sử dụng năm cách tiếp cận Chúng đang khái quát hóa để đại diện cho những vùng mà những người phát triển và những người quản lý có thể tập trung vào khi thử dùng những hệ thống cũ cho công việc mới Đó là: Mức dữ liệu (Data-level)
Mức xử lý (Process-level)
Mức API (API-level)
Mức UI (UI-level)
Trung gian (Middleware)
Giao diện múc dữ liệu
Những cơ sở dữ liệu kiểu tiêu điểm giao diện trên việc truy nhập kế thừa đầu tiên hay những tập tin trực tiếp tại cấp dữ liệu Đa số chức năng này được ấn định bởi ứng dụng phạm vi ngoài
Nếu dữ liệu của chúng ta được lưu giữ trong những cơ sở dữ liệu SQL chúng ta trực tiếp có thể truy nhập chúng sử dụng những truy vấn SQL thích hợp Một số hệ thống RDBM, như những phiên bản cũ hơn hơn của Novell Btrieve, không cung cấp SQL, tuy nhiên khá đầy đủ, API truy cập tới những cơ sở dữ liệu của họ Những hệ thống khác cung cấp những
cơ chế bộ nhớ dữ liệu sở hữu và thường có nhập khẩu dữ liệu và những chức năng xuất khẩu thiết kế đặc biệt cho giao diện Truyền thông với những hệ thống này được thực hiện
Trang 6xuyên qua sự trao đổi của những tập tin khuôn dạng đặc biệt Thường chúng sử dụng để triệu gọi một vài biểu mẫu của các tập tin văn bản không giới hạn
Một vài công ty khác, chẳng hạn Oracle và Microsoft cung cấp lưu trữ XML trong cơ sở
dữ liệu của họ
The vấn đề chính với giao diện mức dữ liệu là nó tăng sự ghép nối dữ liệu giữa những ứng dụng, do đó tăng sức nặng bảo trì của chúng ta Chúng ta có lẽ đã cũng không có khả năng truy nhập sự hợp thức hóa dữ liệu và những quy tắc doanh nghiệp khác quan trọng mà
cố hữu trong ứng dụng mà không phải trong phương thức của việc truy nhập thông tin Cuối cùng chi phí có thể cũng là một nhân tố giới hạn, một cách đặc biệt nếu bạn cần thuê một sản phẩm trung gian
Giao diện mức xử lý
Các giải pháp được được viết cho một số môi trường máy tính lớn, một cách đặc biệt chúng được viết trong COBOL, được phát triển như một loạt của những chương trình thực thi riêng rẽ Giao diện với những hệ thống này thông thường yêu cầu chuẩn bị môi trường triệu gọi, gọi là chương trình yêu cầu, và mang về và xử lý dữ liệu trở về lại Trong khi công thức này giao diện mức quá trình cung cấp một phương pháp chung của việc dữ liệu nó có thể đang là chôn vùi khi thử giải nén thông tin đơn giản
Đây là một ví dụ của giao diện mức xử lý làm việc với CICS, cung cấp một Giao diện Gọi Ngoài (External Call Interface-ECI) để cho phép những không CICS khách hàng để kéo theo và kiểm soát lập trình dưới CICS ECI bao gồm sự an toàn hỗ trợ CICS và những giao dịch và, không giống những môi trường RPC, ECI không yêu cầu các mẩu (stubs) và sự sử dụng một ngôn ngữ định nghĩa giao diện (Interface Definition Language - IDL) và bởi vậy dễ dàng để sử dụng
Giao diện mức API
Một kiểu giao diện khác với những hệ thống thừa kế sẽ cung cấp một API truy nhập chức năng của một ứng dụng Nhiều gói, như SAP và PeopleSoft, Bao gồm C/ C++ hay thậm chí API nền tảng COM để truy nhập những hệ thống của họ Tuy nhiên, API hạn chế trong phạm vi, ngăn ngừa sự truy nhập tới những chức năng bạn cần Chúng có thể truy cập theo kiểu cách mà chúng ta không mong muốn, chẳng hạn các tuyết trình không an toàn
Nếu đội của chúng ta có những tập kỹ năng yêu cầu, những API này có thể cung cấp một phương tiện mạnh của giao diện tới những hệ thống thừa kế Tuy nhiên, những API này
có lẽ đã hạn chế trong phạm vi, cản trở bạn truy nhập những chức năng bạn cần Họ có lẽ
đã cũng không xử sự trong kiểu cách chúng ta đòi hỏi
Giao diện mức giao diện người sử dụng (Mức UI)
Truy cập những ứng dụng thừa kế xuyên qua UIs, một quá trình gọi là nạo màn ảnh, tham chiếu tới sự tương tác với phần mềm thừa kế được thực hiện bởi việc sử dụng đã mô phỏng những phím nhấn và nhập dữ liệu bằng việc xử lý việc chụp màn hình đầu ra Kỹ thuật này được sử dụng với "màu xanh lục" cũ trên nền thiết bị đầu cuối những hệ thống thường xuyên nhất và là một trong số phương pháp cuối cùng một người có thể sử dụng để hợp nhất với một hệ thống
Mới đây kỹ thuật này đã được sử dụng bởi những chỗ tập hợp trên nền Web để giới thiệu dữ liệu tài chính hay những kiểu khác của thông tin Những chỗ này xây dựng nội dung của họ bằng việc kết hợp dữ liệu được rút từ việc phân tích những trang HTML được khôi phục từ những trang web khác
Trung gian (Middleware)
Vài nhà cung cấp máy tính lớn và vật thứ ba những công ty cung cấp những giải pháp
mà cho phép những ứng dụng truy nhập dữ liệu xuyên qua những sản phẩm trung gian Những sản phẩm này ngồi giữa những hệ thống mới và hệ thống kế thừa của chúng ta, che giấu những chi tiết phức tạp giao diện thừa kế từ chúng ta
Những sản phẩm trung gian khác có thể thay đổi nhiều trong chức năng Một số sản phẩm đơn giản cung cấp một cơ chế cho dữ liệu để có từ nơi này sang nơi khác, chẳng hạn như RPC, Những hệ thống thông điệp, và những hệ thống đối tượng phân tán Những sự đề nghị phần trung phức tạp hơn, tuy nhiên, có thể giúp đỡ quản lý lôgic ứng dụng và những tài nguyên Những đa số công cụ linh hoạt trực tiếp hỗ trợ những chức năng ứng dụng quan
Trang 7trọng như những giao dịch thẻ tín dụng cho thương mại điện tử Bởi việc thuê caching và công nghệ chuyển đổi dữ liệu không đồng bộ phức tạp, những sản phẩm cấp cao này có thể cũng cung cấp sự truy nhập tới dữ liệu thừa kế của chúng ta
Nếu sự hỗ trợ hệ thống thừa kế đặc biệt của chúng ta được cho phép, sử dụng sản phẩm trung gian có thể rất đơn giản hóa nhiệm vụ của sự hợp nhất gia tài Downside chính
là những sản phẩm này, đặc biệt là thứ cấp cao, không rẻ Họ cũng yêu cầu những tài nguyên phần cứng và sự quan tâm hành chính thêm mà thêm vào chi phí Bạn sẽ phải quyết định liệu có phải việc sử dụng một sản phẩm trung gian là chi phí có hiệu quả cho những
nhu cầu hợp nhất đặc biệt của chúng ta s
V Kiến trúc hệ ứng dụng tích hợp
Điều kiện hạt nhân
Ba điều kiện cần phải được sử dụng chuẩn bị cho những hệ thống thừa kế hợp nhất Bằng việc làm cho hệ thống có thể tiếp cận xuyên qua nhiều truyền thông là những cơ chế trước, sự lỗi thời bởi công nghệ có thể thu nhỏ Danh sách sau đây phác thảo ba vùng này: Ứng dụng cần phải có khả năng hỗ trợ nhiều thủ tục truyền tin như HTTP, IIOP, SOAP,
và những cái khác Trong khi đầu tiên và sự thi hành tức thời có thể hỗ trợ chỉ có một, những hook cần phải được xây dựng bên trong để có thể mở rộng tương lai Ngoại lệ duy nhất khi chúng ta đang xây dựng cho một sự hợp nhất trước kia để di trú dữ liệu vào trong một hệ thống mới
Giao diện thông điệp phải không phụ thuộc giao thức và nhất quán
Mô hình dữ liệu sử dụng bởi các thông điệp định dạng phải định nghĩa trong các điều khoản của sự vận chuyển kinh doanh của tổ chức
Lớp dịch vụ là lớp giữa cung cấp chức năng cho những yêu cầu được định dạng bởi phiên dịch XML, triệu gọi những thao tác thích hợp ở trên hệ thống thừa kế, và định dạng những sự đáp lại vào trong XML
Một lớp bộ tiếp hợp thừa kế là lớp trong cùng chiụ trách nhiệm về giao diện cho hệ thống thừa kế và đại diện cho mô hình của dữ liệu
Lớp vận chuyển:
Lớp vận chuyển, trong khi chúng tôi đề cập, cho phép những trình khách của những ứng dụng thừa kế này để sử dụng những giao thức và những cơ chế khác nhau, như HTTP, CORBA (IIOP), Hay DCOM, triệu gọi những dịch vụ để xác định bởi giao diện tới ứng dụng Những lớp trong lớp này có thể khá thẳng thắn bởi vì vai trò sơ cấp của chúng sẽ cung cấp một cái cầu truyền thông tới những dịch vụ thực tế Trách nhiệm chính của lớp này sẽ làm cho phần còn lại của hệ thống độc lập giao thức
transport_layer.aspx: Sample Transport Layer for HTTP protocol
<%@ import namespace="System.Xml"%>
<script language="C#" runat="server">
/* string used to hold string representation of
our service request XML message */
String xmlStr = "<ServiceRequest>";
/* get names of all form variables into local array */
String names[] = Request.Form.AllKeys;
/* loop through form variable to build request XML message */
foreach ( name in names )
{
/* if form variable is called "service", use its value to
build the ServiceName element */
if ( name == "service" )
{
Trang 8xmlStr += "<ServiceName>" + name + "</ServiceName>";
}
/* othewise use this form variable's name and value to
build a <Param> element */
else
{
xmlStr += "<Param name=\"" + name + "\">" +
Request.Form[ name ] + "</Param>";
}
}
xmlStr += "</ServiceRequest>"
/* create XmlDocument using the reqXML string */
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.LoadXml( xmlStr );
/* instantiate our ServiceLayer object */
ServiceLayer service = new ServiceLayer();
/* invoke the perform() method with our request XML message */
XmlDocument retXmlDoc = service.perform( xmlDoc );
/* output the response XML message to the client tell
browser/client that we are outputting XML */
Lớp dịch vụ
Lớp thứ hai định nghĩa những dịch vụ trong hệ thống được triệu gọi như thế nào và dữ liệu được trả lại bởi những dịch vụ được định dạng như thế nào Những yêu cầu có định dạng XML được đẩy tới tới lớp này qua lớp vận chuyển, và những lớp trong lớp này phân tích những yêu cầu giao dịch và triệu gọi những phép toán trên hệ thống kế thừa
Những phương thức trưng bày bởi những lớp bộ tích hợp kế thừa và tham số được dùng trong việc triệu gọi những phương thức cần phải được dùng để thiết kế định dạng của thông điệp XML được dùng bởi lớp này Khi thiết kế định dạng của những thông báo này, giữ cho nó chắc chắn ngang qua những dịch vụ khác nhau sẽ được triệu gọi Chẳng hạn, ví
dụ sau sẽ trưng bày ý tưởng của chúng ta (ServiceName sử dụng để chỉ định dịch vụ kế thừa sẽ được triệu gọi, Param giữ tên và giá trị của tham số)
sample_request.xml: Sample service request XML message
Trang 9{
/* our Legacy Layer object */
Legacy legacy = new Legacy();
/* retrieve name of the legacy service to invoke */
DocumentNavigator nav = new DocumentNavigator( params ); nav.Select( "//ServiceRequest/ServiceName" );
/* retrieve the customerID, itemID, and qty parameters
from the Params XML document */
nav.Select( "//ServiceRequest/Param[@name='customerID']" ); nav.MoveToNextSelected();
string customerID = nav.innerText;
nav.Select( "//ServiceRequest/Param[@name='itemID']" ); nav.MoveToNextSelected();
string itemID = nav.innerText;
nav.Select( "//ServiceRequest/Param[@name='qty']" );
nav.MoveToNextSelected();
string qty = nav.innerText;
/* invoke the orderItem() method in our Legacy object
to place an order and build result XML document based on the outcome */
string customerID = nav.innerText;
/* invoke the getOrderHistory() method in our Legacy
object and output result in our resultDoc XML document */ try
{
string[] tranIDs = legacy.getHistory( customerID );
/* get list of transaction IDs of past transaction
and build result XML document */
foreach ( string tranID in tranIDs )
{
res = res + "<TransactionID>" + tranID +
"</TransactionID>";
}
Trang 10/* build and return result XML document */
XmlDocument resultDoc = new XmlDocument();
resultDoc.loadXml( "<ServiceRequestResponse>" + res +
legacy_layer.cs: The psuedocode of a sample Legacy Layer
public class LegacyLayer
{
/* place an order return the new transaction ID or throw
an exception if an error occurred */
public string orderItem( string customerID, string itemID, string qty )
{
/* insert your actual implementation here */
}
/* get order transaction of a specific customer return a
string array containing the list of the transaction IDs
of previous order transaction or throw an exception if
Trang 11BÀI 4 TÊN BÀI : LIÊN HỆ GIỮA XML VÀ NET
Học xong bài này học viên sẽ có khả năng:
- Hiểu được các vấn đề về XMLP (SOAP)
- Hiểu được quan hệ XML với Biztalk Server
- Hiểu được quan hệ XML với phát triển trên môi trường NET
Nội dung chính:
I Vấn đề XMLP (SOAP)
SOAP <Envelope>
Một thông điệp SOAP là một tài liệu XML mà gồm có một phần tử SOAP gốc
<Envelope>, một phần tử tùy chọn <Header>, và một phần tử <Body> Nghĩ về điều này như một phong bì thường gửi bưu điện một bức thư tới một bạn ngang qua nước Phong bì SOAP tương tự đối với phong bì giấy-nó trình bày những phương hướng lộ trình và bức thư Những phương hướng lộ trình, hay địa chỉ (từ và đến) được đại diện cho trong phần tử
<Header> của một thông điệp SOAP Chính bức thư được chứa đựng trong thân SOAP Tất
cả thông tin này cần thiết để một cách thành công truyền dữ liệu qua giao thức SOAP skeletal_soap.xml: A skeletal SOAP message
SOAP <Envelope> được định nghĩa bởi không gian tên có URI http://schemas.xmlsoap.org/soap/envelope/, định nghĩa các phần tử và thuộc tính SOAP sử dụng trong phần tử <Envelope>
Các luật mã hóa mặc định SOAP và kiểu dữ liệu được định nghĩa bởi không gian tên có URI http://schemas.xmlsoap.org/soap/encoding/
Thuộc tính toàn cục encodingStyle
Thuộc tính SOAP-ENV:encodingStyle được dùng để chỉ báo những quy tắc thường mã hóa thông tin trong một thông điệp SOAP đặc biệt Những quy tắt mã hóa SOAP mặc định được xác định bởi không gian tên http://schemas.xmlsoap.org/soap/encoding/ Thuộc tính này có thể xuất hiện trên bất kỳ phần tử nào Khi được áp dụng, phạm vi của nó bị hạn chế đối với nội dung của phần tử đó và tất cả các phần tử đứa trẻ không phải đè thuộc tính với namespace của mình Chú ý rằng không có sự mã hóa mặc định được định nghĩa cho một thông điệp SOAP, vì vậy bạn phải bao gồm thuộc tính encodingStyle ít nhất một lần trong những thông điệp SOAP của chúng ta Thường thì chúng ta sẽ bao gồm nó trong bản thân khai báo <Envelope>, tập tin sau là một ví dụ:
Trang 12<Header>
Phần tử <Header> được dùng để đóng gói thông tin mà không bị ràng buộc đối với một phương thức đặc biệt, nhưng cung cấp thông tin văn cảnh thay vào đó Những ví dụ tiêu biểu của việc sử dụng phần tử <Header> là sự an toàn, quản lý giao dịch và thông tin thanh toán
Đây là vài quy tắc được định nghĩa bởi thuyết minh SOAP cho phần tử <Header > được liệt kê như sau:
Phần tử <Header> là tùy chọn , nhưng, nếu được ấn định, phài là phần tử con đầu tin trong <Envelope>
Phần tử <Header> phần tử phải sử dụng các luật mã hóa SOAP trừ phi đầu mục chỉ định một tập hợp các luật khác Yêu cầu này được hoàn thành sử dụng thuộc tính SOAP-ENV:encodingStyle
Tất cả phần tử con <Header> phải đủ khả năng không gian tên
Phần tử <Header> có thể chứa thuộc tính SOAP-ENV:mustUnderstand
soap_header.xml: Một vài ví dụ về các phần tử SOAP <Header>
Giá trị của thuộc tính SOAP-ENV:mustUnderstand là 1 hoặc 0 Sau đây là một ví dụ: soap_header2.xml: The SOAP-ENV:mustUnderstand attribute
Trang 13một tập hợp những trung gian SOAP, mỗi lần nhận được thông điệp sẽ được chuyển đến bộ thu tiếp theo, cho đến khi thông điệp đạt đến trạm cuối cùng của nó Bởi vậy, không phải tất
cả thông điệp những bộ phận của một thông điệp SOAP có thể được dự định cho trạm cuối cùng; nó được định hướng tại một hoặc nhiều trong số những trung gian trên đường dẫn thông điệp
Chúng ta sử dụng thuộc tính SOAP-ENV:actor để cho phép một thông điệp SOAP thông tin của <Header> liên quan đối với một trạm nhận chỉ định Giá trị của thuộc tính SOAP-ENV:actor là một URI được dùng xác định trạm nhận của phần tử <Header> Thuyết minh SOAP định nghĩa một URI đặc biệt: http://schemas.xmlsoap.org/soap/actor/next, để chỉ ra phần tử <Header> liên hệ được dự định cho trạm nhận SOAP đầu tiên, trung gian hay cách khác
<Body>
Phần tử <Body > chứa đựng dữ liệu liệt kê thực tế của phương thức gọi chính nó Phần
tử <Body> được sử dụng cho một sự đáp lại của sự gọi phương thức, mà sẽ hay là thông tin liên quan đến một yêu cầu hợp lệ hay một lỗi SOAP nếu sự triệu gọi thất bại Thuyết minh SOAP định nghĩa ba kiểu phần tử <Body>
<Body> Call chứa thông tin yêu cầu cho một phương thức gọi, chẳng hạn tên phương thức và tham số
<Body> Response chứa thông tin đáp trả cho một phương thức gọi thành công
<Body> Fault chứa mã lỗi và các thông tin khác cho một phương thức gọi không thành công
Call <Body>
Phần tử con đầu tiên của một phần tử <Body> Call là nhãn theo tên phương pháp Những phần tử nhúng Khi xếp theo thứ tự tham số, với mỗi tham số đặt tên theo dấu hiệu phương thức Chẳng hạn, trong phương thức gọi TranslationService có lẽ đã có một phương pháp với dấu hiệu C# sau đây:
string TranslateText(string SourceLanguage, string TargetLanguage, string Text)
Hình dung công dụng thông qua ví dụ sau:
// Translates an English sentence to French
string translatedText = TranslateText( "en", "fr", "I speak French" );
soap_callbody.xml, hiển thị một thông điệp SOAP tương ứng:
soap_callbody.xml: SOAP Call <body> example
Trang 14<Fault> trong <Body>
Khi một phương thức gọi lỗi, thay vì một <Body> Response bình thường, một bộ xử lý SOAP sẽ sử dụng một sự cố <Fault> trong <Body> của thông điệp SOAP đáp trả như trong
Thuyết minh SOAP định nghĩa các phần tử con sau:
Phần tử bắt buộc <faultcode> có thể được sử dụng bởi những ứng dụng cho thuật toán
tự động cho lỗi Những giá trị <faultcode> được định nghĩa trong một thái độ dễ mở rộng tương tự như 1xx, 2xx, 3xx, và sự đáp lại các mã HTTP cơ bản Tuy nhiên, thay vì những giá trị số những mã được định nghĩa khi những tên phân loại XML Dấu chấm dùng tách biệt các giá trị lỗi từ trái qua bên phải
Phần tử bắt buộc <faultstring> cung cấp một diễn giải có thể đọc được của một lỗi Phần tử tùy chọn <faultactor> cung cấp thông tin về lý do tại sao lỗi phát sinh bên trong đường dẫn message
Phần tử bắt buộc <detail> cung cấp chỉ định lỗi ứng dụng liên hệ với xử lý của phần tử
<Body> Một mục chi tiết, là một phần tử con tức thời của phần tử <detail>, phải là một tên hoàn toàn có đủ tiêu chuẩn
Các mã lỗi định nghĩa trong SOAP
Trang 15Máy chủ
hello.asmx, cho thấy một tập tin asmx dịch vụ Web Chương trình này không trả về gì hơn một chuỗi đến trình khách yêu cầu
hello.asmx: A simple Web Service
<%@ WebService Language="C#" Class="Hello" %>
Dịch vụ Web đặc biệt được cài đặt trong C#, nhưng chúng ta có thể cũng sử dụng bất
kỳ ngôn ngữ khác được xây dựng NET Framework, chẳng hạn như Visual Basic.NET Dòng đầu tiên trong hello.asmx khai báo rằng đây là một dịch vụ Web XML và đặt ngôn ngữ (C# trong trường hợp này) được dùng để cài đặt dịch vụ này Tiếp theo chúng tôi nhập khẩu không gian tên System.Web.Services và khai báo rằng lớp của chúng ta được dẫn xuất
từ lớp dựa trên WebService Cuối cùng, để chỉ báo rằng phương thức GetStockPrice của chúng ta sẽ có thể tiếp cận như một phần của dịch vụ, chúng tôi đánh dấu nó với thuộc tính tùy biến [WebMethod]
Để cho phép những ứng dụng trình khách để tiêu thụ dịch vụ Web này bạn cần để tạo
ra một lớp uỷ nhiệm DLL DLL này bao bọc tất cả mã và sự gọi trong dịch vụ Web có liên hệ vào trong một sự gọi phương thức đơn giản tương tự như một đối tượng COM Trong tài liệu NET Framework SDK, chúng ta sẽ sử dụng một công cụ được gọi là WebServiceUtil.exe để thực hiện nhiệm vụ này Sử dụng như sau:
WebServiceUtil /c:proxy /pa:http://localhost/Hello.asmx?SDL /n:nsHello
để phát sinh một lớp uỷ nhiệm gọi là Hello.cs Kế tiếp bạn cần biên dịch hello.cs vào trong một DLL vợi lệnh sau:
csc /out:Hello.dll /t:library /r:system.data.dll /r:system.web services.dll /r:system.xml.serialization.dll Hello.cs
Trình khách
Dịch vụ web hello.asmx có thể được truy nhập bởi một khách hàng mà thực hành để tiêu thụ những thông điệp SOAP Chẳng hạn, chúng tôi sẽ phát triển một trang ASP.NET đơn giản với ý định sử dụng dịch vụ web XML này
hello_client.aspx: An ASP.NET consumer of the Hello Web Service
<%@ Import Namespace="nsHello" %>
<html>
<script language="VB" runat="Server">