Active Directory Services

Published on June 2016 | Categories: Documents | Downloads: 37 | Comments: 0 | Views: 210
of 34
Download PDF   Embed   Report

Comments

Content

BREW.
Abstract
All of we knows what is the importance of the wireless networks. Today no one can apart from this technology. We can’t imagine the world without it. The intension of this seminar is to understand whole this network, its requirement and the problems in it. This seminar gives the idea about the how the network can be used efficiently by using the term BREW. This seminar not concerns with the the technologies like WAP, 3G,Bluetooth and lot more. But it describes all this thing in some different and in generalize manner. Along with whole discussion, the main focus of the seminar towards the change of developers view in the wireless industry.

Keywords
ARPU : OEM : WAP : MIF : PDA : SDK : JVM : CDMA : API : Average Revenue Per User Original Equipment Manufacturer. Wireless Application Protocol. Module Interface File Personal Digital Assistant. Software Development Kit Java Virtual Machine. Code Division Multiple Access Application Program interface

INDEX
CONTENTS PAGE 1. Basic background…………………………………………………5 1.1 Wireless network structure 1.2 Problems in basic n/w structure 1.3 Primary solution 2. Customer intention towards the telephone……………………..8 2.1 What the People want ? 2.2 Don’t overlook the telephone ! 3. Need of Wireless Industry……………………………………….9 4. What is BREW means ? ………………………………………..10 4.1 BREW DEFINED . . . . 4.2 BREW Objectives 5. Introduction to BREW………………………………………… 11 5.1 The BREW application platform 5.2 Client side processing
6.

BREW technical overview……………………………………..15 6.1 BREW system overview 6.2 Device architecture (Layearing) 6.3 OAT (OEM Acceptance Test ) 7. Value for all……………………………………………………19 7.1 Networks and Network Operators 7.2 Devices and Manufacturers 7.3 Application Developers 7.4 Users 8. Introduction to BREW SDK…………………………………25 8.1 BREW from an Application Developer’s Perspective : 8.2 BREW SDK Components 8.3 Module Information File (MIF)
2

8.4 How It All Fits Together 8.5 Writing a BREW application 9. BREW Development Process……………………………….29 10. An Integrated Business Model…………………………….30 10.1 Reliable, High-Quality and Safe Applications Summary………………………………………………………. 31 Conclusion……………………………………………………... 32 References………………………………………………………33 1. BACKGROUND
All of we know what is the importance of the communication in our day-to-day life. Technology always try to give the best solution for it. Technology shifts from the mailing to the telephones to the mobiles and what next…? Today all of we familiar with the mobile communication. I am shortly describing this system But in some different perspective parallel with main topic.

1.1 Wireless network structure
Basically this wireless network is divided into the 3-categories. - Manufacturer - Carrier - Developers 1.Manufacturer: They provide the physical device cable for wireless communication called as a handset. These handsets are of various types according to the functionality, user requirements and the environment in which they are used. Also there are various companies involved in the manufacturing the handsets. So there is the various architectures of the handsets. And the primary requirement is each handset must communicate with the others. 2.Carrier: They are responsible for providing the services to the user. They are handling the whole network. They are deciding the cost for the services and collecting the bills from the user. They act as an agent between the developers and the customer. 3.Developer: They write the various applications used by the end user on the handset.

1.2 Problems in basic n/w structure
There are the various drawbacks of this basic network structure. The main problem starts from the manufacturers phase. As there are various architectures involved 3

in the system, the whole system becomes the highly heterogeneous and the task of each one is to resolve this heterogeneity. The huge complexity involved in the role of the developers and the carriers. Carriers have to check the device type, it’s applicability and lot more for each service to be provide. The main drawback from the developers point of view is, they have to write the same application in different manner for different architectures. Also for that they need to have the knowledge of each architecture for which they have to write the applications. So they have the collaboration with the manufacturers. Still this structure was worked because whatever overhead involved to setup this network are taken from the customer by taking the higher costs for the services. This results in, customer not demands the applications on wireless network. It uses it as only for emergency conditions. So though this network has huge capacity, it was not used efficiently. This is huge wastage of the energy and the technology. Now the second main problem is that the processing capabilities of the handsets. As the requirements for the handsets as small size, low power consumption, low price It is not possible to provide the high processing capabilities at the handset. So the whatever applications are provided to the customer are all of the type server side processing i.e. whatever application demanded by the user is first processed at the carriers server and then he processed data is send to the client. The handset has the browsers, which are embedded at the time of manufacturing are capable of to display the processed data on the handset. So the customer has to pay more and also re-pay again when it uses the same application next time. Again this would leads to the same problem.

