Pages

Friday, December 31, 2004

SOAP Building Blocks

A SOAP message is an ordinary XML document containing the following elements:

* A required Envelope element that identifies the XML document as a SOAP message
* An optional Header element that contains header information
* A required Body element that contains call and response information
* An optional Fault element that provides information about errors that occurred while processing the message

All the elements above are declared in the default namespace for the SOAP envelope.


Syntax Rules for SOAP

Here are some important syntax rules:

* A SOAP message MUST be encoded using XML
* A SOAP message MUST use the SOAP Envelope namespace
* A SOAP message MUST use the SOAP Encoding namespace
* A SOAP message must NOT contain a DTD reference
* A SOAP message must NOT contain XML Processing Instructions

Friday, December 24, 2004

JAVA talk : Collection Interface

Collection

The Collection (in the API reference documentation) interface is the root of the collection hierarchy. A Collection represents a group of objects, known as its elements. Some Collection implementations allow duplicate elements and others do not. Some are ordered and others unordered. The JDK doesn't provide any direct implementations of this interface: It provides implementations of more specific subinterfaces like Set and List. This interface is the least common denominator that all collections implement. Collection is used to pass collections around and manipulate them when maximum generality is desired.

JAVA talk : ArrayList Class

public class ArrayList
extends AbstractList
implements List, RandomAccess, Cloneable, Serializable

Resizable-array implementation of the List interface. Implements all optional list operations, and permits all elements, including null. In addition to implementing the List interface, this class provides methods to manipulate the size of the array that is used internally to store the list. (This class is roughly equivalent to Vector, except that it is unsynchronized.)

The size, isEmpty, get, set, iterator, and listIterator operations run in constant time. The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList implementation.

Each ArrayList instance has a capacity. The capacity is the size of the array used to store the elements in the list. It is always at least as large as the list size. As elements are added to an ArrayList, its capacity grows automatically. The details of the growth policy are not specified beyond the fact that adding an element has constant amortized time cost.

An application can increase the capacity of an ArrayList instance before adding a large number of elements using the ensureCapacity operation. This may reduce the amount of incremental reallocation.

Note that this implementation is not synchronized. If multiple threads access an ArrayList instance concurrently, and at least one of the threads modifies the list structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more elements, or explicitly resizes the backing array; merely setting the value of an element is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the list. If no such object exists, the list should be "wrapped" using the Collections.synchronizedList method. This is best done at creation time, to prevent accidental unsynchronized access to the list:

List list = Collections.synchronizedList(new ArrayList(...));


The iterators returned by this class's iterator and listIterator methods are fail-fast: if list is structurally modified at any time after the iterator is created, in any way except through the iterator's own remove or add methods, the iterator will throw a ConcurrentModificationException. Thus, in the face of concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future.

Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.

This class is a member of the Java Collections Framework

Sunday, December 12, 2004

Wireless Industry Growth Depends on Rich Data Services

Read what John Pallatto has to say on mobile content :

The sale of data services is going to drive the growth and profitability of the wireless telecommunications industry as voice services continue to come under increasing price pressure, said Paul Jacobs, president of Qualcomm Corp.'s wireless and Internet Group.

"Our industry is going through a fundamental change" because it is moving from selling voice service that has been commoditized to selling data services that provide added value and differentiation to operators' offerings, Jacobs said in his CTIA Wireless show keynote here on Tuesday.

"This change is rippling all through the industry" and will continue to gather momentum, he said. Wireless carriers are adding as many new services as they can, including ring tones, games, e-mail and instant "press to call" services, he noted.

Many wireless phone operators, especially those in Asia, are making plenty of money, but data services is what is going to keep them going, Jacobs said. "Voice is still a very important service, but data is going to be the thing that drives an operator's service … at a time when voice revenues are under pressure, he said.

Jacobs predicted that data services will generate as much as 25 percent of wireless operators' revenues by 2008.

HSDPA, WiMax Show Mobile Enterprise Promise

Andrew Garcia shares his findings on further improvements to the underlying GSM (Global System for Mobile Communications) architecture :

HSDPA (High Speed Downlink Packet Access), a software upgrade to WCDMA (Wideband Code Division Multiple Access), is an asymmetric data transmission technique expected to deliver a download capacity of 2M bps to 3M bps and an uplink speed of 384K bps. Cingular Wireless LLC is expected to conduct initial trials of HSDPA next year, with wider deployment in 2006.

However, getting the most buzz in the mobile-data-access industry right now is 802.16e, the mobile version of WiMax (Worldwide Interoperability for Microwave Access). WiMax has significant backing from Intel Corp., and the fixed-point variety, 802.16a, has already been ratified. The mobile version of the standard is expected to be ratified early next year, with consumer products available in 2006.

WiMax, a method of broadband wireless access, uses frequency bands between 2GHz and 11GHz and does not require line of sight to the base station. Each WiMax base station will theoretically have a range of 50 kilometers, serving thousands of concurrent connections under ideal circumstances.



802.20 is another fledgling standard designed for mobile data access. Unlike WiMax, which relies on a limited number of base stations in a metropolitan area, 802.20 is a more cell-like option that is designed for high-speed mobility and promises throughput exceeding 1M bps.

Flarion Technologies Inc., a major proponent of 802.20, has been testing its FLASH-OFDM (Fast Low-latency Access with Seamless Handoff Orthogonal Frequency Division Multiplexing) technology with Nextel Communications Inc. However, the standards proceedings are not far along, so there's no guarantee that Flarion's technology will ultimately form the basis of the standard.

Both 802.16e and 802.20 could also be hampered by carrier adoption rates. Mobile device connectivity for high user densities will require a significant infrastructure build-out, and carriers may ultimately view this deployment as an unnecessary duplication.

Of course, the unquenchable thirst for unfettered mobile access to data stems, in part, from the rapid proliferation of 802.11-based WLAN (wireless LAN) technologies in the home, the workplace and public hot spots. Indeed, the steady increase of Wi-Fi hot spots in public locations has fostered expectations of being able to connect to the Internet from anywhere. However, relying on public hot spots is a dicey proposition because coverage and throughput will be unpredictable and access could require payment to several entities managing the hot spots.