Giáo trình Tích hợp các ứng dụng trên web qua XML (Phần 2)

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ữ

hỗ trợ

Sự phức tạp khi

cấu hình

Chi

Kiểu

Nền tảng

phí

g

Soc

UNIX

available)

(variants

Khôn

C

Cao

kets

DCE

CO

UNIX

C, C++

Any

Cao

Trung

UNIX, Windows

Trung bình

RBA

RMI

OM

bình

g

Java

DC

Java (Java Virtual

Machine)

Khôn

Chỉ Java

Thấp

Windows

Rất nhiều

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

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.

JAXM:

API for messaging

Java

JAXR:

for

registries

Java

Hỗ trợ truy nhập đăng ký kinh doanh dựa trên internet. JAXR

XML API cung cấp khả năng để đăng ký một dịch vụ web với những nơi

đăng ký như UDDI.org.

API

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à

không sắp xếp vào trong tài liệu SOAP JAX-RPC. JAX- RPC là một

API ít thông dụng hơn là JAXM. Nó không cung cấp tất cả các khả

năng của JAXM, Việc bao gồm thông điệp không đồng bộ, thông

API

for

via

issuing

XML

RPCs

documents

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.

<%@ import namespace="System.Xml"%>

/* 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" )

{

245

xmlStr += "<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 */

Response.ContextType = "text/xml"

/* output the response XML message */

Response.Write( retXmlDoc.outerXml );

</script>

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.

<?xml version="1.0"?>

<ServiceName>Order</ServiceName>

<Param name="customerID">foobar</Param>

</ServiceRequest>

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 = "<TransactionID>" + tranID + </TransactionID>";

}

catch ( Exception e )

{

res = "<Fault>" + e.Message + </Fault>";

}

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 + "<TransactionID>" + tranID +

"</TransactionID>";

}

247

}

catch ( Exception e )

{

res = "<Fault>" + e.Message + </Fault>";

}

break;

}

/* build and return result XML document */

XmlDocument resultDoc = new XmlDocument();

resultDoc.loadXml( "<ServiceRequestResponse>" + res +

"</ServiceRequestResponse>" );

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À

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

1.

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 <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-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/

encoding/">

<SOAP-ENV:Header>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

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 <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ụ:

249

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>.

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/

encoding/"/>

<SOAP-ENV:Header>

<a:Authentication xmlns:a="some-URI">

<Password>an-encoded-password</Password>

</a:Authentication>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

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 <Header>, bạn có thể

đánh dấu chỉ định những phần tử <Header> 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ử <Header>

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.

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Header>

<a:Authentication xmlns:a="some-URI" SOAP-ENV:mustUnderstand="1">

<Password>an-encoded-password</Password>

</a:Authentication>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

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 <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.

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Header>

<a:Authentication xmlns:a="some-URI" SOAP-ENV:mustUnderstand="1">

<Password>an-encoded-password</Password>

</a:Authentication>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<m:TranslateText xmlns:m="some-URI">

<Text>I speak French</Text>

</m:TranslateText>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

<Body> Response

<Body> 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 <Body> example.

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

251

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:TranslateTextResponse xmlns:m="some-URI">

<Text_fr>Je parle Francais</Text_fr>

</m:TranslateTextResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

<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

ví dụ sau:

soap_faultbody.xml: SOAP <Fault> in the <Body>.

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<SOAP-ENV:Fault>

<faultcode>SOAP-ENV:Server</faultcode>

<faultstring>Translator not found</faultstring>

<e:ErrorCode>

014

</e:ErrorCode>

<e:ErrorMsg>

No suitable Translator found for "en-fr" translation

</e:ErrorMsg>

</detail>

</SOAP-ENV:Fault>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Thuyết minh SOAP yêu cầu rằng <Fault> phải là phần tử con đầu tiên của phần tử

<Body>.

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

Mã lỗi

Nghĩa

VersionMis

match

Bộ xử lý tìm thấy một không gian tên sai cho phần tử SOAP.

Một phần tử <Header> đánh dấu với thuộc tính SOAP-

ENV:mustUnderstand hoặc là không hiểu hay đúng mức tuân theo bởi

bộ xử lý.

MustUnderst

Client

and

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

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.

Server

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.

<%@ WebService Language="C#" Class="Hello" %>

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.

<%@ Import Namespace="nsHello" %>

<html>

253

Sub Greeting( Src as Object, E as EventArgs )

Dim h as New Hello

lblGreeting = h.SayHello( edtName.Value )

End Sub

</script>

<body>

Your name:

<ASP:INPUT ID="edtName" TYPE="Text" RUNAT="Server"/><br/>

<ASP:BUTTON TEXT="Say Hello!" onclick="Greeting"/>

</form>

</body>

</html>

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",

"nsHello.Hello",

"host/Hello.soap",

// Assembly

// Full type name

// 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