1.3 Primary solution
The primary solution build to handle the above problem is the operating systems for the mobile handsets named as smart phone. It solves the problem of the server side processing. But it violets the basic need for the general customer of small size, low cost. And also the simple handsets can not be upgradeable to those handsets. So again it has the limited customer area and the problem of network efficiency is unsolved. So all this discussion indicates that the technology must have to think more and we are here for that purpose only. Let’s look at the some other interesting discussion.

4

2. Customer intention towards the telephone 2.1 What the People want ?


People like talking on telephone
Battery life, coverage, small size

• People like the portable phone

More and more peoples attracted towards the mobile phones

• Customer wants the useful stuff

Users don’t engage in substandard experiences just for the benefit of the technology industry.

• Customers want more for the same money

$500 PC today does more than $2000 PC did five years ago.



Really wants windows in my pocket.

2.2 Don’t overlook the telephone ! • People want a telephone first

How can you help me make better phone calls?

• Then they want telephone enhancements

Portable numbers, integrated directories, etc

5



Maybe after that they want stuff to do in between phone calls
Chat, games, location assistance, maybe music

• But they don’t want to compute on their telephones!

No productivity software, no commerce, no corporate apps

3. Need of Wireless Industry So what this all above discussion concluded ?
For mobile wireless network operators, the road to profit has always included providing services their customers find valuable, and to a certain degree addictive. To date, voice has been the leading application on mobile wireless networks. But it is clear that non-voice services (data applications) offer an enormous opportunity – if operators provide them in a way that’s operationally efficient and has mass-market appeal. The best way for the wireless industry to deliver these applications to customers is through a solution that:  Is open, globally standardized, hardware independent and consistently deployable on any network and on any mobile device.  Provides an end-to-end solution, encompassing both an open technology platform and a well-developed business model for revenue sharing along the entire value chain. Includes a method for discovering, buying, downloading and managing applications on client devices.



6

Finally technology reaches at the stage to achieve all this goals at best by using the term named as

“ BREW ”

Let’s see what this BREW is ?

4. What is BREW means ? 4.1 BREW DEFINED . . . . Let’s see what is the meaning of the term BREW.

Binary :
API is the set of libraries. Applications and the extensions are compiled for the native execution.

Runtime :
BREW applications and the extensions are discovered at runtime and loaded when needed.

Environment :
An open and flexible environment with wealth of API and the application management services.

Wireless :
Fast, efficient, low RAM/FLASH environment developed for the wireless devices to take the advantage of the wireless services. Tuned for efficient use of the wireless network services.

7

This definition itself specifies what the term BREW stands for and what it does. It might be consider as, BREW is the cup of coffee taken for the refreshment to work with complex, tedious job by the smart people.

4.2 BREW Objectives BREW provides the unifying platform that benefits to the users, developers, carriers and manufacturers. Benefits Handset Manufacturer • Supports new features across the handset lines. rd • Simplifies the working with 3 party developers. • Reduces training, development and integration. • Time to market Benefits Developers • Open a new development platform. • Leverages familiar paradigms. Benefits Carriers • Speeds the introduction of new applications and services. Benefits User • Allows user to select the feature they want.

8

5. Introduction to BREW
The BREW is not the single term. It is technology as well as the integrated business model. It has the different perspective according to, from whose eyes you viewed it. Finally it is the product of the big company name called as QUALCOMM suited in JAPAN and has various offices and market place trough out the world. So this name BREW cannot be separated from the name QUALCOMM. So in further discussion about this topic this word will come appropriately. So before taking the technical review of BREW, let’s understand in short what it is ? AND what it does ?

5.1 The BREW application platform
The complete BREW solution begins with the open, standard applications execution platform that resides on the wireless device.

• Open :
9

Open means an architecture whose specifications are public, and that includes officially approved standards as well as privately designed architectures whose specifications are made public by the designers. The opposite of open is closed or proprietary. The great advantage of an open architecture is that anyone can design add-on products for it. This is true about BREW.

