Implementing s6a diameter endpoint using RestComm Jdiameter - lte

I am pretty new to Diameter and I need a test application to imitate HSS behavior and send some diameter requests to the MME on s6a interface.
I have checked out seagull tool but it has some problems as seagull assumes that the client always initiates the request. But in my case, there is a constraint that the MME always initiates the CER request.
I was checking for alternatives and I came across RestComm JDiameter but I have no clue on how to use it. The github repo doesnt provide any information on using it and I couldnt find out any information by googling either.
So kindly guide me on how to use Jdiameter for my application.

JDiameter as a very powerful framework, although quite complex to understand. You especially need to really read carefully through the diameter specs and how the messages and their value types are.
CER and CEA are diameter standard and will work out-of-the-box for JDiameter. So what you basically need to do is:
Setup your project and decide on a server to use for it. I chose
wildfly, but had to give it access to some elsewise protected
internal java classes (only required for SCTP). Secondly I doubt, that the JDiameter internal thread handling really matches the JEE standard, but at least it works.
include JDiameter as library. In maven terms, this looks like this:
<dependency>
<groupId>org.mobicents.diameter</groupId>
<artifactId>jdiameter-api</artifactId>
<version>1.7.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.mobicents.diameter</groupId>
<artifactId>jdiameter-impl</artifactId>
<version>1.7.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>org.mobicents.protocols.sctp</groupId>
<artifactId>sctp-impl</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.mobicents.diameter</groupId>
<artifactId>mobicents-diameter-mux-jar</artifactId>
<version>1.7.0-SNAPSHOT</version>
<type>jar</type>
</dependency>
Create a working jdiameter-something.xml file for the configuration. You can place it within the resources directory or external of your application, but it needs to be accessible.
If your application will run in an application server and not standalone, create a java class that will be instantiated at startup and initialize the JDiameter stack there. Initializing consists of reading the xml configuration using e.g.
stack = new StackImpl();
Configuration serverConfig = new org.jdiameter.server.impl.helpers.XMLConfiguration(serverConfigInputStream);
factory = stack.init(serverConfig);
After that, register the NetWorkReqListeners for your custom messages as well as:
stack.start();
ISessionFactory isf = (ISessionFactory) factory;
isf.registerAppFacory(ServerS6aSession.class, new S6aSessionFactory(1000, factory));

Related

Adding transaction support to embedded jetty/GWT RemoteServiceServlet without Spring?

GWT's servlet implementation has onBefore/onAfterDeserialization which would give me a hook with which to start and stop transactions without doing anything fancy, however those methods don't allow me to properly check for error conditions after the service method got invoked, I just have access to the serialized return value, not directly to any exception that might have been thrown, so deciding whether to roll back or not is not possible that way without rewriting parts the GWT servlet.
I was thinking about using aspectj's compile-time weaving. However, this does not work with Netbeans' compile-on-save feature because the module needs to be recompiled using the aspectj compiler.
How about LTW (load-time-weaving)? Is there any way (or example) to add LTW to the webapp container without using the Spring framework?
I was also thinking about using AOP based on Java dynamic proxies, ie. to put a proxy in front of the servlet. Again, the question arises how to tell the Jetty WebApp container to load the proxy instead of the original servlet.
Or is there any ready-to-use solution out there already?
I think you could overwrite a combination of
public String processCall(RPCRequest rpcRequest) from RemoteServiceServlet and RPC.invokeAndEncodeResponse to do what you want.
Not ideal, as you need to copy/paste a few lines of code, but they really are only a few.
I myself hit the same problems as I needed some customizations, and relevant methods didn't had the access modifier that I needed, so I ended up copy/pasting some portions.
I can't comment on the rest of your question, but I don't expect to find any ready-to-use solutions, as GWT-RPC doesn't seem to have any new fans out there; just people maintaining legacy systems. Therefore, I expect that you either don't find anything or find solutions that are no longer maintained.

Using tapestry-jpa just with tapestry-ioc in non-web project

