New stuff

Last week was a bit of hell week. We had two releases going on, one for SS7 project second for SLEE container. So lets see what we managed to push to community.


SS7 includes few fixes, but most important improvements are hidden in SCCP and M3UA/MTP. This release brings two things:
 - support for M3UA, now you can integrate our stacks with Dialogic M3UA.
 - SCCP routing and service. SCCP layers supports now basic routing. Additionally it has been changed to service, in which for instance JSLEE RAs, can register to receive MU which are targeted for specific address.
Release already happened, shortly there will be new bundle available on sourceforge.net.

JSLEE release brings tons of goodies. Detailed info can be found here, in short:

- Cluster performance optimization, 8x compared with 2.1.2.FINAL
- Support for "Buddy Groups" clusters
- Tracers performance optimization
- Enhanced RA's SleeEndpoint with custom operations to help/optimize
work in cluster mode
- EJB support for SBBs, as defined by JAIN SLEE 1.1 standard
- CMP Field Accessor Methods performance optimization
- SbbContext/ProfileContext JAIN SLEE 1.1 Extension
- ActivityContextInterface JAIN SLEE 1.1 Extension
- Library XML Descriptor References JAIN SLEE 1.1 Extension

Additionally this release comes with Twiddle CLI and refactored Eclipse plugin (EclipseSLEE).

Trip after trip, training gig.

Its been a while since Ive had some time to blog, high time to catch up.


Sometime ago(end of August I believe) me and Amit had pleasure to perform training in South Affrica.
Training took place in(or near) Johanesburg at CSIR institute. 


CSIR stands for Council for Scientific and Industrial Research. Its located in Pretoria, Johanesburg. The CSIRis South Africa's central and premier scientific research and development organisation in Africa. Constituted by an Act of Parliament in 1945 as a science council, the CSIR undertakes directed and multidisciplinary research, technological innovation as well as industrial and scientific development to improve the quality of life of the country’s people. In short, CSIR hosts researches and create technologies which are implemented by SA government.




We had accommodation  provided by Meraka. During whole training we stayed in one of houses at Merakas campus. Campus is a huge playground, not only it looks great but it provides also a lot of places to socialize, like:

• football field
• tenis/squash courts 
• gym
• etc....

Usually core developers do not provide training. However this case was a bit different. Whole training was customized, to address needs of Meraka team. 

Training gave me and Amit rare opportunity to interact with users. Whole gig gave us quite good picture of problems and design traps users fall into. Most of them come simply from missing concepts behind specification. This is something we can address in blog posts and documentation. And we will.

CSIR developers are quite experienced. They've been playing with JSLEE container for quite some time now. They already have few Resource Adaptors and services developed on top of JSLEE container. Some of them quite interesting, for instance MOBI4D.

CSIR. Meraka Team, me and Amit.

Mobicents does it again!

Incredible. Once again we managed to make release, or two. Details below:

• Protocol Suite  - 1.0.0.B2.
• Media Server - 2.0.0.CR3.

Mobicents media server is last CR before FINAL( previously called GA).

Ive mentioned that incubator went live on mobicents.org. Some work has been done there as well, during last few days. roadmaps are alive and beeing updated as in other projects. Also some new projects surfaced there(HA, SIP LoadBalancer, ....). 

What is still on "TODO" for incubator? Documentation. It should be linked soon. Stay tuned.

Incubator goes live! Baby projects are official.

Again its been a while. Shortly traffic will pick up and some tutorial will see the light here. But before that, small update on mobicents.org. Incubator goes live. First Mobicents baby projects hit the light!

http://www.mobicents.org/incubator.html

• stream library - proprietary stream library
• asn.1 library - library which enables user to encode/decode ASN.1.
• set of SS7 stacks.
• USSD Gateway

Some more will get promotion to incubator, time will show.

Fresh releases from Mobicents Kitchen

Last week or two were quite fruitful for mobicents team. What came out from under our hood?
Well:

• Jain MGCP Stack RC7 - last RC, more info can be found here.
• Diameter 1.2.0 GA - JSLEE 2.x resources, more info can be found here.
• MMS 2.0.0.RC1, first Release Candidate from 2.x trunk of MMS, more info can be found here.

