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