• Standard :
Standard means a definition or format that has been approved by a recognized standards organization or is accepted as a de facto standard by the industry. Standards exist for programming languages, operating systems, data formats, communications protocols and electrical interfaces. The goal of the BREW is to become the standard wireless applications environment that enables an open and dynamic wireless applications and services market. Standard also means "the same everywhere it exists." This is true about BREW. For consumers, standards are extremely important in the computer industry because they allow the combination of products from different manufacturers to create a customized system. Without standards, only hardware and software from the same company could be used together. BREW makes this possible in the wireless space. Before the BREW platform, wireless handset application development was virtually closed to third-party developers. With the BREW platform as a standard environment, software developers write their applications to the BREW platform once, effectively eliminating the need to modify applications for each new device model.

• Thin :



Not just a scaled down version of a product developed for PCs or PDAs BREW is many times smaller than other applications platforms or fullblown operating systems. Fast :BREW platform sits right on top of the chip system software enabling fast C/C++ native applications and easy integration of browsers, virtual machines based on Java™ technology and extensions such as game engines and music players. Applications written in C/C++ offer certain efficiencies, considering the constraints of wireless handsets. C/C++ enables native, compact, resource-efficient applications that run fast because they do direct native processing rather than byte-code interpretation. In recent focus groups, BREW developers referred to writing in C/C++ as "more efficient and neater." And, "C is better for writing to small devices." "In writing applications in C/C++, you don't have this 'abstraction' layer that you do with another platform." 10

A developer who is focused on writing Java™ applications can also take advantage of BREW by writing to Virtual Machine environments that have been ported to BREW. BREW is neutral about other development environments. In fact, it complements them by enabling Java applications to be downloaded over the air and easily installed on BREW handsets. A VM can be integrated onto the BREW platform very quickly.

• Extendible :

Third parties can write extensions to the BREW platform, making additional functionality available to applications.

• Cost effective :

Reduces development costs and accelerates time-to-market for device manufacturers. They spend less time developing and integrating assorted applications on different models and more time designing products.

• Secure :

BREW protects essential phone and wireless network operations.

5.2 Client side processing
Mobile phones have become like a computer in the hand – capable of running a variety of applications. Yet this capability is constrained by market demands that require mass-market phones to be small, inexpensive, light and consume little power. These constraints, in turn, have restricted device processing power and memory (storage). The historic approach to delivering applications to phones has been to shift processing power to servers in the operator’s network, or to a third-party company via the Internet (known as server-side execution.) Portals and mobile games using WAP browsers exemplify this strategy. Content and applications are generated by remote servers, passed through the network and displayed in the browser on the mobile phone. The user then keys in responses to choices displayed on the device screen, which are sent back through the network to the server for processing and response. The weaknesses of the browser-based server-side approach are clear: high latency and limited interactivity on the mobile device. This makes the most exciting, graphic-rich interactive games impossible – and these games represent the bulk of gaming activity on other (nonwireless) handheld platforms. In effect, with a browser-based solution 11

that requires server-side processing, the mobile phone becomes an unnecessary performance bottleneck and prevents the best applications from being developed because of its inability to process information locally. However, decreases in size, power consumption and cost of silicon chips have enabled a second approach – putting more processing power on the mobile device. This opens up a new range of applications based on local, or client-side, processing. This is expected to be the predominant growth area for new mobile wireless applications – rendering today’s slow server-side approaches virtually irrelevant for many new types of applications. Rather than only using the browser on the mobile phone to run and interact with applications, it becomes a true platform for software applications that can offer a startling array of new consumer data services provided by the network operator. QUALCOMM’s BREW platform and Sun Microsystem’s Java technology (implemented on mobile phones as J2ME) are two popular technologies that support client-side processing. Both technologies offer a method for executing software applications on a mobile device. Contrary to popular belief, BREW and J2ME technologies can run together on the same phone. The BREW platform supports J2ME and gives J2ME developers added value through its end-to-end system approach. The BREW platform also offers specific advantages in efficiency, device integration, power consumption, functionality and cost. Advantages of BREW’s client-side processing technology include the following: • True real-time processing. With client-side processing, a new range of applications (such as action games) will be developed because of the BREW platform’s ability to download and run applications locally on the phone. Even on circuit-switched networks, applications start immediately since they reside on the phone – with no need to wait for a data call to be initiated. BREW extends this advantage by offering true real-time processing, enabling other applications – especially those that are voice-based applications. • Fast interactivity with information.

12

