- SbbContextExt - extension of javax.slee.SbbContext interface, exposing methods to retrieve SLEE facilities, factories and RA objects. An API more consistent with the RA API which does not uses JNDI
- ProfileContextExt - extension of javax.slee.ProfileContext, exposing a method to retrieve the Alarm Facility, same reasoning as the extension of SbbContext
- ActivityContextInterfaceExt - small extension of javax.slee.ActivityContextInterface, allowing the retrieval of the timers and names bound to the ACI
- Library References - extension of the Library Jar XML Descriptor, allowing the reference of other component types such as SBBs or RA Types
Read and discuss all about those extensions by clicking here. Any feedback and contribution is welcome.
Hi Eduardo,
ReplyDeleteI think that Library components should not access SBBs. So far, a known issue, common resources based on RA API had to be enclosed within SBB components. That would be nice and reasonable to provide it through a Library. From the SBB point of view it's not RA that is accessed but some resources - no conflict.
But still allowing an SBBs to reference Libraries and then again those Libraries to reference other SBBs IMHO would break the clarity of the SLEE logic composition. A horizontally focused (implicit layers) concept keeps things modular with no cyclic dependencies. RAs and Libraries and above them SBBs.
Cheers,
- Tomasz Zieleniewski
I see the Library as a facility, touching both RA and SBB layer, since both use them. Note that cyclic references are always possible and even accepted in SLEE, as long as the components are in same DU. Not sure about this one, as long as something is not ugly or incorrect I like to leave the path open for all kinds of usage, this sometimes is what makes an API take another direction - good or bad... We need more thoughts and opinions :)
ReplyDelete