|By Jim Keogh||
|January 1, 2003 12:00 AM EST||
J2ME developers have long desired the opportunity to build sophisticated applications for the personal digital assistant (PDA) market, applications common to resource-rich desktop computers. One thing stood in their way: most PDAs lacked resources to efficiently execute those applications.
However, that's about to change with the introduction of ARM processor-based PDAs and the PDA Profile that's soon to be incorporated in SDKs and VMs.
Improvements in processor design have transformed new PDAs into a powerhouse platform capable of running sophisticated J2ME applications and clients of enterprise Java systems. New PDAs bring higher performance previously known only on desktop computers.
With performance and power barriers removed from the new PDA, a committee of the Java Community Process that included PalmSource, the software division of Palm, defined a new profile called the PDA Profile (PDAP) that introduces classes for building highly responsive J2ME applications.
PDAP is an extension of the Connected, Limited Device Configuration (CLDC) 1.1 and the Mobile Information Devices Profile (MIDP) 1.0. New PDAs powered by an enhanced processor are capable of running both MIDP applications and PDAP applications using a PDAP-enabled VM. There are two key features introduced with the PDAP: the capability to develop sophisticated graphical user interfaces for a PDAP application using the Abstract Windowing Toolkit (AWT - a subset of the J2SE AWT), and the capability to access a PDA's native personal information data. A PDAP application can access data managed by the PDA device's address book, calendar, and to-do list applications.
The New PDA
I use the term "new PDA" to describe the latest incarnation of a PDA, but that doesn't help you know if a PDA can run PDAP applications. A better definition of "new PDA" is to describe the footprint required to run a PDAP application.
A PDA must have a minimum of 1,080KB of memory: 500KB for CLDC and MIDP, 540KB for the PDAP user interface libraries, 20KB reserved for the PIM API, 10KB for the Generic Connection Framework, and another 10KB for the PDAP security model. Table 1 describes other hardware configurations that are required to run a PDAP application.
PDAP and MIDlets
A PDAP application is called a PDAlet, which is a variation of the MIDlet application model. Actually, a PDAlet is a MIDlet that uses the PDAlet API and follows the same principles used in a MIDlet and MIDlet suite.
There isn't a PDAlet class because a PDAlet is a conceptual entity that refers to the capabilities and requirements of a PDAlet. A PDAlet is created by defining a class that extends the MIDlet class. Think of it as an extension of a MIDlet; those rules that apply to a MIDlet also apply to a PDAlet.
Listing 1 shows an empty MIDlet and Listing 2 converts this empty MIDlet into an empty PDAlet by calling the getDefaultToolkit() method within the startApp() method. The default toolkit is a subset of AWT and is used to create a GUI for the PDAlet. The getDefaultToolkit() method makes the PDAP API available to the PDAlet.
Although many developers will use AWT components to build a GUI for their PDAP application, a GUI isn't required for a PDAlet. You can create a PDAlet without having a GUI by calling the Display.setCurrent(null) method within the startApp() method. The PDAlet is then placed in the active-without-UI state, which means the PDAlet is still active but the implementation determines what, if anything, is displayed on the screen.
The PDAlet Suite
A PDAlet suite's functionality is similar to a MIDlet suite's in that both are packages of PDAlets and MIDlets, respectively. Suites make it easy for the developer to group related PDAlets and MIDlets for deployment and installation.
A PDAlet suite is a bundle of PDAlets and MIDlets that's implemented simultaneously on a PDA. All PDAlets (and MIDlets if any) within a PDAlets suite are considered a group and must be installed and uninstalled as a group. Each PDAlet and MIDlet within the PDAlet suite must be listed in the PDAlet suite's manifest, which is also contained in the PDAlet suite.
Members of a PDAlet suite share the same resources from the host environment and share the same Java class instances, and run within the same JVM. This means if three PDAlets from the same PDAlet suite run the same class, only one instance of the class is created. A key benefit of the relationship between PDAlet suite members is that they share the same data, including persistent storage such as that used to store user preferences.
Sharing data among PDAlets exposes each PDAlet to data errors caused by concurrent read/write access to data. However, this risk is reduced because synchronization primitives on the PDAlet suite level restrict access to both volatile and persistent data.
Data cannot be shared between PDAlets that are from another PDAlet suite because the PDAlet suite name is used to identify data associated with the PDAlet suite. A PDAlet from a different PDAlet suite is considered an unreliable source.
A PDAlet suite is installed, executed, and removed by the application manager running on the device (the manufacturer of the PDA provides the application manager).
Once a PDAlet suite is installed, the application manager gives each member of the PDAlet suite access to JVM and CLDC classes. Likewise a PDAlet can access classes defined in the MIDP and PDAP to interact with the user interface, network, and persistent storage.
The application manager also makes the Java Archive File (JAR) file and the Java application descriptor file (JAD) available to members of the PDAlet suite. Note that the JAD file is optional.
All the files that are necessary to implement a PDAlet suite must be contained within a production package called a Java Archive File (JAR). These files include PDAlet classes, graphic images if required by a PDAlet, and the manifest file.
A PDAlet suite is created almost the same way you create a MIDlet suite except PDAlets are identified within the PDAlet suite's manifest using the PDAlet=<name> attribute, where name represents the name of the PDAlet class.
The manifest file contains a list of attributes and related definitions that are used by the application manager to install the files contained in the JAR onto the small computing device. There are 10 attributes that are defined in the manifest file; all but seven of these attributes are optional.
Table 2 lists attributes contained in a manifest file. Of these, the following attributes are required for every manifest file. Failure to include them causes the application manager to halt the installation of the JAR file.
Listing 3 is a manifest file that contains the minimum number of attributes. All these attributes are required for a PDAlet manifest. Create a manifest file as a text file with the .txt file extension using an editor. The manifest file's file extension is changed to .mf when the PDAlet suite is prepared for deployment.
Entries in the manifest are name:value pairs and can therefore appear in any order within the manifest file. Each pair must be terminated with a carriage return. Whitespace between the colon and the attribute value is ignored when the application manager reads the manifest file.
Let's step through the manifest file shown in Listing 3. The MIDlet-Name attribute specifies the name of the PDAlet suite. The MIDlet-Version and MIDlet-Vendor attributes identify the version number of the PDAlet suite and the company or person who provided it.
The MIDlet-n attribute and the PDAlet-n attribute contain information about each MIDlet and each PDAlet that is in the JAR file. The number of the MIDlet and PDAlet replaces the letter n. The MIDlet-n attribute and the PDAlet-n attribute can contain three values that describe the MIDlet/PDAlet. A comma separates each value.
The first value is the name of the MIDlet/PDAlet. Next is an optional value that specifies the icon that will be used with the MIDlet/PDAlet. The icon must be in the Portable Network Graphics (PNG) image format. The last value for the MIDlet/PDAlet attribute is the MIDlet class name. The application manager uses the class name to load the PDAlet.
The next MIDlet/PDAlet attribute is the MicroEdition-Profile, whose value is the J2ME profile that's required to run the PDAlet. In this example the PDAP-1.0 profile is required. And the last MIDlet/PDAlet attribute is the MicroEdition-Configuration, which identifies the J2ME configuration that's necessary to run the MIDlet/PDAlet.
Attributes can be listed in any order in the PDAlet manifest and may contain spaces. The PDAlet manifest cannot have the MIDlet-Jar-URL and MIDlet-Jar-Size attributes. Both these attributes are permitted in the MIDlet manifest.
A PDAlet suite can contain PDAlets and MIDlets, and both are listed in the manifest as illustrated in the previous example. Both a PDAlet and a MIDlet listed in the manifest can provide the same functionality except that the PDAlet uses the PDAP API and the MIDlet uses the MIDP API.
If the implementation doesn't support the PDAP API in the VM, both PDAlets and MIDlets in the PDAlet suite won't run. However, you can specify that a MIDlet should run in place of a PDAlet by assigning the same index number to a PDAlet and a MIDlet. The PDAlet runs if the implementation supports the PDAP API, otherwise the MIDlet runs.
Listing 4 illustrates this technique. Notice there are two poker programs in this manifest. The first is MIDlet-2 and is called poker. The other is PDAlet-2 and is called PDAPoker. Since MIDlet-2 and PDAlet-2 have the same index number, the PDAPoker is the preferred poker program if the device supports the PDAP API. The MIDlet-2 program is used if the device does not support the PDAP API.
It's critical that the numbering sequence of MIDlets and PDAlets remain sequential without duplication except to resolve preferences, as in the case of PDAlet-2. Although there are six programs in the manifest in Listing 4, only five programs are visible to the implementation. Only one program is visible per index number.
Both the PDAP 1.0 and CLDC 1.1 APIs must be present on the device to install and execute the PDAlet suite, because these values are specified in the MicroEdition-Profile and MicroEdition-Configuration attributes in the manifest. The MIDP 1.0 API is implied whenever you specify the PDAP 1.0 profile in the MicroEdition-Profile attribute. However, you can explicitly specify the MIDP 1.0 API and the PDAP 1.0 profile together by including the MIDP 1.0 in the MicroEdition-Profile attribute as shown here:
MicroEdition-Profile: PDAP-1.0 MIDP-1.0
A PDAlet suite that contains both MIDlets and PDAlets requires both the PDAP API- and the MIDP API-compatible VM to install and execute the PDAlet suite. However, there are times when you want the PDAlet suite to be installed and execute only the MIDlets within the PDAlet suite if the VM is only MIDP 1.0. In this situation, you can specify that the PDAP API is optional.
To specify that the PDAP API is optional to run the PDAlet use the MicroEdition-Profile-Opt manifest attribute as shown in the following code segment. The PDAlet suite will install and execute on a MIDP 1.0-only VM. Only MIDlet programs will be installed and executed. PDAlets are considered application-specific attributes and are not available for execution.
Java Application Descriptor File
Application management software uses a Java Application Descriptor File (JAD) to manage the PDAlet, and the JAD can be used by the PDAlet to configure specific attributes. You may include a JAD within the JAR file of a PDAlet suite as a way to pass parameters to a PDAlet without modifying the JAR file. A JAD file is also used to provide the application manager with additional content information about the JAR file to determine if the PDAlet suite can be implemented on the device.
A JAD file is similar to a manifest in that both contain attributes that are name:value pairs. Name:value pairs can appear in any order within the JAD file. There are six required system attributes for a JAD file, see below. A system attribute is an attribute that's defined in the J2ME specification. Table 3 contains a complete list of system attributes. All JAD files must have the .jad extension. Listing 5 illustrates a typical JAD file.
The JAD file shown in Listing 5 contains a few attributes that are also found in the manifest file. The first three attributes in the JAD are identical to attributes in the manifest file.
The MIDlet-Jar-URL attribute contains the URL of the JAR file, which in this example is called bestmidlet.jar. The last required attribute in the JAD file is the MIDlet-n and PDAlet-n attribute that defines a PDAlet and MIDlet of the PDAlet suite that's identical to the PDAlet-n and MIDlet-n attributes of the manifest. A MIDlet-n attribute is required for each MIDlet in the PDAlet suite, and a PDAlet-n attribute is required for each PDAlet in the PDAlet suite.
A word of caution: the values of the MIDlet-Name, MIDlet-Version, and MIDlet-Vendor attributes in the JAD file must match the same attributes in the manifest. If the values are different, the application manager uses the attribute of the JAD file. Failure to include these attributes in the JAD file will prevent the JAR file from loading into the device.
A developer can include application attributes in a JAD file. An application attribute is a name:value pair that contains a value unique to the application. Any name can be given to an application attribute as long as the name does not begin with MIDlet-, PDAlet-, or MicroEdition-.
Abstract Windowing Toolkit
The PDA profile uses common user interface elements of the Java Abstract Windowing Toolkit (AWT) as the user interface solution for PDAlets. These user interface elements are native to many PDAs that use the ARM processor.
The AWT used in the PDA profile is a subset of the J2SE AWT that's designed to utilize the limited display space and memory constraints found in a PDA. This subset contains all the features that you'll require when developing a PDA application.
A subset of AWT is used as the user interface API for two J2ME profiles: Personal Basis Profile (PBP) and Personal Profile (PP). Each is used for a targeted class of devices. As a point of reference, the PDAP AWT is a subset of the Personal Profile.
The PDA Profile subset contains support for all but the following features:
- Serialization of UI components
- Object cloning
- J2SE security model
- Buffered images
- Data transfer APIs
- Alpha composite image manipulation
PDAlets run on a variety of PDA devices, each having support for some set of graphical user interface elements. Fortunately for developers, PDA devices that run PDAP API-capable VMs must adhere to a minimum of GUI elements that enable you to design a PDAlet that can take advantage of these GUI elements.
Color choices for your PDAlet GUI might be limited to black and white since these are the only two colors that an implementation is required to support. Realistically, however, many implementations will support a variety of colors through the RGB constructor for the Color class. Therefore it's wise to test your PDAlet on as many implementations as possible to be assured that your color choices don't negatively impact your application.
You also need to be alerted to the fact that some implementations that support a broad color palette may not permit you to change the colors of standard GUI elements such as menus and title bars. However, this lack of support doesn't prevent you from calling methods to change the color of those elements. The implementation won't throw an error, but will simply ignore your request to change the color of the element.
In some PDAlets you may want to set your own cursor using the AWT Component class. While setting the cursor is commonplace in J2SE applications, you might not be able to do so using the PDAP API because some implementations may prohibit such settings. Attempts to set the cursor will cause a silent error. The implementation will continue to run your PDAlet, but ignore your request to change the cursor.
Avoid using a variety of fonts in your application's graphical user interface because they may not be supported by the implementation. The PDAP only requires support for Font.Plain. Support for other fonts is implementation dependent. You can't assume that a font other than Font.Plain is available unless your application is tailored to run on a specific implementation.
Another limitation of running a PDAlet is thread safety. The PDAP does not mandate that AWT be thread safe. Therefore, avoid concurrent access to GUI objects using different threads. However, you can use a system event thread to enable concurrent access by calling the static invokeLater() method and the invokeAndWait() methods of the EventQueue class.
AWT offers window management capabilities that enable you to instantiate frames, windows, and dialogs from anywhere in the PDAlet and then show them by calling appropriate methods. All PDAP implementations support multiple top-level windows that are visible at any given time.
However, there are window management limitations that restrict windowing. Only one top-level window (window, frame, or dialog classes) can be shown (seen by the user) and active (has input focus) at a time. Some implementations might permit multiple top-level windows to be shown and be active simultaneously.
Tip: The implementation determines the behavior of windowing for the application if your PDAlet does not make a top-level window visible.
Top-level windows may not be resizable by your PDAlet or by the user, and calls to the setSize() method are silently ignored. Therefore, you should assume that resizing is not available unless you're designing an application for a specific PDA that you know enables top-level windows to be resized.
Likewise, you should expect that the implementation might limit or prohibit the resizing of dialogs. Attempts to change the size of a dialog may result in a different size than the size you requested - or no change whatsoever. Implementations that prohibit resizing of dialogs will not notify your application that an attempt to resize has failed. Instead, they ignore your request to resize the dialog.
Always minimize the need to change the size of a dialog within your application. If you must change the dialog size, make sure you test those changes on all the implementations that will be running your application in order to determine the visual effect those changes have on the application's graphical user interface. Failure to do so might result in an unexpected GUI for your PDAlet.
Additional restrictions might apply to the location of dialogs on the screen. Some implementations may limit the location on the screen where you can display the dialog, and other implementations outrightly prohibit the application to determine where the dialog is displayed on the screen. And, as with other prohibitions discussed in this section, your PDAlet continues to run uninterrupted because your request for change is ignored by the implementation.
PDAP does not require that an implementation provide a means to display a title for a dialog. This means that calling the setTitle() method and getTitle() method have no effect on the dialog.
Frames also have many of the restrictions found in dialogs. You can expect that an implementation will support a one-sized frame that can't be resized by a user or an application. An attempt to size or resize a frame causes a silent error to occur without an error message being sent to your application.
Likewise, the location of a frame is determined by the implementation, not by the application or the user of the application. Frames also can't be iconified or titled. As with all the restrictions discussed in this section, an implementation may not have these restrictions.
Personal Information Management
A PDA device has native personal information management (PIM) data that's managed by personal information applications that run on the PDA device. The PDA profile requires that an implementation grant PDAlets access to PIM data. This means that your PDAlet can access data managed by the PDA device's address book, calendar, and to-do list applications. PIM data does not have to reside on the device. Your PDAlet can access the data even if the information is contained on a remote device, such as a PC that's linked to the PDA device.
The PDAP API implementation will handle security management to prevent unauthorized Java applications from accessing PIM databases. The implementation also provides a mechanism to enable a PDAlet to access PIM data efficiently without hindering performance.
PIM data can be imported and exported using a format specified by the Internet Mail Consortium. The vCard 3.0 format is used for address book entries and the vCalendar 1.0 format is used for calendar and to-do entries.
You can access PIM data directly from your PDAlet by using the PDAP PIM API found in the javax.microedition.pim package. All PDAP implementations support the PDAP PIM API.
There are three types of PIM databases supported by the PDAP PIM API: Event, Contact, and ToDo. The Contact Database also supports a photo field that can receive and store data in any of the IANA registered image formats or a nonstandard image format. The Photo field is consistent with the definition of the PHOTO field in the vCard specification and must support the Portable Network Graphics (PNG) format.
Every PDAP implementation must have an HTTP connection for networking devices, which is the same requirement for the MIDP profile. However, some implementations may support the Generic Connection Framework API, the logical serial port connection using CommConnection class, as well as the file systems and/or removable memory cards using the FileConnection class.
Support for the logical serial port connection and for the file systems is dependent on the operating system and hardware support that's available on the device running the PDAP implementation. The device is not necessarily required to have a serial port connection if the device's operating system enables an IR port to be configured as a logical serial port.
The file system of a device that implements PDAP is typically located either in the device's memory or on memory cards, depending on the device and the limits of the operating system. Memory cards that contain file systems include:
- SmartMedia Card (SSFDC)
- CompactFlash Card (CF)
- Secure Digital Card (SD)
- MultiMedia Card (MMC)
- MemoryStick (MS)
There are multiple security features imposed by the PDA profile that protect the user of the application and the device from malicious access and use. The PDA employs the sandbox security model that's implemented in CLDC 1.1 and MIDP 1.0. Security is further enhanced by the authorization security that enforces access privileges on resources of the device. These enhanced security policies will also be found in MIDP 2.0.
The enhanced security policies are hidden from the application and become visible only if a security exception occurs when using the PDAP API privilege functionality. Restrictions and permissible actions are associated with all PDAlets and MIDlets in a PDAlet suite and all code that runs on behalf of a member of the PDAlet suite.
The implementation determines how authorization results and configuration settings are presented to the user in the user interface. However, the implementation will require privileges to:
A Welcome Addition
J2ME developers who design and build applications for PDAs will find the PDA Profile an invaluable addition to their development arsenal, enabling the creation of powerful applications that take advantage of a new PDA footprint. The PDA Profile provides specifications for a rich set of AWT components that are used to implement sophisticated graphical user interfaces for PDA applications, GUIs similar to those found on desktop applications.
The PDA Profile also gives J2ME applications access to information stored on a PDA by proprietary, personal information management software that OEMs supply with the devices. This means your J2ME application can interact with a PDA's address book, calendar, and to-do list, including storing your own information in the databases used by these applications. Combining connectivity and security capabilities with AWT and personal information management, the PDA Profile is the right tool for every J2ME developer.
In his General Session at 16th Cloud Expo, David Shacochis, host of The Hybrid IT Files podcast and Vice President at CenturyLink, investigated three key trends of the “gigabit economy" though the story of a Fortune 500 communications company in transformation. Narrating how multi-modal hybrid IT, service automation, and agile delivery all intersect, he will cover the role of storytelling and empathy in achieving strategic alignment between the enterprise and its information technology.
Jan. 18, 2017 04:45 PM EST Reads: 4,501
Buzzword alert: Microservices and IoT at a DevOps conference? What could possibly go wrong? In this Power Panel at DevOps Summit, moderated by Jason Bloomberg, the leading expert on architecting agility for the enterprise and president of Intellyx, panelists peeled away the buzz and discuss the important architectural principles behind implementing IoT solutions for the enterprise. As remote IoT devices and sensors become increasingly intelligent, they become part of our distributed cloud enviro...
Jan. 18, 2017 04:30 PM EST Reads: 4,620
With major technology companies and startups seriously embracing IoT strategies, now is the perfect time to attend @ThingsExpo 2016 in New York. Learn what is going on, contribute to the discussions, and ensure that your enterprise is as "IoT-Ready" as it can be! Internet of @ThingsExpo, taking place June 6-8, 2017, at the Javits Center in New York City, New York, is co-located with 20th Cloud Expo and will feature technical sessions from a rock star conference faculty and the leading industry p...
Jan. 18, 2017 03:30 PM EST Reads: 3,666
"LinearHub provides smart video conferencing, which is the Roundee service, and we archive all the video conferences and we also provide the transcript," stated Sunghyuk Kim, CEO of LinearHub, in this SYS-CON.tv interview at @ThingsExpo, held November 1-3, 2016, at the Santa Clara Convention Center in Santa Clara, CA.
Jan. 18, 2017 02:45 PM EST Reads: 1,585
Things are changing so quickly in IoT that it would take a wizard to predict which ecosystem will gain the most traction. In order for IoT to reach its potential, smart devices must be able to work together. Today, there are a slew of interoperability standards being promoted by big names to make this happen: HomeKit, Brillo and Alljoyn. In his session at @ThingsExpo, Adam Justice, vice president and general manager of Grid Connect, will review what happens when smart devices don’t work togethe...
Jan. 18, 2017 02:00 PM EST Reads: 373
"There's a growing demand from users for things to be faster. When you think about all the transactions or interactions users will have with your product and everything that is between those transactions and interactions - what drives us at Catchpoint Systems is the idea to measure that and to analyze it," explained Leo Vasiliou, Director of Web Performance Engineering at Catchpoint Systems, in this SYS-CON.tv interview at 18th Cloud Expo, held June 7-9, 2016, at the Javits Center in New York Ci...
Jan. 18, 2017 01:00 PM EST Reads: 5,592
The 20th International Cloud Expo has announced that its Call for Papers is open. Cloud Expo, to be held June 6-8, 2017, at the Javits Center in New York City, brings together Cloud Computing, Big Data, Internet of Things, DevOps, Containers, Microservices and WebRTC to one location. With cloud computing driving a higher percentage of enterprise IT budgets every year, it becomes increasingly important to plant your flag in this fast-expanding business opportunity. Submit your speaking proposal ...
Jan. 18, 2017 01:00 PM EST Reads: 5,097
Discover top technologies and tools all under one roof at April 24–28, 2017, at the Westin San Diego in San Diego, CA. Explore the Mobile Dev + Test and IoT Dev + Test Expo and enjoy all of these unique opportunities: The latest solutions, technologies, and tools in mobile or IoT software development and testing. Meet one-on-one with representatives from some of today's most innovative organizations
Jan. 18, 2017 12:15 PM EST Reads: 1,525
20th Cloud Expo, taking place June 6-8, 2017, at the Javits Center in New York City, NY, will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud strategy.
Jan. 18, 2017 12:00 PM EST Reads: 4,228
SYS-CON Events announced today that Super Micro Computer, Inc., a global leader in Embedded and IoT solutions, will exhibit at SYS-CON's 20th International Cloud Expo®, which will take place on June 7-9, 2017, at the Javits Center in New York City, NY. Supermicro (NASDAQ: SMCI), the leading innovator in high-performance, high-efficiency server technology, is a premier provider of advanced server Building Block Solutions® for Data Center, Cloud Computing, Enterprise IT, Hadoop/Big Data, HPC and E...
Jan. 18, 2017 12:00 PM EST Reads: 5,755
SYS-CON Events announced today that Linux Academy, the foremost online Linux and cloud training platform and community, will exhibit at SYS-CON's 20th International Cloud Expo®, which will take place on June 6-8, 2017, at the Javits Center in New York City, NY. Linux Academy was founded on the belief that providing high-quality, in-depth training should be available at an affordable price. Industry leaders in quality training, provided services, and student certification passes, its goal is to c...
Jan. 18, 2017 12:00 PM EST Reads: 1,941
WebRTC is the future of browser-to-browser communications, and continues to make inroads into the traditional, difficult, plug-in web communications world. The 6th WebRTC Summit continues our tradition of delivering the latest and greatest presentations within the world of WebRTC. Topics include voice calling, video chat, P2P file sharing, and use cases that have already leveraged the power and convenience of WebRTC.
Jan. 18, 2017 10:30 AM EST Reads: 3,103
"Matrix is an ambitious open standard and implementation that's set up to break down the fragmentation problems that exist in IP messaging and VoIP communication," explained John Woolf, Technical Evangelist at Matrix, in this SYS-CON.tv interview at @ThingsExpo, held Nov 4–6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
Jan. 18, 2017 09:45 AM EST Reads: 11,553
WebRTC sits at the intersection between VoIP and the Web. As such, it poses some interesting challenges for those developing services on top of it, but also for those who need to test and monitor these services. In his session at WebRTC Summit, Tsahi Levent-Levi, co-founder of testRTC, reviewed the various challenges posed by WebRTC when it comes to testing and monitoring and on ways to overcome them.
Jan. 18, 2017 08:15 AM EST Reads: 5,977
"A lot of times people will come to us and have a very diverse set of requirements or very customized need and we'll help them to implement it in a fashion that you can't just buy off of the shelf," explained Nick Rose, CTO of Enzu, in this SYS-CON.tv interview at 18th Cloud Expo, held June 7-9, 2016, at the Javits Center in New York City, NY.
Jan. 18, 2017 07:45 AM EST Reads: 4,632
DevOps is being widely accepted (if not fully adopted) as essential in enterprise IT. But as Enterprise DevOps gains maturity, expands scope, and increases velocity, the need for data-driven decisions across teams becomes more acute. DevOps teams in any modern business must wrangle the ‘digital exhaust’ from the delivery toolchain, "pervasive" and "cognitive" computing, APIs and services, mobile devices and applications, the Internet of Things, and now even blockchain. In this power panel at @...
Jan. 18, 2017 06:45 AM EST Reads: 2,765
Every successful software product evolves from an idea to an enterprise system. Notably, the same way is passed by the product owner's company. In his session at 20th Cloud Expo, Oleg Lola, CEO of MobiDev, will provide a generalized overview of the evolution of a software product, the product owner, the needs that arise at various stages of this process, and the value brought by a software development partner to the product owner as a response to these needs.
Jan. 18, 2017 06:30 AM EST Reads: 1,186
WebRTC services have already permeated corporate communications in the form of videoconferencing solutions. However, WebRTC has the potential of going beyond and catalyzing a new class of services providing more than calls with capabilities such as mass-scale real-time media broadcasting, enriched and augmented video, person-to-machine and machine-to-machine communications. In his session at @ThingsExpo, Luis Lopez, CEO of Kurento, introduced the technologies required for implementing these idea...
Jan. 18, 2017 06:30 AM EST Reads: 4,633
The WebRTC Summit New York, to be held June 6-8, 2017, at the Javits Center in New York City, NY, announces that its Call for Papers is now open. Topics include all aspects of improving IT delivery by eliminating waste through automated business models leveraging cloud technologies. WebRTC Summit is co-located with 20th International Cloud Expo and @ThingsExpo. WebRTC is the future of browser-to-browser communications, and continues to make inroads into the traditional, difficult, plug-in web co...
Jan. 18, 2017 05:45 AM EST Reads: 2,915
Internet of @ThingsExpo, taking place June 6-8, 2017 at the Javits Center in New York City, New York, is co-located with the 20th International Cloud Expo and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. @ThingsExpo New York Call for Papers is now open.
Jan. 18, 2017 05:15 AM EST Reads: 3,594