With client-side execution, customers can download a database of travel information about a specific locale to their devices in just a few seconds, then search the database or interact with maps quickly and as often as needed. The locally stored information can also be used to enhance position information for personalized location-based services. All customers enjoy equally fast application response times regardless of network bandwidth. BREW enhances client-side execution by tightly integrating with the phone’s basic telephony functions. It’s simple for a developer to write applications that take advantage of BREW’s telephony management features, so an application can be automatically suspended and then resumed in the event of an incoming call or SMS message. • A more personalized mobile experience – over the air. End users can literally customize their phone with applications and information that suits their lives – and change the applications as often as they wish. One customer might personalize his or her handset by downloading all business productivity applications (a financial calculator, a stock-tracking application and a streamlined contact database), while another might download entertainment applications and a personalized ring tone. And it can all be done over the air – no cables or PC connection required. The BREW application platform allows network operators to install, recall and update applications over the air. Even in the case of telephony-specific applications, there is no need to bring the handset into a store or operator location for servicing. • Minimal hardware and software requirements. The BREW platform is thin – ~150k – efficient and powerful, and there’s no need for a separate virtual machine (VM) for each model of phone. Carriers who wish to have both J2ME and BREW on a handset will only need one VM, and over time they will have access to multiple VM options. BREW naturally supports client/server-based applications, such as multi-player gaming, just as elegantly as client-side applications.

Now let’s we turn our attention to the technical review of the BREW.

13

6.

BREW technical overview Essentially BREW provides the software connection between low level function of mobile and higher level applications written by third parties. 6.1 BREW system overview

Figure 6.1 Brew system overview

Above diagram describe the various views of the system for which it is used. We see each of them in the following sections.

14

6.2 Device architecture (Layearing)

Figure 6.2 BREW device architecture.

BREW architecture is made of basically of three layers : 1. AEE layer 2. BREW interface layer 3. OEM layer AEE layer
It is an Application module ExtEnsion layer. It provides the platform for the all the modules written within with BREW environment as well as other applications platform like Java virtual machine (J2ME), extensions written for the handset, applications embedded at the manufacturing time. This layer basically provides the various API classes and manages the application execution.

15

OEM layer
OEM layer is responsible for providing uniform behavior to AEE layer for device compatibility. OEM layer is composed of two sub layers : o MIL -Module Interface Layer o ChIL –Chip Interface Layer ChIL provides baseband chip specific services like GPS, Socket etc. MIL provides baseband chip independent services like database, heap, etc.

BREW interface layer
This is the logical layer provides the interaction between the OEM layer and AEE layer. This is the very important layer in whole architecture since each device provides different sets of features and hardware capabilities like • • • • Different Different Different Different screen size, resolution, color depth and refresh rate key pad and input method memory configuration (size and speed) network speed

BREW application need to adapt to different running environment.

6.3 OAT (OEM Acceptance Test )
To insure BREW device compatibility, each OEM is required to run OEM acceptance test (OAT). OAT tests MIL and ChIL to insure device compatibility: – File system implementation – Display implementation – Network implementation – Memory management implementation 16

BREWStone measures performance of each handset.

BREWStone measures following subsystems: • Display and graphics • File system access • Database access • Memory access • CPU/computation Performance numbers are relative to reference device. This completes the technical review related with BREW. This whole technical review is related with interaction of BREW with handset architecture i.e. from manufacturers point of view.BREW’s interaction with Developers and Carriers can not be listed specifically since it is just the logical interaction. We will see it in following sections.

17

7. Value for all
In this section we will see how the BREW suited in the wireless network and how it benefited to all. The BREW platform provides unique advantages over any other solution available, to meet both market and technology requirements. From the ground up, BREW is complete in its specific attention to supporting the requirements of the entire value chain. Foremost, BREW offers the opportunity for increased average revenue per user (ARPU) in a way that preceding technologies, such as WAP, have been unable to achieve and sustain. The reason is simply that BREW enables higher value applications to be created and provides a revenue-generating marketplace for more applications to be developed in the future. WAP has added some incremental revenue from existing voice customers. But customers’ perceived value of the service has been low. It has failed to gain significant adoption and many operators have been forced to give away WAP service and subsidize phones in an attempt to stimulate use. Even with time, the impact on ARPU will likely be minimal due to the continuing constraints imposed by the WAP solution (and solutions layered atop WAP, such as M-Services). Increasing ARPU is the key to a complete value chain. If the customer isn’t willing to pay more for the new data services, nobody makes a profit. This can be seen in practice today as application and content developers for WAP-based services are failing to achieve profitability and are either quitting or moving on to other, more profitable platforms. Left unsolved, this problem will eventually lead to a dearth of meaningful services and a downward economic spiral. With a powerful platform that enables high-value applications and services that perform well, ARPUs will increase. The BREW applications execution environment is designed specifically to support development and provisioning of high-value applications on the kinds of mobile devices people use most today. Increased ARPU is only the beginning. To be truly effective, a technology must support network operators, devices, application developers and users.

