Click here to Skip to main content
Click here to Skip to main content

Heterogenous Environments and Platform Independant Data Access

, 11 Jan 2006
Rate this:
Please Sign up or sign in to vote.
An article on designing heterogeneous environments and client independent platforms.

Introduction

Every theoretical work exists because of practical necessity.

Most mission-critical corporate data resides in diverse data stores on a variety of computing platforms. Thus, successful enterprise solutions must be able to function in heterogeneous environments and access data regardless of form or location.[1]

There are few existing technologies that provide platform independent collaboration: CORBA, .NET Remoting, and a few less popular which are not considered within this article.

The Common Object Request Broker Architecture (CORBA) is a specification of a standard architecture for object request brokers (ORBs). A standard architecture allows vendors to develop ORB products that support application portability and interoperability across different programming languages, hardware platforms, operating systems, and ORB implementations. [2]

Universal Data Access (UDA) is Microsoft's model or framework for a single uniform application program interface to different software makers' databases, both relational and non-relational. UDA is the database access part of Microsoft's Component Object Model (COM), an overall framework for creating and distributing object-oriented programming programs in a network. UDA consists mainly of the high-level interface, ActiveX Data Objects (ADO), and the lower-level services called OLE DB. IBM, Oracle, and other companies have provided database bridges that interface with OLE DB. [1]

There are pros and cons for each of the existing methods, but they all have the same imperfection: the technology must be used over the entire application. By stating this, I mean that the implementation of a server application using CORBA and a client application using .NET Remoting at least needs to be avoided (I suppose that this is absolutely clear for the reader).

The article is not aimed to propose a new platform independent technology, but an approach to implement a complex heterogeneous method in Designing Service-Oriented Occasionally Connected Smart Client Applications [1], which is based on existing platform independent tools: Sockets, Web Services, and XML.

Business oriented applications

The most common requirement to business applications is a client independent transactions server, and a client application adapted for Pocket PCs, laptops, Cell Phones and Personal Computers. Implementation for each platform may significantly vary. For instance, the Pocket PC client is allowed to enter data only, and PC client can run reports and perform system settings update. Need to remember that client computers can have different processor types, operating system, and screen size (the last distinction impacts the application even on a UI design level). In the same time, the applications should operate within a common database. Therefore, developers obtain a more complex task, which is not only to provide correct transactions handling logic but also, to guarantee the possibility to expand the client applications on different platforms in a fast and efficient manner.

Consider a fast growing company that provides technical services for their clients. At the moment, 250 technicians are hired by this company. The flow of the company’s operations is:

  1. A client reports the company about the issue raised.
  2. A call center operator assigns a technician on the job
  3. The technician goes to the client to fix the issue.
  4. A manager tracks the issue (runs reports).

You can see that each step is separated between different persons, each of them operates with different platforms: the manager has a laptop with the Linux operating system, the call center operator is using a PC with Windows 98 OS, and the technician is using a Pocket PC device with Microsoft Windows Mobile 2005 installed.

As developers create complex Business Logic server applications, they might transfer the responsibility of client applications development to third parties, or perform it independently from the main server part. In this case, they must define an API access to the open server’s logic.

Data Exchange

There are two methods of data transfer between computers that can be distinguished by:

  • High abstract level methods (Remote Procedure Calls, .NET Remoting, Web Services, direct HTTP Requests.....).
  • Low abstract level (sockets).

Each of the ways has its own strong and weak sides. Herein, I shall try to explain which of the existing methods is more convincing than the other, and start with the low abstract level data exchange method first.

Socket Data Changes

Sockets stand at the bottom of the TCP/IP protocol description. We must admit that this is an absolutely platform independent method of data transferring, but the single problem that must be considered is Firewalls. Therefore, deployment of an application that uses sockets might be very painful, as on each machine, we will have to manually update firewall settings. Also, there are many exceptional situations while programming sockets which have to be handled properly. Nevertheless, sockets might successfully be used during the implementation of heterogeneous environments.

Windows Services might be a good example of a system implementation via sockets. Let's consider that we have created a Windows Service that runs every time when the computer starts and works like a listener on port 2142. Client computers can connect via socket connections and perform database calls.

