Skip to main content

Autodeploy and naming conventions about entity links etc.

3 replies [Last post]
mranga
Offline
Joined: 2003-06-06

Hello all!

Note that the autodeployer was assuming some hard coded naming convention about ResourceAdaptorEntity name. There is no such default name in the slee spec and such assumptions make it brittle and subject to failure. That was at least part of the problem we uncovered today. We changed the entity link name and could not deploy the SIP resource adaptor. It took a lot of searching and precious time to discover the root cause of the problem.

The steps for installing the resource adaptor are

1. Create the Entity

2. Activate it

3. Give it an entity link name.

This is how the application ( sip proxy in this case ) binds to the RA.

I think it would be a good thing to move in the direction of the 1.1 Spec for the ResourceManagement Mbean. Autodeploy seems to have some dependency issues that I had not previously thought of. I can see several hairy problems being introduced without some explicit way of defining dependencies. Moving in the direction of the ResourceManagementMBean from the 1.1 spec may be a better use of reseources.

All: Please do an end to end test of the specific component you are working on before commit. I am going to use the sip tester from cafesip.org ( which works on jain-sip) to do a simple proxy auto test. These hiccups take a long time to fix.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ivelin
Offline
Joined: 2003-07-13

You are correctly describing the auto-deploy behaviour in regard to entity-link names, but how would you expect it to work?

In the case of the deployment via ant, the entity link name is provided by the script. What is a good way to choose an entity link name for auto-deploy?

Also, what are the hairy dependency issues that you have in mind?

I am not familiar with the SLEE 1.1 mechanism, but will study it.

Ivelin

mranga
Offline
Joined: 2003-06-06

> You are correctly describing the auto-deploy
> behaviour in regard to entity-link names, but how
> would you expect it to work?
>

It should work the way the ant script does. That is it should be possible to specify the entitylink name in the deployment and use the specified one.

> In the case of the deployment via ant, the entity
> link name is provided by the script. What is a good
> way to choose an entity link name for auto-deploy?

Imbed ant in mobicents and read an ant script to do the deploy. Let the mobicents deployer scan for changes in the ant script. This way dependencies can be explictly stated.

>
> Also, what are the hairy dependency issues that you
> have in mind?

When you deploy something, you may have dependencies on other jars that need to be deployed before it. For example, you have the RA types.jar to be deployed first, the RA jar to be deployed next and finally the proxy. If things are not done in this order the proxy will not deploy. If I understand it correctly what you are suggesting is that alphabetical ordering be used to deploy the jars in the right order. Thats fragile IMO.

When you change the proxy jar only the proxy jar must be redeployed and not the other two. So how do you propose to deal with bundling? Say somebody installs a proxy that depends upon the SIP RA and another person installs an IM server that also depends upon the SIP RA. You have to make sure that the SIP RA is only deployed once. Which one will you pick? A lot of interactions remain to be clearly spelled out. They are not complicated but they need to be thought through.

Also it should be possible to install multiple SIP RA's (note that you can be on a mult-homed host).

>
> I am not familiar with the SLEE 1.1 mechanism, but
> will study it.
>
> Ivelin

ivelin
Offline
Joined: 2003-07-13

Ranga and I had an offline discussion about the requirements for the auto deployment service. I am working on enhancements that will automatically create RA entity links on demand and will also track dependencies between components so that the service does not depend on jar file naming conventions.

Started doing some legwork. When I have a better grasp of the problem, I will post design notes.

For the time being, continue to use the ant scripts - sipradeploy and proxy-service-deploy, which Ranga enhanced to eliminate the need for shell scripts.

Ivelin