18

7.1 Networks and Network Operators
The BREW platform is designed to provide a consistently excellent user experience regardless of network infrastructure. First and foremost, it is entirely agnostic – meaning that it deploys equally well on all leading wireless technologies. The BREW platform also works well with existing circuitswitched networks, addressing the needs of operators who will not be building packet networks near term and those who will be deploying packet networks in stages. Whether the customer is on a packet network or circuit network, or roaming between the two, does not affect the quality of the customer experience. BREW can be an effective revenue-generator now, not only after expensive network technology upgrades. This differs from server-side solutions such as WAP. Because they rely almost entirely on constant communications between the device and the application server, WAP requires a packet network for a satisfactory end-user experience.3 Even with a packet network, issues of latency are problematic. Latency gives the user the impression of a “slow network” regardless of actual bandwidth available. The BREW platform, because of its client side execution capability, is independent of network latency. A better network increases what can be done with BREW, but regardless, BREW enables a good user experience with any existing 2G or later network. BREW applications can provide powerful services even without 3G networks. Equally important, BREW grows with network and device upgrades. Greater bandwidth and/or lower cost delivery mean that over time more robust applications can be downloaded and run more economically. This increases the perceived value of BREW-based applications from the customer perspective, and it capitalize on the advanced capabilities of new networks as they are deployed. Additionally, as memory and processing power in devices increase, BREW applications will increase in their sophistication and can be provided to end users over the air. Obsolescence is a non-issue – BREW becomes increasingly useful and valuable over time. Perhaps the best part of the BREW platform is its low cost of implementation. BREW reduces costs and risk to network operators and enhances their operational efficiency in three ways: • Low infrastructure cost. Operators have total control over how much and what they want to control, and can scale to demand. Their investment can start under $100,000 to support up to 4 million users. • Lowered cost for other platforms.

19

Because the BREW platform provides the basics – application discovery, management, downloading, billing records, etc. – it supports a wide range of other applications and programming languages. Whether a microbrowser, a game, a ring tone, a voice application or even J2ME applets, the BREW platform gives operators the means to offer a wide range of services atop a single platform. This eliminates the need to implement proprietary platforms for every new service that becomes available – thus increasing efficiency and lowering costs.
• Low risk. With the BREW business model (discussed below), operators pay only for successfully deployed applications and services. Application developers are paid only for applications actually purchased by subscribers. Because of its small memory footprint, BREW handsets can be made less expensively. That means BREW can roll out to price-sensitive customers today – the same demographic market that made SMS a global success.

7.2 Devices and Manufacturers
In the past, the “smart phone” concept led many to believe that feature-laden operating systems were the key to advanced data on mobile devices. But the experimental and niche phones based on operating systems from Geoworks, Palm, Symbian and Microsoft have failed to attract volumes of users, in large part due to their exceptionally high prices. Operating systems are not an efficient solution for enabling wireless data. Ideally, applications should be scaled perfectly with the various tiers of phone models and make efficient use of the phone’s resources and provide a consistent user experience. To succeed at this task requires a complete solution that addresses the needs of all devices – not just the high-end. The BREW application execution environment does this by virtue of being integrated with the processing chip in the Flash memory and RAM of mobile devices. Essentially, BREW provides a software connection between the low-level functions of the mobile device and the higherlevel applications written by third parties. Because BREW functions as an abstraction layer in the Flash and RAM, BREW software developers do not need to intimately understand embedded systems programming. Instead,

20