this is a very basic question, and I'm kind of sorry, but I don't seem to be able to get a simple Tapestry-IOC based application to work with the built-in Tapestry JPA module.
The application is not necessarily meant as a web project so the dependencies are just tapestry-ioc and tapestry-jpa for the JPA integration. I used the hibernate-entitymanager before and everything worked fine. But I thought I might rather use the official JPA support of Tapestry.
So what I did was to get the above mentioned dependencies (in Tapestry version 5.3.7) and to write the beginning of a test.
This beginning looks like this
Registry registry = RegistryBuilder.buildAndStartupRegistry(MyModule.class);
EntityManager em = registry.getService(EntityManager.class);
That's all. Because as soon as I try this I get the error that no service would implement the EntityManager interface.
So I added the Tapestry JPA module:
Registry registry = RegistryBuilder.buildAndStartupRegistry(MyModule.class, JpaModule.class);
But then again I get an error that the JpaModule wants to contribute to the ApplicationStatePersistenceStrategySource service which is not present. This service seems to be defined in the TapestryModule so I did
Registry registry = RegistryBuilder.buildAndStartupRegistry(MyModule.class, JpaModule.class, TapestryModule.class);
But this causes an error due to the missing servlet API. So now I get to the point where I would have to define the web environment for Tapestry. But I don't want this, I just wanted to use the JPA integration.
Is this even possible? And if so, how do I do it? Following the documentation at http://tapestry.apache.org/integrating-with-jpa.html does not help in this regard.
Thank you very much for reading, any hint appreciated!
Quick answer -- I could be wrong -- but I thought Tapestry-jpa was intended for using JPA with Tapestry-core (the web framework). I don't think there would be any benefit over plain JPA in your case.

apache-cxf dosgi restful service as eclipse plug-in weirdness

I'm in the process of exposing some of the data generated in one OSGi bundle with a REST interface so it can be consumed with typical http requests afterwards by anyone. To do this I'm using a combination of apache-cxf, JAX-RS and Jetty (for testing purposes mostly).
My whole application is distributed in two ways:
Core: Runs a set of minimal bundles as an OSGi framework.
Full: Core + plus a set of plugins to be used within Eclipse, in a graphical way, to put it that way.
While in the Core launch configuration I can make this work without any problems, have a look at the MANIFEST:
Require-Bundle: cxf-dosgi-ri-singlebundle-distribution;bundle-version="1.3.1",org.eclipse.core.runtime, org.eclipse.osgi.services;bundle-version="3.3.0", org.mortbay.jetty.server;bundle-version="6.1.23", org.mortbay.jetty.util;bundle-version="6.1.23"
When I try to launch the Full distribution, jetty server does not seem to start and thus, the RESTful service is not working properly. Full distribution comes with a lot more plugins, mostly related with wizards, perspectives and so on. Root of this problem is somehow related with the cxf-dosgi-ri-singlebundle-distribution bundle, and can be tackled by "forcing" auto-start of this bundle to true, instead of default (check image below):
While this is OK, my question is ...why is this happening? And second and most important, I distribute the Full distribution via an update site, so users can download it, open perspective and start using it, that said, will this affect the final distribution? Is there a way I can control this auto-start=true for the apache-cxf bundle in the update site?
Hope I can make myself clear...
Thanks!
I don't like answering my own questions, but since I'm getting no feedback and maybe someone else has the same problem...here it goes
I decided to change the whole design of my restful bundle, by not using apache-cxf, since it is really not needed. All I need to do what I want is the embedded Jetty server and javax for dealing with HttpRequests and HttpResponses. Thus, I get rid of dependecies with third party libraries, leveraging the launching problems at the same time.
Got the ideas from these official sites in Eclipe:
Embedding an HTTP server in Equinox
Writing a bundle-based server application
Besides, a more hands-on tutorials can be also found here:
OSGi as a Web Server application
Extending Eclipse: displaying HTML content from a bundled archive
Special thanks to both authors for the enlightenment :).

GwtTestCase and Spring

