Cơ Chế Xác Lập Ứng Dụng Liên Quan Đến Nhiều Nền Tảng.

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

Kiểu

Nền tảng	Ngôn ngữ hỗ trợ	Sự phức tạp khi cấu hình	Chi phí
Soc kets	UNIX (variants available)	C	Cao	Khôn g
DCE	UNIX	C, C++	Cao	Cao
CO RBA	UNIX, Windows	Any	Trung bình	Trung bình
Java RMI	Java (Java Virtual Machine)	Chỉ Java	Thấp	Khôn g
DC OM	Windows	Rất nhiều	Thấp	Khôn g

Có thể bạn quan tâm!

Xem toàn bộ 258 trang tài liệu này.

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
JAXP: Java API for XML processing	Cung cấp khả năng cho cả hai nền xử lý dựa trên cây (DOM) hay trên nền xử lý sự kiện (SAX) của dữ liệu XML. API cũng cung cấp sự hỗ trợ XMLTs giúp chuyển đổi những tài liệu XML của chúng ta vào trong từ vựng XML. Bạn có lẽ đã muốn làm điều này để, chẳng hạn, thay đổi dữ liệu XML tới HTML cho màn hình trong một bộ duyệt web, hay rút những thành phần của một tài liệu XML và áp dụng những gói WML cho màn hình trên màn ảnh của một thiết bị vô tuyến.
JAXB: Java API for mapping XML documents to Java classes	Cung cấp khả năng để tạo ra những lớp Java từ dữ liệu XML và một XML DTD hay giản đồ. Những lớp này tự động cung cấp khả 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 từ một thể hiện tài liệu XML. Từ một tài liệu XML bạn có thể tạo ra một cái cây đối tượng Java để xử lý bởi người dịch vụ web của chúng ta.
JAXM: Java API for messaging	Cung cấp khả năng để tạo ra những tài liệu SOAP để chuyển thông điệp giữa các hệ thống trong định dạng SOAP. API quản lý những chi tiết như cú pháp SOAP và sự nhận ra thông báo.
JAXR: Java API for XML registries	Hỗ trợ truy nhập đăng ký kinh doanh dựa trên internet. JAXR 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.
JAX-RPC: Java API for issuing RPCs via XML documents	Những sự hỗ trợ phát hành RPCs như yêu cầu và những tài 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 đ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.

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

{

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 )

{

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