they’re freed-up to focus on the design and creation of the application, not the underlying hardware. The benefits of this approach are clear: streamlined and efficient software development. With BREW, porting applications from device to device becomes almost a trivial task. Time-to-market is vastly reduced, and new applications work consistently from one phone to another. BREW’s easy software porting makes BREW functionality readily available to all handset manufacturers. The BREW platform is airinterface independent and has been ported to CDMA IS-95A, IS-95B, 1x, 1xEV-DO and GSM/GPRS handsets. Of all available options for client-side processing, the BREW solution is the least expensive and easiest to implement, with the lowest requirements for phone design. As mentioned previously, the BREW platform is ideally suited for lower priced phones, which account for most of today’s mobile phone market. Because BREW only requires ~150k of memory for the complete system, more usable and interesting applications (that can be as small as 10-50k per user application) can be offered on lower tier phones. The low cost and simplicity of this chip level integration means that BREW can realistically serve mass market devices.

7.3 Application Developers
Bringing new applications to market quickly is critical to the success of software developers. The BREW execution platform is based on the widely-used programming language C/C++, which has a base of more than 7 million application developers today who can support BREW with minimal additional knowledge of mobile phones. To begin the process, a developer can simply download the free BREW SDK from http://www.qualcomm.com/brew/developer/developer.html. At the time of publication of this paper, QUALCOMM had logged more than 12,000 SDK downloads. Java programmers can also benefit from the chip-level integration of BREW. Java applications normally require a Java Virtual Machine (JVM) that is specifically designed for each device to handle chipset-level functions. For example, any application running on a phone needs to access basic telephony functions such as the arrival of

21

an SMS message or access to a phone’s built-in GPS capability. Because access to those functions varies from phone to phone, a special JVM would be required for nearly every model. Every network operator defines their own specification for Java implementation (over and above the MIDP specification). Therefore, each manufacturer builds custom APIs to get better performance out of the MIDP 1.0 specification. The result is that each handset may require different JVMs and MIDP interpretations from each manufacturer. IBM has written a single JVM that acts as an extension to BREW. Java developers will be able to take advantage of this JVM to enable them to write Java applications once and run them on all BREWenabled devices that have sufficient memory footprints, regardless of manufacturer. The BREW platform is standardized, so porting applications from one device to another is simplified. Additionally, BREW makes getting Java applications onto handsets much easier, and will enable upgrading and recalling JVMs over the air. Java applications will run on more phones, more easily, with BREW. Essentially, BREW functions as the “lowest common denominator” to smooth the way for Java applications, and enables millions of C/C++ and Java programmers to offer software for mobile devices as well. Finally, the BREW platform gives developers the ability to easily monetize their applications. The BREW solution includes a complete billing and payment infrastructure – the BREW Distribution System – that helps ensure developers receive the payment they deserve for their applications. No other platform solution offers this benefit.

7.4 Users
Mobile phone consumers occupy many market segments – from price-sensitive “security” users with inexpensive handsets to corporate customers with high-end devices, and from young people seeking entertainment services using prepaid handsets to international roamers with high monthly expenditures. A successful technology must address all segments of consumers.

22

BREW is integrated at the chipset level allowing network operators to provide meaningful applications to even the lowest cost mobile phones. Lower costs means consumer-oriented phones can be more readily supported. Lower-cost phones are critical to the prepay market. Even the most price-sensitive customers can have access to new applications on their handsets regardless of their method of payment. BREW is universally available to customers, even as they graduate from one handset to another and from one pricing plan to another. The built-in “Mobile Shop” application allows BREW users to easily find, add and remove applications with just a few clicks on the keypad. And, there is no requirement to “synchronize” the phone with an Internet-connected computer. The BREW platform enables a myriad of compelling and useful consumer applications and services on the mobile phone. These applications are dramatically better than the WAP- and SMS based services of today. Applications written for BREW offer excellent graphics, fast-paced action and real-time interactivity. Information services give the user the ability to search information both locally (on the phone) and on the Internet, as part of a single, seamless process.

This completes the whole discussion about how the BREW suited in whole wireless network. Now let’s look at the some important topic from Developers point of view.

23

8. Introduction to BREW SDK
The purpose of the BREW SDK is to provide a platform where applications for mobile devices can be easily written and tested on a familiar desktop (PC) environment prior to porting on mobile devices

8.1 BREW from an Application Developer’s Perspective :
– BREW is a set of functions (APIs) that can be used to write applications for mobile devices – These APIs offer a wide range of services such as: Display, Memory, Files, etc. – BREW shields the application developer from the phone internals. BREW SDK offers the emulation of these APIs on a PC environment.