Web Services

A web service is the technology that uses the XML format of data transferring between clients and the server via the HTTP protocol. That's its main advantage over all other communication protocols. This standard which developed rapidly is supported by all existing forth generation object oriented programming languages and technologies.

Data exchange is performed via an HTTP request to the HTTP Server where the Web Service is running. All requests and responses are converted into SOAP format and transferred between the server and the client.

SOAP (Simple Object Access Protocol) is a protocol specification for invoking methods on servers, services, components, and objects. SOAP codifies the existing practice of using XML and HTTP as a method invocation mechanism. The SOAP specification mandates a small number of HTTP headers that facilitate firewall/proxy filtering. The SOAP specification also mandates an XML vocabulary that is used for representing method parameters, return values, and exceptions.

This facility caused an increase in the command size, but as speeds of network hardware raised noticeably, this issue could be ignored in applications for small and mid-size businesses.

Summarizing, we may state that each approach may be classified using the following constraints:

  • Value oriented
  • Implementation speed oriented

One more thing that we have to underline is that HTTP requests are not declined by firewalls.

Data Storage

The next feature that we need to describe here is - that the same server can be easily modified in order to operate with any data source. No matter if it is an MS SQL Server database, Oracle database, a binary file or any client’s data storage, the server API doesn’t change. Therefore, by the client needs and the project’s budget, the client obtains a system which suits the requirements better.

According to the design pattern, Low Cohesion, it is recommended that the API server provides only a single method for data request. This feature guarantees that we are able to perform all required service operations (requested logging, tracing, security verifications ...) over every request.

Data Content

String queries have one issue that should be considered as critical for the transport protocol – it is a simple text format which can be interpreted not only by machine but by a human, too. Let’s consider the following code extracted from an XML query:

<AssignmentQueryData RequestID="string">
 <AssignmentQueryRecord>
  <Progress>Closed</Progress>
  <AssignmentID>123123</AssignmentID>
  <EmployeeCode>JOE</EmployeeCode>
  <JobID>4123</JobID>
  <CallID>12312</CallID>
  <Scheduled>2005-12-01T13:20</Scheduled>
  <ActualTime>2005-12-01</ActualTime>
  <ActualDuration>2:00</ActualDuration>
  <Notified>2005-12-01T13</Notified>
  <Dispatched>2005-12-01T13</Dispatched>
  <Onsite>2005-12-01T13</Onsite>
  <Completed>2005-12-01T13</Completed>
  <MileageIn>123</MileageIn>
  <MileageOut>123</MileageOut>
  <JobNo>12312</JobNo>       
  <LocationID>3213</LocationID>

As you can see, this code can be easily read by any human/machine. As the data transferring is performed via the TCP/IP protocol, any HTTP analyzer tool can easily intercept this information. Therefore, security is an issue in this type of data transfer.

There are two ways of securing the data:

  • XML Encryption
  • Access level grants

My assumption is that both methods have to be implemented. The recommended data encryption is using SSL (or any other encryption system). Access level grants are implemented on the data level and processed by the Business Logic server.

XML Requests

The XML command set is divided into three types of requests:

  • General Requests
  • Master Requests
  • Connection Requests

General Requests

General requests require no validation or security. These requests do not access any sensitive information. Connect is an example of a general request.

<ConnectRequest Version="string" 
         RequestID="string">
  <Connect>
    <AgentName>CompanyName</UserName>
    <AgentPassword>123123-370E-4CC9-9518-274CFD7FB108</Passsword >
  <Connect >
</ConnectRequest >

Connection Requests

Connection requests can only be submitted after a valid connection has been established. The XML for connection requests consists of a Command node wrapped in the ConnectionRequest node.

Connect” must be submitted before submitting connection requests. Connect is a general request and will validate an agent access to the database system. Upon validation, Connect will return a ConnectionID. This ConnectionID is required for all subsequent connection requests.

Usually, in multi-tier applications, we must distinguish between connection and sessions. Sessions are opened for a single user, while the connection exists for the server. This is a good practice, as we may control all clients that obtain access via the same data client server.

