UNIX was not designed to stop people from doing stupid things, because that would also stop them from doing clever things.
- D. Gwyn
Chapter 3
3. Design
This chapter outlines our fundamental design rationale of WSNFS, with an emphasis on the provision of SOAP base Remote System Call. The chapter begins by presenting key design goals, and explains the advantage of using soap to marshalling remote system call. The chapter then shows an overview of high level design decisions that shape the overall WSNFS structure and usage.
3.1. Goals
It is helpful to describe the design goals, before moving on to the main task. Because of the following goals drive the design of our WSNFS architecture. In view of having similar situation in Grid computing and mobile computing, we mention in section 1.5, let us then try to solve those issues at the same time.
z Global Access – A global file system should behave the same, no matter which client a person uses to access his/her files. We can access to data anytime, anywhere in the world, independent of location and the semantics of the operations should not change. Because of servers grant access to users, not to clients. Users can have accounts on each independently administered server.
z Application Transparency - Users should use the same type of access mechanisms for both local and remote (WSNFS) resource.
z Mobile transparency – When mobile user is switched the to another IP address or location use different access point, the connection will be re-established on the next operation to the new environment. All of this is done quietly and automatically, with no interaction needed from the user and without noticing to or impact on the user.
z Cross-platform interoperability - Cross Platform Web services Development Using XML is the practical, hands-on introduction to using SOAP on Windows, Linux, and UNIX platforms, using any of five leading programming languages.
z Low Administrator overhead –User-level implementation, configuration and installation of WSNFS should require little or no system administrator invention, to enforce easy of accessibility and promote sharing.
z Reduce network traffic – To reduce the amount of small request by delay
updating the metadata cache of the client. We use a modeless asynchronous
write-back mechanism.
z Firewall friendly – As mention in 2.5.1, when SOAP RPC on the top of HTTP, the SOAP message packets can easily bypass the firewall as it uses the standard port 80 for the message data transmission.
z Security communication – When SOAP convention on the top of HTTP, it is easy to apply SSL (for HTTPS) for security communication.
z Highly integrated with Grid computing – Web services is the trend using in grid computing.
z Gateway (or middleware) of other network file system – The mobile user’s data might have already been stored in every kind of network file system around the world. With limitations in mobile device capabilities, as mentioned earlier, such as low battery power, slow CPU speed, smaller memory and storage capacities, and etc; installing every kind of network file system they need and using it might be a big challenge. WSNFS provide a scalable and efficient middleware interface to enable mobile devices to utilize other network file system they have already used.
3.2. An Overview of System Architecture
File Server WSNFS
Client
WSNFS Client
Web Service File Server
NFS
AFS
SMB Firewall
SOAP/HTTP Internet SOAP/HTTP
Internet
Figure 1 Web services base Network File System Architecture
Figure 8 shows the network file system proposed in this paper. The Web services server is responsible for receiving requests from any type of client over the Internet via either HTTP or HTTPS, and either handling file operation or dispatching these requests to other distributed file system.
The advantage of this architecture is that a mobile user can use PDA or laptop to
access services wirelessly and transparently through firewall and get their data any time and anywhere. Furthermore, we should notice that WSNFS in this architecture can not only be a network file system, but also be a getaway of other distributed file system by cascading mount, which means mounting a remote file system on top of another already mounted remote file system [56]. The question now arises: Dose it necessary that mobile user access other distributed file system via WSNFS rather than direct access, and what is the benefit?
See Figure 9. It shows a scenario which the user can connect to several different types of file servers to fulfill the requirement of file sharing among heterogeneous distributed file servers. However, we are confronted by several difficulties while we employ this kind of architecture to make file sharing among heterogeneous file servers. First of all, the client has to install the driver module for each distributed file system. For example, the client has to install individual drivers in the kernel of its operating system for NFS and AFS. These driver modules have to be stored in the local disk of the client and they occupy the memory space of the client device even when the client does not connect to any one of the file servers. Second, the client has to install a new driver module whenever it needs to connect to a new type of file server.
Third, it is usually a lot of works to port these driver modules to a new client device as they usually have to be installed in the system kernel of the client. Fourth, some of the distributed file systems have the limitations for the mobile client devices to connect with. For example, the client must have a fixed IP address to connect to a NFS file server. Also, the existing of the firewall may have influence on the working of some of the network file systems.
File servers
PDA
Laptop computer
NFS
AFS
Samba Firewall
Clients
Figure 2: Resource sharing by connected to several heterogeneous file servers
As mention before, not all clients, especially mobile devices may have
capabilities to store variety of network file system package tools and keep every connection state, which will not only waste storage space, but increase the power consumption for mobile device. In order to reduce power consumption and save disk space, the need for a scalable and efficient middleware platform is essential.
The “web services” paradigm can be seen as a middleware for wrapping computing resources into a well understood machine interface. This interface exports the offered resources as services in a standard way, enabling their seamless discovery and usage by other systems. In our Network file system gateway architecture, other distributed file system’s information is cached in WSNFS systems supporting mobile users. This limits the amount of control traffic required by mobile device, either deliver a connection or deliver a packet. Because of the client only need to connect with WSNFS server, it enables mobile devices to utilize the Server’s computational power and storage resources.
Furthermore, another application scenario could be downloading audio/video content to mobile devices. A user has an open session from a PDA terminal connecting to WSNFS server via a Wired or Wireless network. By application transparency, multimedia application can directly read audio and/or video files, just like local one.
Viewed in this light, WSNFS could be regarded as another kind of general purpose streaming technology. However, to follow up this matter further would involve us in other factors than our focus, and would take us beyond the scope of this thesis. We may leave the detail to future work.
3.3. Component Overview
The architecture of WSNFS consists of three majored parts: Client side of WSNFS driver module, Web services base Remote System Call (WSRSC) and Server side of WSNFS server daemon. Figure 10 shows system architecture where the coloring portion is the majored components of web services based network file system, and the steps involved in servicing a remote file request.
When application sent a file system call to read a file (setup 1), WSNFS client
marshal the request as soap message, and forward to WSNFS Server over HTTP
(setup 2). The server daemon gets the message and demarshals the soap message
turning into real system call to VFS (setup 3). After the request is serviced in the
remote kernel, the result is returned to the application in similar manner.
Client WSNFS file gateway
Application program
Virtual File System
User space Kernel space
Application
program WSNFS daemon
NFS
AFS Samba Ext2
WSNFS driver module
Virtual File System
User space Kernel space
(HTTP/SOAP message)
System call request System call response
System call request System call response System call
request System call response
WSNFS request
WSNFS response
(HTTP/SOAP message)
Figure 3: The Architecture of WSNFS 3.4. Detailed Design
This section gives detailed descriptions of each of the components introduced in Section 3.3. Conceptual details, including API specifications, are spelled out in this section, but implementation details are left for Chapter 4.
3.4.1. Web services base Remote System Call (WSRSC)
In a traditional distributed file system the server, in RPC architecture typically provides a service by supporting a set of remote procedures in a well-defined interface.
A client is a user of those services, such as open, read, write, etc. The same as traditional distributed file system, we use RPC architecture. However, in order to achieve section 3.1’s goal, we use different RPC encoding mechanism. The Web services based network file system implements a virtual File system over HTTP. Using SOAP message to wrap standard POSIX.1
1I/O system call interface [60], applications can access files and directories with location and application transparency, as described on Figure 10. We named it as” Web services based Remote System Call”.
1
POSIX (Portable Operating System Interface) is defined by IEEE and ISO/IEC.
3.4.2. Web services base Network File System Protocol
Before turning to describe the detail of WSRSC API, we must draw attention to WSNFS Protocol. While using SOAP as RPC Protocol, there is one thing I should mention that WSNFS protocol is built as connectionless services in order to improve scalability over connection-oriented services. Connection oriented protocols maintain each connection and will therefore quickly reach the limit of maximum open sockets or are being dramatically slowed down by the required management overhead. HTTP is “hit and run” and can therefore serve multiple times the number of concurrent users than connection-oriented protocols. For connectionless protocol, there is no long term connection between consumers and producers as multiple messages are passed back and forth. One thing to point out, though, is that connected vs. connectionless is a concept that can vary depending on what level we're defining. SOAP messages being sent over HTTP are connectionless to the programmer. However, HTTP itself is a request and response sent back and forth over a short-lived connection using TCP, a connection-oriented protocol.
In WSNFS protocol, we reuse the same connection across multiple remote system calls – it is, after all, expensive to set up and tear down network connections. However, we do not require that the connection remain active and it is OK if the connection goes down for some reason. If the connection goes down, we simply re-establish it with the next remote system call. Besides, every remote system call includes full authentication information for the user. So, any call can establish the user identity, and WSNFS Server daemon verifies the user at every interaction. Fuller discussion about authentication will be presented in section 3.6.
By this approach, if in the weakly connection environment and the connection temporarily drop, it is simply re-established as needed, and operations continue without interruption. If a user does not perform operations for an extended time, the TCP layer will time the connection out and tear it down. It is simply re-established at the next operation and we did not require maintaining that TCP connection for the entire time that the user was inactive. The significant benefits of this approach is that if the mobile user is switched the to another IP address or location use different access point, the connection is re-established on the next operation to the new environment.
All of this is done quietly and automatically, with no interaction needed from the user
and without noticing to or impact on the user. We call this mobile transparency.
3.4.3. WSRSC API Description
The following table groups the operation of WSNFS, and shows each kind of WSNFS requests and response.
Command of WSNFS Request
Input of parameter of WSNFS request
output of parameter of WSNFS request
lstat path res, error, statbuf (base64Binary)
2statfs path bufsize, res, error
statfsbuf (base64Binary)
opendir path dpstat, res, dp
readdir dp, offset, res, error, item (base64Binary)
closedir dp res, erro
readlink path, size error, res, readlinkbuf mknod path, mode, redv res, erro
mkdir path, mode res, erro
unlink, rmdir path res, erro
rename,symlink from, to res, erro chown path, uid, gid res, erro
chmod path, mode res, erro
utime path, buf res, erro
truncate path size res, erro
close, fsync df res, erro
open path, flags fd, erro
read fd, size, offset res, erro,buf (base64Binary) write fd, buf (base64Binary),
size, offset
res, erro
Table 1 Type-specific Fields of WSNFS request
2
In order to reduce the number of items in XML file and speedup the performance of serializing SOAP
messages, we package these data structure as Base64binary.
Command of WSNFS request
Name of the packaged parameters
The data structure
lstat statbuf struct ws2__statfs {
long f_type;
long f_bsize;
long f_blocks;
long f_bfree;
long f_bavail;
long f_files;
long f_ffree;
struct { int __val[2]; } f_fsid;
long f_namelen;
long f_spare[6];
};
statfs statfsbuf struct ws__stat {
short st_dev;
unsigned long int st_ino;
unsigned int st_mode;
unsigned int st_nlink;
unsigned int st_uid;
unsigned int st_gid;
short st_rdev;
long st_size;
long int st_blksize;
long int st_blocks;
long int st_atime;
long int st_mtime;
long int st_ctime;
};
readdir item struct ws__DIR
{ int dd_fd;
int dd_loc;
int dd_size;
char dd_buf[512];
};
Table 2: The command and parameters in WSNFS request and response 3.4.4. WSNFS Mounting Protocol
Having observed table 2 in section 3.4.3 and notice the path name of client input data,
we can then go on to consider the mounting protocol, which establishes a local name
for remote files by path name translation. A mount operation includes the name of the
remote directory to be mounted and the name of the server machine storing it. The
remote directory may be any sub-tree of the requested remote file system, enabling
clients to mount any part of the remote file system. As Figure 11 indicates, mounting
remote file system (/home/howie) under local directory /mnt/wsnfs/ would result in the
path name /mnt/wsnfs/Doc.txt to reach remote /home/howie/Doc.txt.
Client Server
/
mnt
Doc.txt wsnfs
/
home
Doc.txt howie user1
user2
Mounting by client
html html
bin
Figure 4 example of mounting structure
For application transparency, path name translation is done by breaking the path into two parts: local path name and remote path name. When local applications call file system API, they only need to input the path name, such as /mnt/wsnfs/doc.txt.
WSNFS will translate path name into remote path name, such as /home/howie/doc.txt.
The results are present in Figure 12.
/mnt/wsnfs doc.txt
Client site path name Remote path name
/
Mounting start point
/home/howie/doc.txt
Real path mapping path
Mapping local path /mnt/wsnfs/ to remote path /home/howie/
Figure 5 Example of path name translation
3.4.5. Web services Description Language(WSDL) example
In WSDL, the message is a collection of XML Schema defined parts, so an instance representing a part may then faithfully represent the data structure as a tree with values corresponding to simple (non-structured) types at the leaves. With a straight-forward creation API and values at the leaves typed in the native language, the invoker may easily create the arguments of operations without requiring extra class generation or the creation of XML trees whose values require the conversion of everything into a string. In section 2.5, we mention that Web services application exposes some type of functionality; we can invoke that functionality through various types. The de factor standard of specification used to make Web services self-describing is Web services Description Language (WSDL).The following figures show the example of WSNFS API in standard WSDL form. (The whole WSDL file we put it in Appendix A.)
Figure 13 shows the schema for open request and response is as follows: Request message specifies the pathname (path) of the file to be open, and some access mode flags (flag), which request opening the file read-only, write-only or read/write, and etc.
Response message specifies the return value, such as error message, and file descriptor (fd).
<element name="open">
<complexType>
<sequence>
<element name="path" type="xsd:string" minOccurs="0" maxOccurs="1" nillable="true"/>
<element name="flags" type="xsd:int" minOccurs="1" maxOccurs="1"/>
</sequence>
</complexType>
</element>
<element name="openResponse">
<complexType>
<sequence>
<element name="error" type="xsd:int" minOccurs="1" maxOccurs="1"/>
<element name="fd" type="xsd:int" minOccurs="1" maxOccurs="1"/>
</sequence>
</complexType>
</element>
Figure 6 A Sample WSDL descriptions of open system call
Figure 14 shows the schema for read request and response is as follows:
Request-message require three parameters: number of (size) that specifies how many
bytes should be read from file descriptor (fd) at offset (offset), where the start of the
file. Response-message also return three parameters: the return data stored in buffer
(buf), the number of size (res) have been read, and error message (error), if an error
occurred.
<element name="read">
<complexType>
<sequence>
<element name="fd" type="xsd:int" minOccurs="1" maxOccurs="1"/>
<element name="size" type="xsd:unsignedLong" minOccurs="1" maxOccurs="1"/>
<element name="offset" type="xsd:unsignedLong" minOccurs="1" maxOccurs="1"/>
</sequence>
</complexType>
</element>
<element name="readbufResponse">
<complexType>
<sequence>
<element name="error" type="xsd:int" minOccurs="1" maxOccurs="1"/>
<element name="res" type="xsd:int" minOccurs="1" maxOccurs="1"/>
<element name="buf" type="xsd:base64Binary" minOccurs="1" maxOccurs="1"
nillable="false"/>
</sequence>
</complexType>
</element>
Figure 7 A Sample WSDL descriptions of read system call
Figure 15 shows the schema for write request and response is as follows: Request message specifies write bytes (size) of data (buf ) to file descriptor (fd) at offset (offset), where the start of the file. Response message specifies the return number of write bytes if success (res) and error message (error).
<element name="write">
<complexType>
<sequence>
<element name="fd" type="xsd:int" minOccurs="1" maxOccurs="1"/>
<element name="buf" type="xsd:base64Binary" minOccurs="1" maxOccurs="1"
nillable="false"/>
<element name="size" type="xsd:unsignedLong" minOccurs="1" maxOccurs="1"/>
<element name="offset" type="xsd:unsignedLong" minOccurs="1"
maxOccurs="1"/>
</sequence>
</complexType>
</element>
<!-- operation response element -->
<element name="writebufResponse">
<complexType>
<sequence>
<element name="error" type="xsd:int" minOccurs="1" maxOccurs="1"/>
<element name="res" type="xsd:int" minOccurs="1" maxOccurs="1"/>
</sequence>
</complexType>
</element>
Figure 8 A Sample WSDL descriptions of write system call
We should notice that the encoding data type of (buf) is base64Binary. Because of the format of a read buffer is basically a length followed by a series of bytes. The bytes may contain zeros, which in some documents represent end of files. The bytes might also contain series of bytes that have other special representations that may skew the encapsulation of the attachment. The solution to this problem was to create a data representation protocol that would allow binary data to be encapsulated within another document. The de facto standard for doing this is called base 64 or base64binary. The Base64 Content-Transfer-Encoding is a two way encoding scheme defined in RFC 1521[49] that is designed to represent arbitrary sequences of octets in a form that need not be humanly readable. It uses a 65-character subset of US-ASCII, enabling 6 bits to be represented per printable character (the extra 65th character, "=", is used to signify a special processing function).
However, it is well known that base64 encoded data expands by a factor of 1.33x original size (assuming an underlying UTF-8 text encoding in both cases; if the underlying text encoding is UTF-16, these numbers double). Also of concern is the overhead in processing costs (both real and perceived) for these formats. When comparing base64 decoding to a straight-through copy of opaque data
3, the throughput of at least one popular programming system decreased by a factor of 3 or more. These performance concerns may discourage many developers from using embedded data in XML. As discussed, this is one of the potential performance issues in this technique.
There is room for further investigation, which will be presented in chapter 5 Evaluation.
3.4.6. Open / Read / Write scenarios
Let us now return to a real case for example. In this case, we assume that remote directory /home/howie has already mounted on local directory /mnt/wsnfs, and the file list has been queried by client site. Below is the step of the remote system call handshake between Server and Client. Client sent request, such as open, read, and write, to server; and server responses to client. The SOAP message of remote system call shows from figure 16 to figure 22.
3
An opaque type is a data type that is not fully specified, is hidden, or whose declaration is deferred.
For example the following C declaration defines the data type for p as pointer to struct foo, which is not
yet defined.
Client Open request: path Server
Open response: fd
Read request: fd , size,offset
Read response: buf
Write request: fd,size,buf
Write response: res
Figure 9 Remote system call handshake between server and client
Figure 17 shows that a client sent open request with path name of the file, and open flag to server.
POST / HTTP/1.1
Host: 140.122.76.177:8080 User-Agent: gSOAP/2.7
Content-Type: text/xml; charset=utf-8 Content-Length: 458
Connection: keep-alive
Authorization: Basic aG93aWU6dmlzaXQ=
SOAPAction: ""
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ws="http://tempuri.org/ws.xsd">
<SOAP-ENV:Body>
<ws:open>
<path>/home/howie/document/doc.txt</path>
<flags>32768</flags>
</ws:open>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 10 Example of open request SOAP message
Figure 18 shows that server response the file descriptor (fd) of doc.txt to client. The file descriptor of open statue will be kept in Server until the close remote system call.
It is clear that WSNFS is stateful.
HTTP/1.1 200 OK Server: gSOAP/2.7
Content-Type: text/xml; charset=utf-8 Content-Length: 423
Connection: keep-alive
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ws="http://tempuri.org/ws.xsd">
<SOAP-ENV:Body>
<ws:openResponse>
<error>0</error>
<fd>9</fd>
</ws:openResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 11: Example of open response SOAP message from server
Figure 19 shows the client try to read a remote file of /home/howie/document/doc.txt through file descriptor (fd), and read size is 4096 bytes from offset 0.
HTTP/1.1 200 OK POST / HTTP/1.1
Host: 140.122.76.177:8080 User-Agent: gSOAP/2.7
Content-Type: text/xml; charset=utf-8 Content-Length: 426
Connection: keep-alive
Authorization: Basic aG93aWU6dmlzaXQ=
SOAPAction: ""
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ws="http://tempuri.org/ws.xsd">
<SOAP-ENV:Body>
<ws:read>
<fd>9</fd>
<size>4096</size>
<offset>0</offset>
</ws:read>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 12 : Example of read request SOAP message
Figure 20 shows that server responses 1416 bits of data embedded in (buf) with no
error message.
Server: gSOAP/2.7
Content-Type: text/xml; charset=utf-8 Content-Length: 2393
Connection: keep-alive
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ws="http://tempuri.org/ws.xsd">
<SOAP-ENV:Body>
<ws:readbufResponse>
<error>0</error>
<res>1461</res>
<buf>
ICAgICAgICAgICAgICAtLS0tLS0tU2VxdWVudGlhbCBPdXRwdXQtLS0tL…
</buf>
</ws:readbufResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 13 Example of read response request SOAP message from Server Figure 21 show client try to write 64 bits of data, which is imbedded in buf, to remote file /home/howie/document/Doc.txt through (fd).
POST / HTTP/1.1
Host: 140.122.76.177:8080 User-Agent: gSOAP/2.7
Content-Type: text/xml; charset=utf-8 Content-Length: 2387
Connection: keep-alive
Authorization: Basic aG93aWU6dmlzaXQ=
SOAPAction: ""
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ws="http://tempuri.org/ws.xsd">
<SOAP-ENV:Body>
<ws:write>
<fd>9</fd>
<buf>
ICAgICAgICAgICAgICAtLS0tLS0tU2VxdWVudGlhbCBPdXRwdXQtLS0tLS0tLSAt1....
</buf>
<size>1461</size>
<offset>0</offset>
</ws:write>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 14: Example of write request SOAP message
Figure 22 shows the return message of write success.
HTTP/1.1 200 OK Server: gSOAP/2.7
Content-Type: text/xml; charset=utf-8 Content-Length: 436
Connection: keep-alive
<? xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ws="http://tempuri.org/ws.xsd">
<SOAP-ENV:Body>
<ws:writebufResponse>
<error>0</error>
<res>1416</res>
</ws:writebufResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 15 Example of write response request SOAP message from Server 3.4.7. Network Layer
Based on Web services, any remote system call in SOAP is directed to a URI. These are unique identifiers for any resource located within the scope of the network the HTTP service is running in. On the Internet, such an identifier lets you uniquely pinpoint a resource anywhere in the world. URIs are a generalization of the better known “URL” (Uniform Resource Locator) term that always assumes to provide a full navigation path for a resource. URIs only need to be unique identifiers and may or may not be associated with a transport.In WSNFS network layer, users can easily access remote server in two types. The concept illustrate in Figure 23. In Type 1, clients can directly access WSNFS server via IP address or URLs. In Type 2, clients query the information sever, which stores the location of WSNFS server, and redirection to it.
Users needn’t to know where their data is really stored.
Information Server Type 1:
Direct accesses via URLs or IP address.
Type 2:
Query and redirect by information server, such as LDAP
Figure 16 Illustration of the idea proposed in this article.
3.4.8. Authentication
In recently the SOAP protocol still provides neither an authentication mechanism nor an authentication framework. The lack of a framework is unfortunate as many alternative approaches have proliferated. The defensible argument is that authentication should arguably be performed at a lower level in the protocol stack.
This pushes responsibility down to the HTTP protocol, or whatever protocol binding SOAP is being used with.
In our early design, we use HTTP Authentication: Basic Access Authentication [50]. "HTTP/1.0", includes the specification for a Basic Access Authentication scheme.
The HTTP authentication dependent on checking the username and password strings, which are set when a client request contains HTTP authentication headers. A server may request user authentication and denies access (HTTP 401 error) when the client tries to connect without HTTP authentication (or with the wrong authentication information). The username and password encoded in base64. The example of HTTP Authentication header shows in figure 24.
POST / HTTP/1.1
Host: 140.122.76.177:8080 User-Agent: gSOAP/2.7
Content-Type: text/xml; charset=utf-8 Content-Length: 2387
Connection: keep-alive
Authorization: Basic aG93aWU6dmlzaXQ=
SOAPAction: ""
…
Figure 17 an example of WWW-Authentication HTTP header
However, using Basic Authentication Scheme could damage the performance if the strings should be checked in every remote system call. The concept of session authentication, such as GSI
4may be better. There is room for further investigation, and we put this in the chapter 5 future work.
4