8.2 BREW SDK Components • • • • • BREW Emulator BREW Device Configurator BREW Resource Editor BREW MIF Editor Documentation

The BREW Emulator provides a mechanism to emulate execution of BREW applets on a Windows NT/2000-based desktop computer. The wireless devices emulated can have different screens, keypads, amounts of available memory, and supported languages. During emulation, the BREW Emulator opens a bitmap image of the device on a PC monitor. By clicking the portions of the image that correspond to the device’s keys, you provide key input to the applet being emulated, and the screen output produced by the applet appears in the screen portion of the device image. The BREW Device Configurator is a Windows Standard Device Interface (SDI) application used to define the configuration of each device emulated by the BREW Emulator. These device configurations are saved in files; by loading new device 24

configuration files into the BREW Emulator, you can easily emulate the behavior of BREW applets on a variety of different devices. Because the device configurations are stored in files separate from the BREW Emulator, you can define new devices with the BREW Device Configurator and use them to emulate BREW applet execution. The ability to accurately emulate applet behavior on a PC greatly reduces the amount of testing required on the target device. The BREW Resource Editor creates a Resource file containing the character strings, bitmaps, and dialogs the applet loads during its execution. BREW MIF editor is to used for create and edit the MIFs i.e. Module Information File—a special type of BREW resource file that contains information about the classes and applets supported by particular BREW modules.

8.3 Module Information File (MIF)
A Module is the starting point for all applications For each Module, BREW requires the following information prior to loading the Module: – Number of Applets and Classes in the Module – Class IDs of each of the Applets and Classes in that Module – Titles and Icons to be used for each of the Applets – Etc. All of the above information (and more) is stored in a file called “Module Information File.” This file is created by the developers.

8.4 How It All Fits Together

25

Figure 8.1 BREW SDK working compononent

8.5 Writing a BREW application

Figure 8.2 Interaction of BREW application with BREW SDK In the diagram above, the BREW MIF Editor creates one or more MIFs for the applet and places them in the appropriate MIF directories. The BREW Resource Editor creates a Resource file named app.bar containing the character strings, bitmaps, and dialogs the applet loads during its execution. The Resource Editor assigns IDs to these resources and creates a header file called app_res.h containing these IDs.This file is included in the applet source file, app.c, which is compiled and linked to produce the applet’s dynamic-link library (DLL) file, app.dll When you launch the BREW Emulator, it opens the image of the device defined in the configuration file dev.qsc. The BREW Emulator searches the specified MIF directory and shows a list containing all applets with MIFs in that directory, including

26

the applet named app. The MIFs contain bitmap icons for each applet. For the best possible display, create separate MIF files with icons for each possible device color depth (monochrome, grayscale, 256-color). The MIF file color depth matches the device color depth contained in the configuration file dev.qsc. You then choose the applet app from the list. The BREW Emulator loads app.dll and executes the applet, showing its initial screen on the device image. Click the device keys to provide key input to the applet and observe its behavior, including its output to the screen. To emulate an applet on a different device, load a device configuration file other than dev.qsc into the Emulator. An active device consists of a resource file, generated by the BREW Device Configurator, and device bitmap image files. The resource file encodes information about the device and its components and also contains references to image files of the device. For each active device, the resource file contains information about general device attributes and specific device objects and their attributes.

27

9. BREW Development Process

Figure 9.1 BREW application development process.

Uptill now we are describing the BREW as an technology. Now before I end the BREW discussion, I am presenting the BREW as the Business model in the following last point.

28

10. An Integrated Business Model
The BREW solution takes a holistic approach to the business model. BREW is free to handset manufacturers, free to developers, low cost for operators and includes both a complete technology solution and business model. The BREW application execution environment answers technology requirements by: • Providing a uniform and interoperable method for discovering, buying, downloading and managing applications on client devices – including Java applications; • Serving all wireless technology standards and virtually any mobile device; • Enabling mass-market devices more quickly, tightly integrating with the device chipset and efficiently supporting real-time applications. Distribution, management and the sale of BREW applications are the core of the BREW business model. It includes a virtual marketplace for developers and network operators to buy and sell applications. Application developers submit their applications for testing (see discussion below). Once approved and digitally signed, the applications become available to network operators. Application testing is made available to operators, and BREW applications are tested at their request. The operators select the applications they want to offer to their customers and negotiate a price directly with the developer. The network operator can choose a retail price that makes sense for the application and the market. In some cases, the network operator might mark up the price for additional profit. In other cases, such as an advertiser-subsidized application, the operator could offer the application for free or at a reduced price. The operator is in control of what applications are available and what they cost – and can design an offering that bests suits the demands of its customers.

