On re-entrant SBBs safety (August 12, 2008)
I was always wondering what does “re-entrant” property of SBB mean. SLEE specification warns developer about potential problems related to multithreading (section 6.11):
An SBB Developer can specify that an SBB component is non-reentrant. If an SBB entity of a non-reentrant SBB component is executing in a given transaction context, and another method invocation with the same transaction context arrives for the same SBB entity, the SLEE will throw an exception to the second request. This rule allows the SBB Developer to program the SBB component as single-threaded nonreentrant code.
When one of our SBBs required the loopback call to be possible, I have investigated the different possibilities for the potential error here. It all boils down to the
possibility for SBB to hold some custom state (for stateless objects re-entrant invocations from multiple threads are safe) and to the concurrency control of the event
delivery. In our case the dependencies between two SBBs could be depicted as below. Note that I am using create stereotype everywhere, implying that SBB
entity for SBB A is created during the process of initial event delivery, and SBB entity for SBB B is created after invocation of ChildRelation.create()
method. We will see below that this simplification does not influence the final conclusion.
The actual details of the local method invocations (probably involving proxies) at steps 12 and 13 are omitted. Two questions arise here:
- Is the invocation at step 13 delivered to the same SBB object (remember the mentioned proxies)?
- Is the state of this object the same as before the invocation?
The answer for the first question is “we don’t actually care”. Section 2.2.7 of the SLEE specification says that “the SLEE may assign zero or more SBB objects to represent an SBB entity”, but 6.5.1 prohibits using of class fields for storing local object state. This means that even if the invocation 13 is delivered to another SBB object (and here we are coming to the answer for the second question), then its state would be the same.
But this is not all. A more complicated situation may occur if:
- SLEE delivers an event in another thread to the same SBB entity somewhere between steps 12 and 13
- …and has chosen for this delivery the same SBB object as for invocation 13
- …and this SBB object is different from the object used for delivery of event Foo (section 8.6.6 guarantees serial invocation order only for event handlers for events delivered in the same Activity Context).
In accordance with section 8.6.6, SLEE guarantees that invocations of any methods on the same SBB object are always serial (i.e. are never overlapping). Therefore, event handler will finish its work before step 13, thus (potentially) changing SBB entity state.
We could conclude the simple rules for re-entrant SBBs:
- Event handlers not changing SBB entity state are always safe for re-entrant SBBs (though local methods invocation could change state)
- If underlying resource (say, network) guarantees event firing order, and latter event handlers do not modify SBB entity state required by former, then this is also safe
I was unable to find any other possible problems with re-entrant SBBs, but readers from jNetX and OpenCloud (I know, there are some) are always welcome to prove me wrong.
Cellular-Internet convergency with quasi-femtocells (July 20, 2008)
There were recent news on BT and T-Mobile USA (at least these two) offering GSM/IP converged services with the additional access poit installed at the subscriber’s premises. I am talking about BT Fusion Mobile and T-Mobile at Home. First product takes advantage of connecting the users of Wi-Fi enabled handsets to the core network over broadband IP connection using UMA. Second one does nearly the same, but the access point contains its own SIM, thus rendering the Wi-Fi capabilities of the handset unnecessary. For the security reasons, T-Mobile at Home allows connection only from the wireline phones attached directly to the router.
These devices both are not pure femtocells, as Telco 2.0 thinks. However, what interesting here from the point of view of service delivery provider, is that Internet and phone line connections could be correlated (i.e. operator could associate the signaling connection with the one for Internet data, despite that they could be esablished from different devices). What about your incoming SMS popping in your Facebook window when you logged on?
JAIN SLEE for uninitiated pt. 3 (June 19, 2008)
A curious reader might ask himself after reading the previous part in JAIN SLEE for uninitiated series: it seems that one SBB could create other SBBs and control their attachment to ACIs, fine. But if these SBBs are components of the bigger application — a service — how could they communicate? (Read more…)
Short on gadgets: Nokia N810 and Amazon Kindle (June 9, 2008)
Though I am in no way a gadget freak, there are still two devices of completely different classes which I personally feel drawn to.
First is the Internet tablet from Nokia, N810. This is the small device with a big screen, suitable for most of the everyday online needs — from watching videos on YouTube to writing emails to your boss; from blogging and RSS aggregation to surfing someone else’s Flickr and updating your own; all thanks to Wi-Fi or WiMAX connectivity. Tablet runs a special version of Debian Linux (developed under Nokia-sponsored Maemo project), whose window system is customized especially for usage in smaller devices. It already has a piece of software of the outstanding quality (Canola2), popular programming language available on the system (Java) and a huge army of developers familiar with Linux matters.
Though 3G connectivity would fit well in this sort of device, it is not there: N810 lacks phone functionality. It deals with some of the things we are usually doing on the computer, but these are actually the things common user spend most of his time with. When devices of this class will become mainstream, they probably will not replace the computer for the secretary (office suites fit bad into smaller sizes), but travel photographers will stay connected to their Flickr even on the road, leave alone teenagers with MySpace. Seems like a good way to physically separate the entertainment information streams with the really important things normal computers are built for.
The second one is Amazon Kindle. Ebook readers are here for almost a decade, and none of them got so much attention as Kindle has. Apart from the general popularity of Amazon, which made half of the deal, Kindle is different in some ways. First, it is not tightly bound to any proprietary format (this is what have killed now belonging to the history Sony LIBRIé). Second, it could be used as a standalone device with 3G connectivity over Whispernet (note the brilliant brand name). The good guys at Telco 2.0 give a detailed analysis of the way Kindle works with Whispernet, and I could just add that this idea is so simple and so promising for both operator and device manufacturer that I have some amount of envy that it wasn’t me who even ever thought about this (kidding).
It is quite hot and sunny here in Austria, a host country for now ongoing UEFA Euro Championship, but Kindle works even in direct sunlight, and viennese Wi-Fi capacity is able to deal with all those football lovers together with one more N810 being on.
P.S. And yes, I have a special opinion on iPhone (including the recently announced iPhone 3G), though prefer to keep it.
Next in our series will be the last part of JAIN SLEE for unintiated. Don’t leave.
JAIN SLEE for uninitiated pt. 2 (May 31, 2008)
This is part two of JAIN SLEE for uninitiated tutorial. We have been talking last time about the functions provided by different components, and now there’s a little more about the way components are treated in SLEE. (Read more…)