STRUCTURE OF
M-COMMERCE
The
traditional Web interaction model evolved on desktop computers, making its user
interface assumptions uniquely suited to a desktop or laptop computer. Mobile
Web services span a range of capabilities. Mobile appliances can display many
lines of text and graphics in a single screen. Accessing Web information on
these tiny appliances falls into three categories. This approach employs
manually authored page templates for each device type and populates these
templates with content from a database.
Because
of the labour required, only a small fraction of Web content in Europe and
Japan is manually authored for any particular device. In Japan, the i-mode
service provides many Web phone users with access to specifically authored
compact HTML pages. Automated techniques for re-authoring Web content have
become popular because they are cost-effective and they allow access to content
that providers have not manually authored for very small devices.
Transforming
system Making Web content compatible with device formats, transforming systems
modify content to transform the structure of interacting with the content. The
Digestor system, for example, attempts to imitate an expert Web designer faced
with the task of re-authoring Web pages for PDAs . This study also modifies the
Web page layout, splitting it into multiple sub-pages and adding navigation
links so that the user can navigate the sub-pages. z Multipurpose system
M-Links is a representative of this category. Figure shows the m-Links
architecture proposed by Intel.
The three
main processing components are the link engine, which creates the navigation
interface; the service manager, which creates the action interface, and the
user interface generator, which converts the interfaces into forms suitable for
the requesting device and browser. Formats include HTML, Wireless Markup
Language (WML), Handheld Device Markup Language (HDML) and Compact HTML
(CHTML).
M-Commerce Framework
Figure
illustrates an m-commerce system architecture that shows how this study combined
advance technologies according to the previous works. The architecture consists
of the Web client, XML server, and back-end processing modules. Figure 5 is
depicts the operation scenario between tiny wireless devices and servers, based
on WS technologies.
Web
Client WS technologies describe the specific business functionality exposed by
a company, through an Internet connection, to provide a way for another company
to use business services. WS consists of many software building blocks that can
be assembled to construct distributed applications. They are in particular
defined by their interfaces about how they describe their functionality, how
they register their presence, and how they communicate with other WS. Restated,
individuals wanting to use WS could connect to the UDDI center to search for
the required services.
The
information described by the WSDL can be acquired. The users could also use the
SOAP to transfer the required information and receive the real service. This
study adopts the mobile agent technology into the architecture to mobilize this
information . WS procedures can be mastered with mobile agents. Users only need
to send simple commands of their requirements. The mobile agents perform the
actions according to these commands and interact with WS technologies.
All users
must wait for the response from the service provider and then enjoy the
services. z QoS consideration An m-commerce service could be successful; the
QoS will be one of the ultimate criteria. For example, location awareness, data
burst control, and unpredictable bit error rate. Additionally, QoS combines
several qualities or properties of a service, such as availability, security
properties, response time and throughput.
Many
providers compete to offer the same WS, implying that users can decide to
select providers based on the QoS to which they can commit. This observation
suggests that users and providers must be able to engage in QoS negotiation.
The interaction between users and WS providers occurs via XML-based SOAP messages.
z SOAP security Several service scenarios in which security function is
provided by the transport layer are insufficient. SOAP security is useful for
application developers.
Their
functionalities include end-to-end security, application independence,
transport independence, and stored message security . The code translator
module ensures that the module with correct coding for device. The security
goal of a service-oriented architecture attempts to enable trusted interactions
among the roles. If security is defined as protection against threats, a WS
identifies its set of perceived threats and propose methods of preventing
threats to WS interactions.
Two
parties can establish trust when they understand the risks, having identified
the threats and vulnerabilities and conferred on a set of countermeasures and
safeguards for protecting themselves in doing business. A WS architecture
implementation should allow for incremental security and QoS models facilitated
by configuring a set of environmental prerequisites to control and manage the
interactions. In addition, users can access their personal and services folders
once they have logged into the system using a pass phrase (Certificate
Authority; CA).
The
client also has other functions, including changing the pass phrase;
customizing the appearance of information in the personal folder, and
specifying when the client should lock information. Web Services Flow Language
(WSFL) is an XML language describing WS compositions. WSFL considers two types.
The first type specifies the appropriate usage pattern of a collection of WS,
such that the resulting composition describes how to achieve a particular
business goal; typically, the result describes a business process.
The
second type specifies the interaction pattern of a collection of WS; in this
case, the result is a description of the overall partner interactions. Object
Store creates a ‗proxy‘ object, which communicates with the actual service to
process the application request. The proxy creation and usage is transparent to
the client and its complexity shielded by the underlying WS.
XML
server includes the following functionalities: transforming data in the
database into XML data; making many different XML documents according to
different Document Type Definition (DTD); and receiving requests from web
server and producing HTML files corresponding to the back-end processing
modules. The study develops a user interface generator, which uses a
combination of screen template substitution and program inheritance to produce
the appropriate markup interface for each device.
It begins
by identifying the device making the request, and then determines the
appropriate type of response markup and dispatches to a markup handler. The
handler subsequently uses a screen template to help generate the content
appropriate for the device. The generator uses the same process for both the
navigation and the action interfaces, as well as a few associated screens.
Figure
illustrates the operation scenario, described in the following. 1) A mobile
device sends a request to Filter and Filter relays the request to the WS via
HTTP protocol. 2) The filter authenticates the identity of the user and device,
relays the user's request to the WS and forwards authentication data to the style
generator at the same time. The style generator then determines the style-sheet
to be used according to verify received data with user data and device data. 3)
When receiving the request, the WS generates the appropriate XML documents and
style sheet to send to the rendering module. 4) When receiving the XML
documents and XSLT, the rendering module generates documents with the XML
parser and XSL engine.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.