Xem mẫu
- BÀ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
239
- DCE. 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:
Ngôn ngữ Sự phức tạp khi Chi
Kiểu Nền tảng
hỗ trợ cấu hình phí
Soc UNIX (variants Khôn
C Cao
kets available) g
DCE UNIX C, C++ Cao Cao
CO Trung
UNIX, Windows Any Trung bình
RBA bình
Java Java (Java Virtual Khôn
Chỉ Java Thấp
RMI Machine) g
DC Khôn
Windows Rất nhiều Thấp
OM g
240
- II. Xây dựng ứng dụng liên quan đến nhiều nền tảng dựa vào Web service
Xây dựng các máy chủ
Trong nội dung này, chúng ta bàn luận các công cụ được sử dụng để tạo các máy chủ.
Visual Studio .NET
Chúng ta có thể, về mặt lý thuyết, tạo ra những phương thức HTTP GET và POST hay
những tập tin SOAP của chúng ta để chuyển yêu cầu qua lại giữa máy chủ và máy khách.
Tuy nhiên, khi một môi trường phát triển có thể hỗ trợ bạn bằng việc làm nhiều những nhiệm
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ủ.
UNIX và Linux
Những hệ điều hành khách và những nhà cung cấp ngôn ngữ qui định toolkits và những
môi trường phát triển để tạo ra dịch vụ web trên các nền tảng khác, bao gồm UNIX và những
hệ điều hành Linux. Những tùy chọn bao gồm những dịch vụ Web của IBM Toolkit và Java 2
Enterprise Edition ( J2EE).
J2EE cung cấp một vài API để hỗ trợ cho người phát triển ứng dụng dịch vụ Web trong bảng
sau:
API Diễn giải
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
JAXP: Java API ta vào trong từ vựng XML. Bạn có lẽ đã muốn làm điều này để,
for XML processing 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ị
vô tuyến.
Cung cấp khả năng để tạo ra những lớp Java từ dữ liệu XML và
JAXB: Java API một XML DTD hay giản đồ. Những lớp này tự động cung cấp khả
for mapping XML năng để làm cho có hiệu lực, sắp xếp và không sắp xếp dữ liệu XML
documents to Java 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
classes 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.
Cung cấp khả năng để tạo ra những tài liệu SOAP để chuyển
JAXM: Java
thông điệp giữa các hệ thống trong định dạng SOAP. API quản lý
API for messaging
những chi tiết như cú pháp SOAP và sự nhận ra thông báo.
JAXR: Java Hỗ trợ truy nhập đăng ký kinh doanh dựa trên internet. JAXR
API for XML API cung cấp khả năng để đăng ký một dịch vụ web với những nơi
registries đăng ký như UDDI.org.
Những sự hỗ trợ phát hành RPCs như yêu cầu và những tài
JAX-RPC: Java
liệu SOAP kết quả. JAX- RPC xử lý những chi tiết của sắp xếp và
API for issuing
không sắp xếp vào trong tài liệu SOAP JAX-RPC. JAX- RPC là một
RPCs via XML
API ít thông dụng hơn là JAXM. Nó không cung cấp tất cả các khả
documents
năng của JAXM, Việc bao gồm thông điệp không đồng bộ, thông
241
- API 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.
242
- Mễ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ổ.
Giao diện
Giao diện tham chiếu tới quá trình của việc nói tới Và điều khiển hệ thống thừa kế từ hệ
thống khác. Nếu chúng ta may mắn, những hệ thống thừa kế của chúng ta được thiết kế với
sự hợp nhất trong tâm trí, khi trong hệ điều khiển Thông tin Khách hàng IBM (CICS), như
vậy thì, giao diện cần phải một cách tương đối giải phóng sự đau đớn. Tính tương thích này
là khó khăn tiêu biểu với nhiều hệ thống thừa kế, tuy nhiên, và việc đưa một giao diện tới
chức năng đúng mức có thể là một nhiệm vụ khó khăn.
Phụ thuộc vào liệu có phải hệ thống thừa kế trong câu hỏi được thiết kế với tính có thể
kéo dài ra trong tâm trí, giao diện có thể cần nhiều thì giờ.
Tính Sẵn sàng
Các ứng dụng trên nền web phải hoạt động 24 giờ trên này, 7 ngày trên tuần. Những hệ
thống thừa kế của chúng ta, tuy nhiên, được có lẽ đã không có được phát triển với sự thiếu
này của những sự ràng buộc trong tâm trí. Những hệ thống trên nền máy tính lớn , như một
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
243
- xuyê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
244
- trọ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.
Cách tiếp cận Phân tầng
Một ứng dụng thừa kế có thể được chuẩn bị cho sự hợp nhất xuyên qua sự thi hành
của một mẫu kiến trúc phân tầng mà kể cả tính linh hoạt cực đại. Mẫu này bao gồm:
Lớp vận chuyển là lớp ở ngoài cùng thì chiụ trách nhiệm về sự tiếp nhận và sự trở lại
của XML- những thông báo định hình xuyên qua bất kỳ cái nào được đưa cho cơ chế truyền
thông.
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.
/* string used to hold string representation of
our service request XML message */
String xmlStr = "";
/* 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" )
{
245
- xmlStr += "" + name + "";
}
/* othewise use this form variable's name and value to
build a element */
else
{
xmlStr += "" +
Request.Form[ name ] + "";
}
}
xmlStr += ""
/* 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 */
Response.ContextType = "text/xml"
/* output the response XML message */
Response.Write( retXmlDoc.outerXml );
Trong sự cài đặt của lớp vận chuyển, đầu tiên chúng ta xây dựng một thông điệp XML
yêu cầu từ các biến HTTP POST. Chúng ta khởi tạo một thể hiện của) đối tượng
ServiceLayer được phát triển trong service_layer.cs và triệu gọi phương thức perform với
thông điệp XML yêu cầu như tham số nó. Cuối cùng mọi thứ được bỏ đi tới hiện thị thông
điệp XML đáp trả đến trình khách.
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.
Order
foobar
7843221
5
Tập tin sau là một ví dụ của sự cài đặt một lớp dịch vụ sử dụng thông điệp XML định
nghĩa trong sample_request.xml để triệu gọi dịch vụ được kế thừa:
service_layer.cs: Sample Service Layer.
using System.Xml;
public class ServiceLayer
{
public XmlDocument perform( XmlDocument params )
246
- {
/* 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" );
nav.MoveToNextSelected();
serviceName = nav.innerText;
/* string used to hold result of the method invocation */
string res = "";
switch ( serviceName )
{
case "Order" :
/* 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. */
try
{
string tranID = legacy.orderItem( customerID, itemID, qty );
res = "" + tranID + ";
}
catch ( Exception e )
{
res = "" + e.Message + ";
}
break;
case "History" :
/* retrieve the customerID parameter from the Params
in the XML document */
nav.Select( "//ServiceRequest/Param[@name='customerID']" );
nav.MoveToNextSelected();
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 + "" + tranID +
"";
}
247
- }
catch ( Exception e )
{
res = "" + e.Message + ";
}
break;
}
/* build and return result XML document */
XmlDocument resultDoc = new XmlDocument();
resultDoc.loadXml( "" + res +
"" );
return ( resultDoc );
}
}
Lớp bộ tích hợp thừa kế
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
an error occurred. */
public string[] getOrderHistory( string customerID )
{
/* insert your actual implementation here... */
}
}
}
BÀI TẬP VỀ NHÀ
1. Hãy xây dựng một ứng dụng thực tế liên quan đến nhiều nền tảng dựa vào
Web service
248
- BÀI 4
TÊN BÀI : LIÊN HỆ GIỮA XML VÀ .NET.
Mã bài : ITPRG3_15.04
Giới thiệu :
Trong nội dung bài học này chúng ta sẽ nghiên cứu sự liên hệ giữa XML và .NET cũng như
ứng dụng của XML trong nền tảng .NET.
Mục tiêu thực hiện:
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
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
, một phần tử tùy chọn , và một phần tử . 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ử
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.
Tất cả những thông điệp SOAP cần phải bao gồm những khai báo không gian tên thích
hợp để những ứng dụng SOAP có thể xử lý chính xác những thông điệp. Thuyết minh SOAP
định nghĩa hai không gian tên:
SOAP đượ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ử .
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 , tập tin sau là một ví dụ:
249
-
Phần tử đượ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ử 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ử được
liệt kê như sau:
Phần tử là tùy chọn , nhưng, nếu được ấn định, phài là phần tử con đầu tin
trong .
Phần tử 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 phải đủ khả năng không gian tên.
Phần tử 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 .
foo
an-encoded-password
mustUnderstand
Trong tập tin soap_header2.xml khái niệm của sự chứng thực của yêu cầu dịch vụ. Để
xác nhận rằng một dịch vụ hiểu và có thể xử lý một phần tử đặc biệt , bạn có thể
đánh dấu chỉ định những phần tử với thuộc tính SOAP-ENV:mustUnderstand.
Thuộc tính này chỉ ra tới một bộ xử lý tương hợp SOAP mà có liên hệ phần tử
phần tử với sự xử lý của của phương thức được gọi, nếu lý do nào đó bộ xử lý SOAP từ xa
không thể hiểu hay xử lý nó, bạn không muốn phương thức được gọi để thực thi.
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.
foo
an-encoded-password
actor
Khi một thông điệp SOAP hành trình từ bộ khởi đầu đến điểm đến cuối cùng của nó, nó
trực tiếp không cần hành trình giữa nguồn và nơi đến. Thông điệp có lẽ đã đi qua xuyên qua
250
- mộ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 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ử . 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ử liên hệ được dự định cho trạm nhận SOAP đầu tiên, trung gian hay cách
khác.
Phần tử 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ử đượ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ử
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ố.
Response chứa thông tin đáp trả cho một phương thức gọi thành công.
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
Phần tử con đầu tiên của một phần tử 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 example.
foo
an-encoded-password
en
fr
I speak French
Response
Response chứa đựng thông tin dịch vụ SOAP trả lại người gọi sau khi một sự
gọi phương pháp thành công.
soap_responsebody.xml: SOAP Rresponse example.
- SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
Je parle Francais
trong
Khi một phương thức gọi lỗi, thay vì một Response bình thường, một bộ xử lý
SOAP sẽ sử dụng một sự cố trong của thông điệp SOAP đáp trả như trong
ví dụ sau:
soap_faultbody.xml: SOAP in the .
SOAP-ENV:Server
Translator not found
014
No suitable Translator found for "en-fr" translation
Thuyết minh SOAP yêu cầu rằng phải là phần tử con đầu tiên của phần tử
.
Thuyết minh SOAP định nghĩa các phần tử con sau:
Phần tử bắt buộc 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ị đượ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 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 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 cung cấp chỉ định lỗi ứng dụng liên hệ với xử lý của phần tử
. Một mục chi tiết, là một phần tử con tức thời của phần tử , 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
Mã lỗi Nghĩa
VersionMis
Bộ xử lý tìm thấy một không gian tên sai cho phần tử SOAP.
match
Một phần tử đánh dấu với thuộc tính SOAP-
MustUnderst
ENV:mustUnderstand hoặc là không hiểu hay đúng mức tuân theo bởi
and
bộ xử lý.
Client Thông điệp không đúng được thành lập hay không chứa đựng
252
- Mã lỗi Nghĩa
thông tin thích hợp để thành công. Nói chung, thông báo không nên
được gửi lần nữa không có một vấn đề sự thay đổi sửa chữa.
Thông báo không thể được xử lý bởi bộ xử lý cho những lý do
Server không trực tiếp có thể quy cho đối với chính nội dung của thông điệp,
nhưng tới sự xử lý của thông điệp.
Phát triển các ứng dụng SOAP
Sử dụng các dịch vụ Web
ASP.NET hỗ trợ tuyệt vời để tạo ra những dịch vụ Web XML dựa vào các máy chủ
SOAP. Hỗ trợ những dịch vụ Web XML được cung cấp qua ASP.NET. Những tập tin asmx,
là tập tin văn bản, tương tự tập tin .aspx. Qua vài trang web tiếp theo chúng ta sẽ quan sát
một số ví dụ đơn giản xây dựng cả những trình khách lẫn máy chủ. Tất nhiên, sẽ tương tác
như những dịch vụ Web XML.
Má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.
using System;
using System.Web.Services;
public class Hello : WebService
{
[WebMethod] public String SayHello( String Name )
{
return ( "Hello " + Name );
}
}
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.
253
- Sub Greeting( Src as Object, E as EventArgs )
Dim h as New Hello
lblGreeting = h.SayHello( edtName.Value )
End Sub
Your name:
Trang ASP.NET này đầu tiên nhập khẩu lớp DLL uỷ nhiệm sử dụng không gian tên
được định nghĩa. Sự gọi thực tế tới dịch vụ Hello xảy ra trong thủ tục Greeting trong tập tin
HelloClient.aspx. Từ khóa New được dùng để khởi tạo đối tượng. Một lần được khởi tạo,
chúng tôi đơn giản triệu gọi phương thức SayHello để làm công việc.
Chúng ta hiểu rằng phương thức lập trình và kỹ thuật lập trình Microsoft, cách tiếp cận
này tương tự tới bạn sử dụng một đối tượng COM như thế nào. Đằng sau những gói DLL
lớp ủy thác dịch vụ Web phương thức của chúng ta được gọi trong một thông điệp SOAP và
chuyển chúng thông qua dịch vụ web của chúng ta để xử lý. Dịch vụ Web Hello phân tích
thông điệp SOAP và triệu gọi phương thức SayHello. Kết quả được đóng gói khi một thông
điệp đáp trả SOAP và một lần nữa đi qua bởi uỷ nhiệm phân loại DLL. Và tất cả thời gian
này bạn chỉ nghĩ rằng bạn đang làm một phương pháp gọi đơn giản!
Sử dụng các thành phần
Microsoft .NET Remoting cho phép cho những người phát triển sản xuất quản lý từ xa,
COM/COM+ tự nhiên, và những thành phần dịch vụ (Quản lý những thành phần dịch vụ bởi
những dịch vụ COM+. Cái gì làm sự cài đặt .NET quan trọng là những thành phần này được
xây dựng như điểm cuối SOAP từ bất kỳ trình xử lý nào, kể cả những ứng dụng console,
những ứng dụng GUI, những dịch vụ Windows NT, và IIS. Bởi vì họ được xây dựng trên tiêu
chuẩn này cho truyền thông, số lượng những ứng dụng mà cuối cùng giao diện với những
thành phần có thể đang gia tăng, và những cơ hội cho thành công trong những môi trường
hỗn tạp được tiến bộ.
Máy chủ
hello.cs, hiển thị một .NET đơn giản quản lý thành phần trưng bày phương thức
SayHello.
Trong hello.cs đối tượng Hello có thể được điều khiển từ xa bằng việc mở rộng lớp
MarshalByRefObject. Cái này cho phép phương thức SayHello sẽ được truy nhập thông qua
SOAP khi đối tượng này được phơi bày bởi một chủ nhà thích hợp mà đóng vai điểm cuối
SOAP. hello_host.cs thể hiện sự xây dựng một dịch vụ chờ đợi một kết nối. Người sử dụng
có thể dừng dịch vụ, bằng cách ấn phím Enter.
hello.cs: A managed component.
using System;
namespace nsHello
{
/* Define the Service */
public class Hello : MarshalByRefObject
{
/* This method will be called remotely by our client */
public String SayHello( String Name )
{
return ( "Hello " + Name );
}
}
254
- }
hello_host.cs: Creates a service listening for connections.
using System;
using System.IO;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels.HTTP;
public class HelloHost
{
public static void Main( String[] args )
{
/* Manually load the http channel. 1099 is the port # */
ChannelServices.RegisterChannel( new HTTPChannel( 1099 ) );
/* Register the wellknown server type */
RemotingServices.RegisterWellKnownType(
"nsHello", // Assembly
"nsHello.Hello", // Full type name
"host/Hello.soap", // URI
WellKnownObjectMode.Singleton ); // Object Mode
/* Wait until the user wants to exit */
Console.WriteLine( "Listening for requests - Press ENTER to exit" );
String keyState = Console.ReadLine();
}
}
Trong những thông báo .NET Framework được chuyển qua lại từ đối tượng điều khiển
thông qua Channels Objects gói gọn những giao thức mạng nằm bên dưới tạo sự kết nối
trình khách/máy chủ. Trong hello_host.cs, chúng tôi muốn sử dụng Kênh HTTP gắn sẵn, mà
những sự vận chuyển truyền tin sử dụng giao thức SOAP.
makefile: Một tập tin biên dịch cho hello_host.cs và hello.cs.
all: hello_host.exe hello.dll
hello_host.exe: hello_host.cs
csc /r:System.Runtime.Remoting.dll hello_host.cs
hello.dll: hello.cs
csc /t:library hello.cs
Trình khách
Bây giờ, máy chủ được tạo ra chúng ta có thể tập trung vào trình khách. Tập tin
hello_client.cs là một ứng dụng mà sẽ tiêu thụ dịch vụ được phơi bày bởi hello_host.cs của
chúng ta để triệu gọi phương thức từ xa SayHello.
hello_client.cs: Một người tiêu dùng của hello_host.cs
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels.HTTP;
using nsHello;
public class HelloClient
{
public static Main( String[] args )
{
/* Obtain a Proxy to the SOAP URL */
Hello h = (Hello)Activator.GetObject(
typeof(Hello),
"http://localhost:1099/host/Hello.soap" );
/* The following occurs over SOAP to HelloHost */
Console.WriteLine( h.SayHello( "Dick" ) );
}
}
255
- Trong hello_client.cs chúng ta sử dụng phương thức GetObject thay vì từ khóa mới để
kích hoạt đối tượng từ xa bởi vì chúng tôi bằng tay đang kích hoạt đối tượng. Chúng tôi đã
chưa sử dụng hồ sơ cấu hình từ xa, chúng tôi có thể đã sử dụng từ khóa New tới cùng hiệu
ứng.
Với ví dụ trước đây, chúng ta cần biên dịch ứng dụng. Lệnh sau sẽ biên dịch tập tin
hello_client.cs:
csc /r:System.Runtime.Remoting.dll /r: hello.dll hello_client.cs
Một khi cả máy chủ lẫn những ứng dụng trình khách được xây dựng, chúng tôi có thể
kiểm tra chúng bởi lần đầu tiên chạy hello_host.exe trong một cửa sổ và sau đó chạy
hello_client.exe trong cửa sổ khác. Bạn sẽ nhìn thấy hello_client.exe đáp ứng với một thông
điệp “Hello Dick” trên màn hình.
II. Cài đặt các ứng dụng hướng e-Business bằng Biztalk Server
Trừ khi chúng ta đang làm việc cho một doanh nghiệp dot-com thuần túy, chúng ta có lẽ
cho phép dữ liệu cư trú trong một số cơ sở dữ liệu cũ hơn, bên trong những tập tin phẳng
(flat files), hay loại tài nguyên khác nào đó. Nếu đây là trường hợp, và bạn vẫn còn có một
nhu cầu tới sự truy nhập, cập nhật, và dùng dữ liệu này, bạn có lẽ đã tìm thấy chính bạn
giáp mặt với sự thực hiện và tính linh hoạt chảy ra. Những hệ thống đơn giản có lẽ đã không
có những phương pháp thích hợp của việc truy nhập và sử dụng dữ liệu những ứng dụng.
Qua vài mục tiếp theo chúng tôi sẽ bàn luận những ứng dụng của BizTalk và nó có thể
được dùng giải quyết những vấn đề này. Chúng tôi sẽ nói về sự hợp nhất ứng dụng doanh
nghiệp, sự hợp nhất từ doanh nghiệp tới doanh nghiệp (business-to-business) (B2B) và tự
động hóa qui trình nghiệp vụ.
Muốn đọc một số nghiên cứu tình huống thế giới thực của BizTalk đã được sử dụng
như thế nào cho sự thi hành và giải quyết thể hiện khác nhau này? Kiểm tra tại địa chỉ
http://www.microsoft.com/biztalk/evaluation/casestudies để xem danh sách các công ty và tài
liệu trên cài đặt của chúng.
Sự tích hợp ứng dụng doanh nghiệp
Trong một thế giới kỹ thuật nơi nhiều lập trình viên Java, C#, hay ngôn ngữ kịch bản
(scripting) nào đó đại diện cho tất cả các phương pháp luật và là người có những hệ thống
cũ nhất đó là Windows 98 hay Windows NT 4. Kết quả tìm kiếm COBOL,nNhững máy tính
lớn, một hệ thống bộ nhớ ảo (Virtual Memory System - VMS), sự vận hành trên sự mở rộng
địa chỉ ảo (Virtual Address eXtension - VAX), và những màn ảnh trên nền văn bản đóng vai
xương sống tới những toàn bộ doanh nghiệp có thể là bình thường, một cách đặc biệt trong
những công ty lớn. Những hệ thống gia tài này là sự yên tĩnh rộng rãi được dùng, được triển
khai, và phụ thuộc vào cho những hoạt động doanh nghiệp đang diễn ra.
Trên tất cả mọi thứ khác, bộ máy chủ BizTalk của những ứng dụng được thiết kế cho sự
dễ dàng của sự hợp nhất. Nó sử dụng những tiêu chuẩn công nghiệp nặng nề, tương tự
XML, SOAP, và BizTalk Framework. Nó cung cấp những công cụ cho phép chúng ta để tạo
ra những sự trình bày XML của dữ liệu thừa kế các bạn và sự truy nhập và sự sử dụng dữ
liệu đó phối hợp. Điều này giảm bớt sự hợp nhất của các bạn vào trong hệ thống thừa kế để
đơn giản hỗ trợ một số đặc tính XML cơ bản, và BizTalk sẽ cầm lấy nó từ điểm đó.
Thừa kế dữ liệu, tuy nhiên, là không phải dữ liệu duy nhất mà với BizTalk có thể truyền
thông và số nguyên. Thật ra, những điều này của chung ta tạo ra dịch vụ web dựa trên nền
tảng XML như vỏ bìa trong cuốn sách này, chúng ta có lẽ đã tìm thấy máy chủ phục vụ
BizTalk là hệ thống hoàn hảo để xử lý sự xử lý của những thông điệp.
Sự tích hợp doanh nghiệp-đến-doanh nghiệp
Tích hợp với những ứng dụng bên trong là chỉ có một kiểu của sự cài đặt hữu ích cho
máy chủ BizTalk. Nhiều doanh nghiệp được xây dựng những hệ thống nền tảng XML hay
những giao diện mà cho phép chúng tự động hóa truyền thông của chúng và sự trao đổi với
khách hàng và những công ty đối tác. Ví dụ, một công ty bán lẻ có lẽ đã thu được những sự
mô tả sản phẩm và đặt giá trong một khuôn dạng XML. Việc sử dụng máy phục vụ BizTalk là
khả năng vẽ bản đồ một mô hình tới người khác, bạn có thể cảm thấy tin cậy rằng bạn có
thể thiết kế những mô hình của riêng mình để đúng đối với doanh nghiệp của chúng ta, và
tuy thế không giới hạn sự hợp nhất của chúng ta với những đối tác.
256
- BizTalk Mapper chiết tự cho phép chúng ta vẽ những đường thẳng giữa những phần tử
và những thuộc tính của hai mô hình, với kết quả là một tờ kiểu XSLT mà sẽ thay đổi dữ liệu
của đối tác của chúng ta vào trong một khuôn dạng tới hệ thống của chúng ta. Khả năng này
cho phép bạn để xây dựng một giải pháp nền tảng XML bên trong công ty của chúng ta.
Tự động hóa quá trình kinh doanh
Tự động hóa quá trình kinh doanh được di chuyển tới mặt trước trong hôm nay là kinh
tế. Nếu một công ty thì có thể giảm bớt thời gian và những chi phí được liên quan đến một
nhiệm vụ đặc biệt, như sự kiểm tra kiểm kê, lợi tức của công ty có lẽ đã không tăng, trừ phi
nó đã giảm bớt những chi phí hàng đáy của nó và những lợi nhuận như vậy đang gia tăng.
Tự động hóa có thể là một sự chuyển động vô cùng quan trọng và cất giữ chi phí cho công
ty, một cách đặc biệt khi những tài chính là một sự liên quan chính.
BizTalk Orchestration Designer, cùng với Messaging Manager, BizTalk mang tới một
bảng trực quan là phương pháp dựa trên trực quan để thiết kế, tiến bộ, và tự động hóa qui
trình nghiệp vụ này. Với những công cụ này chúng có thể thiết kế những toàn bộ quá trình
để xử lý những yêu cầu đầu vào hay những tài liệu và tạo ra những hồ sơ chương trình mà
có thể được xử lý và theo dõi.
III. Truy cập dữ liệu và XML
Trước khi có Windows.NET, OLEDB và ActiveX Data Objects (ADO) là API chính cho
việc truy cập dữ liệu trong Microsoft Windows. Với sự ra đời của .NET, Microsoft giới thiệu
một nhánh mô hình mới để truy cập dữ liệu gọi là ADO.NET, nó hỗ trợ mô hình truy cập dữ
liệu và chức năng hoàn hảo cho đa tầng, môi trường web phân tán.
Tất cả ba mô hình đối tượng truy nhập dữ liệu, OLEDB, ADO, và ADO.NET, cung cấp
những mức khác nhau hỗ trợ XML. Trước tiên chúng ta khảo sát qua ba mô hình và sự hỗ
trợ cho XML của chúng.
OLEDB và ADO
Cả hai OLEDB và ADO đều dựa vào công nghệ COM. OLEDB cung cấp một mức thấp
và phương pháp hiệu quả cao của việc truy nhập và thao tác dữ liệu có quan hệ, trong khi
ADO được xây dựng trên OLEDB, cung cấp một phương tiện dễ dàng hơn để sự truy nhập
dữ liệu. Sự hỗ trợ XML trong ADO được cung cấp xuyên qua Recordset Persitence và được
thực hiện bởi Microsoft OLE DB Persistence Provider. Nhà cung cấp này có tạo một đối
tượng ADO Recordset, phát sinh một tài liệu XML và thông tin giản đồ liên quan, và lưu trữ
mọi thứ vào một stream hay tập tin. Tương tự, bộ cung cấp này còn có thể phát sinh một đối
tượng Recordset chỉ đọc và chỉ tiến từ một tập tin XML hoặc một stream.
Ví dụ dưới đây cho thấy chúng ta có thể tạo một đối tượng Recordset để tạo ra tập tin
XML như thế nào.
ADORecordset2XML.cs: Persisting an ADO Recordset object to an XML file.
using System;
using System.Data;
using System.Data.SQL;
public class ADORecordset2XML
{
public static void Main( String[] args )
{
try
{
String connString = "provider=SQLOLEDB;" +
"initial catalog=pubs;" +
"server=localhost;" +
"uid=sa;" +
"pwd=";
String queryString = "select * from titles";
/* Instantiate a Recordet object */
ADODB.Recordset rs = new ADODB.Recordset();
/* Connect to the database and execute a SQL query */
rs.Open( queryString, connString,
257
- ADODB.CursorTypeEnum.adOpenStatic,
ADODB.LockTypeEnum.adLockReadOnly, 0 );
/* Export Recordset to "titles.xml" file in XML format. */
rs.Save( "titles.xml", ADODB.PersistFormatEnum.adPersistXML );
/* close the Recordset object */
rs.Close();
}
catch ( Exception e )
{
Console.WriteLine( "Exception: {0}", e.ToString() );
}
}
}
Trong ví dụ trên, chúng ta tạo ra tập tin titles.xml, trong ví dụ dưới đây, chúng ta sẽ xem
xét việc tạo đối tượng Recordset từ tập tin titles.xml ở trên.
XML2ADORecordset.cs: Recreating the Recordset object from the titles.xml file.
using System;
using System.Data;
using System.Data.SQL;
public class XML2ADORecordset
{
public static void Main( String[] args )
{
try
{
String connString = "provider=SQLOLEDB;" +
"initial catalog=pubs;" +
"server=localhost;" +
"uid=sa;" +
"pwd=";
Int32 adCmdFile = 256;
/* Instantiate Recordset object */
ADODB.Recordset rs = new ADODB.Recordset();
/* Open the titles.XML file into Recordset object */
rs.Open( "titles.xml", connString,
ADODB.CursorTypeEnum.adOpenForwardOnly,
ADODB.LockTypeEnum.adLockReadOnly,
adCmdFile );
/* Display the value of the price field for the first record */
rs.MoveFirst();
Console.WriteLine( rs.Fields[ "price" ].Value );
/* close the Recordset object */
rs.Close();
}
catch ( Exception e )
{
Console.WriteLine( "Exception: {0}", e.ToString() );
}
}
}
XML sự hỗ trợ trong ADO hạn chế để nói là bé nhất. Bạn có thể chỉ vẫn tạo và xây dựng
lại những đối tượng Recordset qua lại giữa tập tin XML và stream. Tập tin XML vẫn tách biệt
với đối tượng Recordset cũ và bất kỳ sự thay đổi nào mà chúng ta tạo ra sẽ không được thể
hiện một cách tự động.
ADO.NET
258
nguon tai.lieu . vn
