Mobility Resources Search Box

Relevant mobility-specific web search.

 

Comments on Nokia's SOA Announcement

by C. Enrique Ortiz, August 3, 2004. Updated on December 2004, November 25, 2006

 

November 25, 2005:
It is time to update this piece titled "Comments on Nokia's SOA Announcement". In 2004 I critized Nokia for introducing their own flavor of Web Services API for Java ME, instead of pushing for the Java Community defined JSR 172 APIs, APIs Nokia also helped define. Recently Nokia announced the S60 platform, and on it I see their support and commitment to JSR 172 Web Services API for Java ME. Thanks Nokia for this decision that helps minimize API fragmentation, and I am looking forward to see your completed SOA architecture for mobile phones...

ceo

On Java One 2004 Nokia announced its vision for a networked service-oriented architecture for mobile phones. I was finally able to find and read the whitepaper. This architecture is interesting indeed, but probably a long way from real adoption. I do understand where they are coming from with an offering, a framework, that provides all the elements that enables SOA-based secure integration to the enterprise. I have some comments/observations:

  • The SOA architecture is Nokia-specific - let me remind mobile application developers to avoid using vendor-specific APIs, as doing so hurts application portability.
  • The architecture seems to further fragment the J2ME APIs - as previously mentioned, the Nokia web services APIs are Nokia specific (i.e. com.nokia.web_services.*) and doesn't seem to promote the standard JSR-172 Web Services API (WSA) for J2ME.  If I recall correctly,  Nokia was part of the expert group that defined the WSA standard API, so I am a bit confused why the introduction of these new (redundant?) APIs.
  • The architecture looks really cool, but I am not sure about its practicality as a whole...

Other observations or questions:

  • How does Nokia feels about API fragmentation? Why not support WSA vs. introducing the com.nokia.web_services.* APIs? Is Nokia starting a new JSR for this?
  • The stack seems heavy and expensive.  I assume that the Nokia Web Services stack will be embedded in the device itself.  This framework is very large, and consist, as illustrated below, of Liberty Alliance modules, service discovery modules, authentication, all kinds of XML application services, XML parser, and various bindings, and even SIP. Can I expect, as a developer, to find all these pieces across all Nokia handsets? Which pieces are mandatory? and which ones will be optional?
  • Is the server framework exclusive to Nokia?  Is this going to be licensed to 3rd parties or open sourced?

Some last words:

  • The architecture claims support for asynchronous messaging. I get many emails people asking how can this be accomplished. To do this, to externally address a device, devices need their own externally visible or public address, being this a telephone number or an IP address (unless Nokia is using a proprietary/hidden way to address their devices). For the former, this is useful if using the Wireless Messaging API (WMA), but using WMA imposes a limitation on the message size, and for the latter it would require a static/public name (DNS) or IP address, which typically translates to higher costs to the end-user.  Support for asynchronous communication may have to be "polling-based", which is more expensive. The examples on the whitepaper only show synchronous requests, very possible for the same reasons I just mentioned.
  • The architecture claims support for service end-points on the device. First, there is the addressability issue mentioned above. Then even though devices as service providers sounds cool, mobile devices which typically are resource constrained, typically are service consumers. Note that service end-points on the device was not included in JSR-172 for these same reasons.
  • Web Services are expensive by nature.  Thought must be given to the request/response nature of  HTTP, and on limiting the number of request/responses iterations (i.e. login, discovery, service invocation). For the benefit of beginner developers, please note that Web Services (and HTTP) is NOT good for streaming - the whitepaper example that shows web services for audio streaming is not the best example to use.
  • Also, the framework seems very enterprise/business oriented, but it is missing device management APIs, which are very important in the enterprise.

I am happy to see, and I support Nokia working on such forward-looking architecture and framework. I am hoping Nokia maintains this open and practical, while minimizing API fragmentation and hype...

Figure 1 - Nokia Open Web SOA (figure taken from Nokia SOA whitepaper)

ceo

 

 

Why Google Ads?
To help subsidy this web site's hosting expenses.