29

10.1 Reliable, High-Quality and Safe Applications
The new mobile environment with downloadable applications will have new challenges such as the frustrations of viruses, hackers, poor usability and software crashes. The inevitable result is two-fold: First, the customer becomes disenchanted with the service (and tired of frequent warnings from the network operator), and hence is reluctant to trust the phone or the operator. Second, the network operator is forced into a role of reactively screening and patching to stop viruses as they appear – an expensive, unreliable, and ultimately frustrating approach. In addition to hacking and viruses, poor quality (but benign) applications also degrade the perceived value of service offerings. Customers expect services to work reliably and predictably. Poor quality applications, even those provided by third parties, reflect badly on the overall service offering. To protect the value of the service offering, it is imperative that some method be implemented to protect the customer from malicious or low-quality applications while simultaneously enabling choice. Here, BREW excels by bundling its core technology model with a process to ensure quality. Applications, at an operator’s request, may be thoroughly tested by National Software Testing Laboratory, an independent testing firm, before they are implemented on mobile networks. Only BREW applications are digitally signed by the developer, by The BREW software environment on the mobile device looks for those digital signatures and will not allow the download or execution of any application that has not been correctly signed. As a result, BREW applications are secure and reliable – and they build trust and value in the eyes of customers.

This ends my discussion on BREW. This whole discussion can be summarized as follow : Summary
Only the BREW platform forms a complete, open solution that encompasses the full range of market requirements, including: • The ability to provision, download, sell and manage applications without custom systems integration.

30

• • •


• • •

High-value applications that increase ARPU, including realtime applications. A good customer experience on any network, and in any payment mode. The ability to work well on lower-priced, mass-market handsets in addition to high-end, feature-rich phones. Minimal barriers to entry, including a low learning curve for developers, no cost to manufacturers, minimal cost to operators and easy implementation. No need to re-write code to access core functions of different model devices. An integrated method to ensure the quality, security and reliability of applications. A guaranteed revenue model for network operator and application developer.

The BREW platform is uniquely positioned to enable the mobile applications of the future, while supporting the technologies and business requirements of the wireless industry.

Conclusion
What can you conclude from whole above discussion ? Is I am the person from the marketing department of QUALCOMM and advertising their great product BREW ? The answer is NO. (It is my bad luck !) The general observation shows that many s/w developer are apart from the wireless industry. They didn’t thought as that it can be the field for them. I am discussing this topic preferably because I think it opens the door for software developers like us for developing the application for the wireless industry. This is the huge opportunity for us. Think on it.

31

References:

WWW.QUALLCOMM.COM

32

Report Documentation & Accounting Page
Report Code: -BE-Seminar 2k2 – 2k3. Report Number: 47

Address of institute: Computer Department, K.K.Wagh Engineering College, Hirabai Haridas Vidya Nagri,
Amrutdham, Nashik

Pin – 422 003, Maharashtra. INDIA.
[email protected]

Report Title: Binary Run Time Environment for Wireless ( BREW)

Author [with Address, phone, E-mail]: Address : Rahul Smruti ‘ , N-8/E-2/18-1, Sane Guruji chowk , New cidco , Nasik-422009 Ph: (0253) 399510

Author Details: Year: 2002 – 2003.

Branch: Computer Engineering Roll: E-mail: [email protected] Type Of Report: FINAL Time Covered (From–To) 2-July-2002 TO 11-Aug-2002 47.

Date Of Report (Date, Month, Year):
11- Sept - 2002.

Page Count 34

Key Words: ARPU :Average Revenue Per User,OEM : Original
Equipment Manufacturer,WAP : Wireless Application Protocol. MIF : Module Interface File, PDA : Personal Digital Assistant. SDK : Software Development Kit, JVM : Java Virtual Machine. CDMA: Code Division Multiple Access , API :Application Program interface
Report Checked By: Report Checked Date: Guides Complete Name: Mr. N.M.Shahane. Report Abstract: This reports gives the basic idea about the BREW – Technology and Integrated business model. It gives basic need for the wireless network and how it fulfilled by the BREW. It mainly focuses on the Developers view provided by the BREW. Total Copies 3

33

34

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close