The business implementation can be the following: we have a single data server, Pocket PC and Smart PC clients. For each type of the client, we define their own server application. Therefore, we can measure the access for a single type of user providing access for a server.

Having a single server for each client is vitally important as the business clients might have different traffic loads, and they can implement their own business oriented operations without impact on the main business data server.

< ConnectionRequest Version="string" 
       ConnectionID="{123123-370E-4CC9-9518-274CFD7FB108}"
       RequestID="string">
  <BeginSession>
    <UserName>TIM</UserName>
    <Passsword>123123-370E-4CC9-9518-274CFD7FB108</Passsword >
    <ClientID>12312</ ClientID >
  <BeginSession>s
</ ConnectionRequest >

Attribute Name

Attribute Description

Version

Command query version

ConnectionID

Valid client server connection identity

RequestID

Request identity

Session Requests

Session requests can only be submitted after a valid session has been established. The XML for session requests consists of a Command node wrapped in a SessionRequest node. “BeginSession” must be submitted before submitting session requests. BeginSession is a connection request and will validate user access to the company data system database determined by the connection. Upon validation, BeginSession will return a SessionID. This SessionID is required for all subsequent session requests.

<SessionRequest Version="string" 
       SessionID="string" RequestID="string">
  <WarrantyQuery Filter="string" Max="string"
       OrderBy="string">
    <LocationUnitID>123123</LocationUnitID>
  </WarrantyQuery>
</SessionRequest>

Attribute Name

Attribute Description

Version

Command query version

SessionID

Valid session identity

RequestID

Request identity

XML Response

The response format should also be standardized to be easily implemented. We may ignore an XML access level, as this information is needed only when we perform a data request.

The format may be the following:

<SessionResponse Successful="true" 
      ResultCode="000" ResultText="Successful"
      RequestID="string">
  <WarrantyQuery>
    <StartDate>12-17-2001T12:00</StartDate >
    <Quantity>4</Quantity>
    <EndDate>12-17-2005T12:00</EndDate>
  </WarrantyQuery>
</SessionResponse>

Attribute Name

Attribute Description

Successful

Specifies whether the request succeeded

ResultCode

Returns error code

ResultText

Short error description if any

RequestID

Returns request identity

Summary

Within this article were considered business requirements of heterogeneous business applications. The most popular existing platforms were briefly considered. As a solution to the problem of client independent business applications was proposed a method of system architecture which allows manufacturing of such systems. The method is based on using Web services/ Sockets as the server application part and XML as an inner format of transferring data. The main issue of the approach considered was data security related. Implementation of additional security features on both steps of data processing: data retrieving and data transferring, was proposed.

I do not consider this a standard of application development. My assumption is that each organization that deploys computer based business solutions must have their own (or bought) framework of thsi type.

This approach can be standardized to CMSs (Content Management System) which can be built successfully.

Bibliography

  1. MSDN
  2. SEI: Object Request Broker

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Share

About the Author

Kyrylo Yatsenko
Web Developer SOCIETE GENERALE CREDIT INVESTMENT BANKING
France France
Kyrylo has started his IT career as software developer. Shortly he became Team Lead developer leading the projects based on MS .NET Framework technology.
 
Today he is working for SOCIETE GENERALE CIB, trying to combine his experience of software developer with bank's activities on electronic markets.

Comments and Discussions

 
GeneralInterprocess communications between Java app and .NET app on same machine PinmemberJohn Obremski12-Jun-09 10:15 
GeneralConnect Access in pocket pc 2005 [modified] PinmemberThai Duong Nguyen7-Nov-06 16:41 
I am from to VietNam and i have some problem.
 
I want to coonect with ms access, but i only new begin and i don't known for it. Please help me or give for me some sample projects.
 
Thank very much.
 
My mail address is thaiduongitc198@yahoo.com.vn
GeneralRe: Connect Access in pocket pc 2005 PinmemberKirill Yatsenko9-Nov-06 12:14 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.141216.1 | Last Updated 11 Jan 2006
Article Copyright 2006 by Kyrylo Yatsenko
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid