Re: [Asterisk-java-users] OT: Asterisk billing development (Thameem Ansari)

[Thameem A. <tha...@ya...>]

HI Peter,

For somereason I didn't get your mail and I came to know about your mail from the response from Brett. I do agree with Brett about using libraries. The reason for using the existing libraries is to avoid so much of coding (reinventing things which exists). 


>>So try to re-evaluate your dependencies. Do you _really_ need hibernate?
>>Can't you implement a simpler serialization mechanism? Do you _really_
>>need sitemesh? Is it not possible to write some simple code that
>>generates some web pages using println statements? What about struts?
>>Isn't it possible to implement web application flow in a simpler way? Or
>>why is quartz really needed? Is it not possible to implement a threaded
>>scheduling mechanism that runs each job in its own thread? I would have
>>thought that such a job could be done with maybe ten classes.
Here is my reason for choosing those libraries. 
Hibernate - I would like to develop an app which is database independent and should perform well in terms of caching etc. Hibernate is the enterprise standard now a days to hide the database dependency. 

Postgres - Even though I choose hibernate I do need some kind of back end database to develop with. Once its developed then the app can be used with any other database including Oracle, Mysql (try to work with this and hopefully Mysql guys will include the missing key features like returning cursors, indexing, etc), postgres, enterprisedb (my favourite). 

Struts 2.x - Simplicity - This is going to be ruling the webapp world in future. As per the design it includes everything for web application development. I was so impressed with the Webwork + struts merge and came up with very good architechture and libraries. Struts 2.0.1 includes Spring framework, hibernate support, Freemarker template, Dojo AJAX support, DWR ajax support, etc. This 2.x architecture uses Dependency Injection and Inversion Of Control and thread local methodologies. So, I strongly believe that to avoid too much of coding we need to use this. 

Sitemesh - To avoid writing layouts, templates and themes for the web application we need this. Prior to struts 2.x Tiles was the layout library used with struts. But struts 2.x have support for Sitemesh which makes the developers life painless by providing few lines of code to have the layout/theme/template. 

Quartz - I do know that using java and their threads directly will solve our issues. But as per my existing experience, the current billing app i have used java 1.5 task schedulers finish my job. But I do see some bottle necks during many calls going on (like > 500 calls). So, as per my past usage experience quartz is getting mature and will perform better than regular threads. (internally it uses these threads only). So, using quartz for scheduling is a good idea. I do have an alternate to avoid threads but I keep quartz in my list incase i need it. 

As Peter mentioned, the build process will not be big pain if we use Maven 2 or legacy ant builders. And moreover the libraries I have listed are all open source and you don't need to hunt for them. 

Thanks,
Thameem





Brett Sutton <bs...@no...> wrote:        I'm not certain I agree with your assertion that using lots of libraries causes the code to be fragile.
 
 My experience with using large numbers of java libraries is that this isn't the case.
 The main reason is that the application doesn't share the libraries with other applications which is the primary cause of the type of fragility that your are talking about (e.g. windows dll hell and linux's problem with shared libraries) 
 
 By using open source libraries you can choose a particular version and stick to it for as long as suits the project.
 AsterFax uses an extensive set of libraries (and we use even more internally) and it very rarely causes us problems.
 
 Regards,
 S. Brett Sutton
 
 Peter Hoppe wrote:    
Dear Thameem!

I somewhat follow the asterisk-java mailing list from afar, but do some
Java programming. Unfortunately I couldn't help with development at the
moment, as I am busy with other projects. However, a little comment:

I think it's a good idea to develop a billing package which provides
many features. However, when I read the long list of libraries you
intend to use for the project I thought "HELP!". I think (and pls
forgive me if I come over the wrong way) that with so many libraries you
may well run into big problems in the future:

* You are likely to create a big dependency mess.  Now that may be fine
for you - but it would create difficulties for other people who may like
to use your software or work on it.

* You not only need the libraries you mentioned, but also those they
depend upon. As result your application may not work unless you have
several tens or more than hundred different jar files installed. It can
make installation a real pain (several hours or days of research on the
internet to find the files and to install them). I have had unpleasant
experiences in the past where I tried one library and needed a few
others. I cannot begin to imagine the kind of problems I would get with
11 big libraries! You may even find that two or more libraries share
depend on different versions of one other library.

* Your product will be very difficult to maintain (fragile). For
example, what if you need a new feature that requires another set of
libraries? How will they work together with the libraries that are
already there? What if someone finds a security hole which needs fixing?
You may find that you may have to upgrade your dependencies for any
future developments. Again, maybe not big trouble for you, but woe
betide the other users of your software...

It's generally a good idea to draw upon ready made libraries, but - in
moderation and where needed. To ascertain this takes a some skill. The
list of libraries gives me the impression that you are developing the
software for a specialized context (like a particular environment you
are working with). But that may be very different from the context used
by other people. As result you may find that not many people can use
your software because it is near impossible to maintain for them. At the
end nobody uses the software because it's too complicated. And that
would be a great pity.

In other words, use less code. With 'less code' I mean: Less of the
amount of code needed overall, i.e. your own code plus the code of all
the dependencies. So, it's not just 'My 200 lines of code', but 'my 200
lines of code plus the 2000000 lines of code that my code depends on =>
2000200 lines'. In light of that isn't it better to arrive at 'my 2000
lines of code plus the 5000 lines of dependency code (= 7000 lines)'?
You will find that less dependencies will make your code much more
portable, maintainable -> usable.

So try to re-evaluate your dependencies. Do you _really_ need hibernate?
Can't you implement a simpler serialization mechanism? Do you _really_
need sitemesh? Is it not possible to write some simple code that
generates some web pages using println statements? What about struts?
Isn't it possible to implement web application flow in a simpler way? Or
why is quartz really needed? Is it not possible to implement a threaded
scheduling mechanism that runs each job in its own thread? I would have
thought that such a job could be done with maybe ten classes.

Pls dont get me wrong - I don't say: Don't use hibernate, quartz, struts
etc. - all I mean is: Evaluate carefully which extra library you
_really_ cannot do without (as it's too time intensive to develop
otherwise) and to implement everything else yourself.

Sorry if I sound too negative, pls forgive me if I did. I think
developing a comprehensive billing application in Java is a great idea.
All I recommend is that you try to be a bit more conservative with your
dependencies. I hope it's ok for me to recommend that to you. You are
likely to get a much more robust software that way!

Thanks for reading my ramblings. Now - get a cup of coffee to wash the
shock away... :) It's all Java, after all!

Peter


  
        
Hello All,

Sorry for sending mail to this list but I find that the people
participating in this list would be appropriate to ask.

I am planning to develop an billing application for asterisk based on
asterisk-java. This would be a full fledged routing, billing and
calling card platform. Many people may ask why the heck i need to
build a new one if there are many open source softwares available.
The reason are many. I evaluated almost all the opensource/commercial
products written in many different languages (non so far in
java)...but they lag of different things...nothing is fully
functionaly or to my expectation..for example,

A2billing .. Not a very good design though..will not handle
simultaneous calls from an account, will not have a good calling card
platform, no callback service, etc.

MORCC -  its a simple and nice calling card app but no way for
provisioning users, prepaid or post paid options

AstBill - need drupal (which i hate it), not a true calling card app
and having problem with simultaneous call billing calculation..

So, here is my request.. I would like to find out is there any more
people available to give me hand on developing that product. I
already have one in production which is working so far good but i
want to rewrite the whole thing again and fix the bottlenecks i
found. Here are the technologies i am planning to use... Struts
2.0.1, tomcat 5.5, asterisk-java, hibernate, postgres 8.x, Jreports
or Jasper Reports, sitemesh, quartz and integration with paypal using
paypal apis, etc... I have a rough design and plan and need people
and inputs...

Please let me know your thoughts...we can start this as sourceforge
project.. Stefan - I need your thoughts on this...

Take care, Thameem
    
      
  ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Asterisk-java-users mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/asterisk-java-users   
  
 -------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Asterisk-java-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/asterisk-java-users