More will come.

Maven Archetypes update

Some changes in maven tools in mobicents platofrm:

• fix metadata
• add jslee 1.1 service archetype

So now all desired archetypes are there.

Maven archetypes can be found here.

Also there is good article how to use archetypes to quick start projects, it can be found here.

How to use archetype from CLI? Please follow:

1. checkout
2. install with mvn install
3. use following command(for service):  mvn archetype:generate -DarchetypeGroupId=org.mobicents.tools.maven.archetype.slee -DarchetypeArtifactId=jain-slee-11-service -DgroupdId=xxx.y -DartifactId=TestSLee11Archetype_service -DarchetypeVersion=1.0.0.BETA2-SNAPSHOT , where:

• archetypeGroupId - archetype group
• archetypeArtifactId - id of archetype
• archetypeVersion - archetype version, once it is released, it should not be required
• groupdId - new groupd id of created project
• artifactId - new artifact id of created project, also directory name

JSLEE 1.1 service composition vs class loading

My last post about JSLEE 1.1 describes theory of classloading in v1.1 containers. However, how does it look in practice?

Well, I must say it looks and works much better than earlier model. But.. yes, there is one small "but", due to inheritance restriction it may sometime prove to be problematic, atleast for certain cases. 

Case 1: General Class Loading scheme

To make problem a bit closer, lets consider two services, each service is composed from the same sbbs:

 - Sbb[1]

 - Sbb[2]

 - Sbb[3]

Each sbb references the same RA Types and Profiles

 - RAType[1]

 - Profile[1]

 - Profile[2]

To make this a bit more complicated - each service is independent. That is each can be deployed separetly and provide service.

Now lets imagine two things:

• SBBs extends super class which provides common fields(RA Type SBB Interface) methods to manipulate profile, etc
• There is shared Utility class which manipulate RA Type message factories to create specific messages, manipulate profiles, etc.

Now there is no problem in 1.0 container as classloading was flat. Everything works fine, one or many sbb jars/DUs - it still works.

However when one wants to deploy this set of services in 1.1 container, problem shows. In 1.1 container (as it is a bit more organized) we would like to have everything separated:

• library(Library[1]) with: super class of SBBs, Utility classes and similar
• sbb-jar.xml, sbb-jar file for each sbb
• DU for each somponent - services,library,profile and RA

Since library contains classes each sbb use, each sbb-jar.xml declares dependency on library.

From first glance it looks like this deployment should work from kick. Well, it wont...

Lets consider Utility class, it operates(depends) on:

 - RA Type events

 - RA Type classes

Sbb super class is very similar in this matter. Both classes are contained in our Library[1].

What is wrong? Library[1] does not have any way of referencing RAType classes. That means that Utility class (as well as Sbb super class) has no access to definition of those classes. This will cause failure during runtime or sbb verification.

Conclusion: using single jar file for sbbs allows to make this problem dormant. However there seem to be more favored way for 1.1 container. That is:

• each functional component declares library with classes it uses
• functional component declares dependency on its library in its xml file
• any other component may ow declare dependency on library to use certain classes

For this example it would mean following:

 RA Type[1] Library[1] is declared. LIbrary[1] declares dependency on  RA Type[1] Library[1].

Case 2: Event sharing

This problem happens only on shared deployment. That is JSLEE and non JSLEE aplication is deployed in the same container.

Lets consider simple web application which fires event "X" into SLEE. Event "X" is received and processed by SLEE service.

This makes it clear that X.class should be present in two places:

• SLEE - since there is service depending on it.
• web application archive, since it fires it.

Since JSLEE v1.1 container no longer shares its classes outside container, it is logical to assume that jar containing X.class should be in both: JSLEE and web archive.

Well, logic fails here. It wont work. It will cause well known exception:

ClassCastException: Can't cast X to X

To make this work following steps should be followed:

- jar containing X.class should be in container library directory

- events.jar deployed within SLEE should contain only xml file with even definitions

Thats it.