So I managed to create a GWT-SpringMVC setup. Wasn't easy (not too many resources), but possible. I even autowired and stuff. It even works :)
However, I can't figure out how to make the GwtTestCase run. Obviously it needs the "server" to be up, and because I use Spring, it needs to pass through the dispatching servlet (no?). But I can't figure out how to connect the two. In production or hosted mode, I got the web.xml and the spring-servlet.xml to configure these things. What can I do for tests?
I thought of ignoring the web part and testing the service directly - but this will deny me the option to automatically tests that everything is "transferable".
(if you have an idea on how to do that, I might ditch the GWTTestCase altogether).
An alternative to GWTTestCase could be the gwt-test-utils framework, which provides a simple integration with Spring (see here for details)

Can the server create and return GWT objects to the client?

Still wresting with GWT and App Engine, and I have come to this problem:
I have an app engine populated with various data, which I would like to present on the client using a GWT RPC.
I have found out the hard way that, because my Model objects are annotated with JDO, i can't just send them back to the client because they aren't serializable. This means I'm going to have to create a layer of intermediate classes to extract data from my model objects, and send it back to the client to use asynchronously.
I am wondering though, it is possible to construct a GWT object in a servlet and send it back to be used? For example, the servlet would be receive my asynchronous request, pull out the data i want from the database, create a GWT VerticalPanel() with appropriate child elements for the data, and send that VerticalPanel back to the client to be injected.
My understanding of the Java / Javascript interaction that is going on here is still foggy, and I'm thinking that sending a Java object that is not compiled to Javascript after the application is deplyed will not work. Can anybody clarify this for me?
No the server can't create GWT UI objects (like vertical panels) to be used in the presentation layer, nor should it, that's why it's called a 'server' and a 'presentation layer' one serves the data and handles all the business logic, the other displays things on a screen and allows a user to interact with them.
You can however send your JPA annotated POJO's to the front end just fine (we do it in all our applications). You simply need to include the source code for the annotations themselves so that GWT knows how to compile them. You also need to make sure your POJOs's are in a package that is referenced by a NameOfXmlFile.gwt.xml file, eg:
<module>
<inherits name='com.google.gwt.user.User'/>
<source path="domain" />
</module>
This file in my case is in a folder above a package called 'domain' where all my JPA annotated POJO's live. Then in your client side you tell it to inherit that .gwt.xml file:
<module>
<inherits name='com.google.gwt.user.User'/>
<!-- Domain layer references -->
<inherits name='your.package.structure.NameOfXmlFile'/>
</module>
There are restrictions on what you can put in those classes (like for example BigDecimal is not supported, etc) but anything that can be compiled by the GWT compiler (and JPA annotations certainly can be) can be sent without needing any kind of transfer objects. This is one of the real strengths of GWT, that you can use the same JPA Pojos in your entire application, without ever needing to create any other similar object.
Edit: I just noticed you said JDO and not JPA. I assume the same applies there as well though if they are just annotations?
I've seen good answers, so I won't repeat them myself..
Anyway my simple but vital suggestion is: the only way to go is through POJO objects.. BUT IMHO to avoid problems, remember that your POJO objects SHOULD be really PLAIN
Anyway, I can suggest you also a little framework I recently did (few hours of work, so don't expect a rocket!).
It is pojo-injector: http://code.google.com/p/pojo-injector
It helps you in translating your data models to POJO and back... It's based on annotations (only on the POJO side!).
I hope it can help.
This is (imho) one of the problems with GWT.
Basically in Java Web applications it's pretty common to have data or domain objects (which would be your JDO objects) and presentation objects, which are sent to the view. Some go much further than this and can have many more layers of abstraction ("go ahead, add one more layer").
I can see the argument for this but it adds a lot of boilerplate as you translate objects between layers.
Anyway, in GWT you need to do this if your domain objects are POJOs (and as with JPA, even though they claim to be POJOs, the annotations make them not so in reality).
GWT will do this for you on objects returned by your RPC interface but there are certain classes you can't use (eg BigDecimal) as there is no Javascript equivalent (so to use BigDecimals you pass Strings around to construct BigDecimals yourself on the serverside when you ened them and convert them back to Strings when you send them to the client).