I have recently moved to telecom and working on automation framework to automate the VoIP phone.
In current framework, for a simple call/conference scenario, additional helper phones are being used. The current framework configure these additional physical helper phones which takes considerable time and consumption of resources.
I am trying to replace these physical helper phones with the programmable soft phones, so that the test execution will be little bit fast.
Please let us know if this can be possible.
I am not looking for GUI-based soft SIP client because automating the UI actions will be another challenge and prone to error.
This framework is being developed in Perl
Your help will be highly appreciated!!
Take a look at SIPp. http://sipp.sourceforge.net/
I think it will do what you want, it even has some handling of RTP data.
If perl is not a strict requirement, the KitCAT framework is extremely (Java) developer-friendly. Test cases are written in JUnit, for ease of integration with other tools. It provides logs at varying levels (including SIP messages), and supports multiple user agents, which can all be coordinated within a test case. (The latter is not well supported in other SIP testing tools, such as sipp). It also provides coordination with other protocols (e.g., RTP, HTTP).
There is a (somewhat dated) screencast that shows installation and basic usage of the tool.
Related
I am currently doing my research on building a chat system with more than 10k users connected online. I came across technologies and ways to do it such as jabber(XMPP), websockets, long polling, push. As far as I now, long polling might not work given the number of users. I know there is a lot of ways to accomplish this. I also know that facebook and Google chat systems are developed on XMPP.
I would truly appreciate if anyone could point me to the right direction. I believe all these methods and technologies out there are good depending on the scale of the project. I definitely need performance and scalability.
I've used Socket.io together with NodeJS for such a chat application. It scaled to over 10K concurrent users on moderate servers and there was a lot of room to grow.
This does depend on your limitations, tho.
What kind of hardware are you planning on using?
Which operating system would power your servers?
Which client platforms are you targeting?
Do you have an existing infrastructure you need to fit this into?
Do you have a previously selected programming language?
The existing skill sets your team members have and your team's ability to adopt new platforms and languages if necessary.
Take all of the above into consideration when making your decision.
Personally, I've found XMPP to be quite adequate, but a bit bloated for my purposes. YMMV.
You are comparing a fruit basket and three different variety of oranges.
XMPP is the only protocol that you have mentioned that actually is designed to support a chat system (of which many exist). The others are simply asynchronous messaging protocols/techniques. XMPP already supports http based chat via BOSH. Without a doubt, it will also support WebSockets when the specification is finalized. There is actually a draft of this already written, but at this point it appears to be a draft using a draft, so there will probably be few, if any, implementations.
Using XMPP would allow you to build on a proven technology for implementing a chat system and would allow you to choose what transport you want to use "under the hood". You haven't actually said whether you need a http based transport or not, but with XMPP you can use the stock tcp socket based transport or a http based one (BOSH) with the knowledge that it will also support WebSockets in the future.
The other benefit is of course that this is a widely used standard that will allow reuse of existing clients, servers and libraries in pretty much all popular (and not so popular) languages and platforms.
Scalability is not too much of a concern with the numbers you are quoting, as most (maybe all) existing xmpp servers will handle that many users.
I am wondering if it would be possible to develop an enterprise-level web application without the use of a standard MVC structure and application server by carrying the business/flow logic and session data to the client-size Javascript and make it talk to REST data services directly...maybe we could make use of an authorization/authentication layer and a second validation layer sitting on top of the data services. All these services operate on standard HTTP methods, support configurable logging&monitoring, and content or query parameters are all contained in the HTTP request/response body. Static HTML and Javascript are served to the browser and the rest is carried out by Javascript functions talking to the HTTP-based authorization/authentication, validation and then data services. Do you think this kind of an architecture could satisfy enterprise-level web application requirements?
It's possible but unlikely; what are the drivers that suggest this architecture to you? Is it just to be different or are there some specific aspects that this best addresses?
by carrying the business/flow logic
and session data to the client-side
Javascript and make it talk to REST
data services directly
In theory you'd still be able to have an appropriately layered solution (Business Logic (BL) script vs UI focused script) but practically speaking it'd be messy, and you'd lose the ability to physically separate it into different tiers. This could "bite" you at any number of places in the life of the system.
"Enterprise" grade systems are seldom small, I hate to think how much logic you'd be having to send over the wire to support a given action/process.
Putting all the BL into a scripting language ties you to that platform, and platforms change over time. The bad thing about scripts is that whilst they are stable to a degree I'd suggest they are more exposed to change than server-based platforms like Java or .Net. In an enterprise scenario, the servers will have very tight change control and upgrade paths mapped out for them - whereas browsers are much more open to regular change.
There's the issue of compatibility - unless you're tied to a specific browser (to the version level) guaranteeing consistent behavior is going to be harder, and will likely require more development effort. Let's say you deliver the solution successfully; what do you do when the business wants to take advantage of mobile computing - say iPads? Your only option is going to be a browser - you won't be able to take advantage of any of the native advantages of the platform. "The web and browsers" might seem like they'll be around forever - but then I'm guessing that what MainFrame folks said at the time. A server-centered solution is going to give you more life for less expense.
Staffing will be an issue - you'll need very strong JavaScript and server-side developers.
Security: having your core BL out on the client where it's much more exposed sounds very dangerous.
EDIT:
Web Apps can be sow for many reasons - not many of which are reason enough to put all your BL in JavaScript on the client. Building apps for performance is a whole field of endeavor on its own - I suggest you get more familiar with Architecting and implementing for performance before you write off n-tier web apps altogether :)
Regarding keeping your layers separated: there are different ways of doing this but it boils down to abstraction - and more correctly to keeping good design principles in mind; if you haven't heard of SOLID that would be a good place to start. In terms of implementation start reading up on Dependency Inversion (FYI - self-promotion, the articles mine and is .Net focused, but you should have no problem tracking down Java-based ones too).
I've recently decided to take on a pretty big software engineering project that will involve developing a client-server based application. My plan is to develop as many clients as possible: including native iPhone, Android and Blackberry Apps as well as a web-based app.
For my server I'm planning on using a VPS (possibly from slicehost.com) running a flavor of Linux with a MySQL database. My first question is what should be my strategy for clients to interface with the server. My ideas are:
HTTP-POST or GET based communication with a PHP script.
This is something I'm very familiar with - passing information to a PHP script from a form, working with it and returning output. I'm assuming I'd want to return output to clients as some sort of XML or JSON based string. I'm also assuming I'd want to create a well defined API for clients that want to interface with my server.
Socket based communication with either a PHP script, Java program, or C++ program
This I'm less familiar with. I've worked with basic tutorials on creating a script or simple application that creates a socket, listens for a connection and returns data. I'm assuming there is far less communication data-overhead with this method than an HTTP based method. My dream is for there to be A LOT of concurrent clients in use, all working with the server/database. I'm not sure if a simple HTTP/PHP script based communication design can scale effectively to meet the needs of many clients. Also, I may eventually want the capability of a Server-Push to clients triggered by various server events. I'm also unsure of what programming language is best suited for this. If efficiency is a big concern I'd imagine a PHP script might not be efficient enough?
Is there a commonly accepted way of doing this? For me this is an attempt to bridge a gap between some of my current skills. I have a lot of experience with PHP and interfacing with a MySQl database to serve dynamic web pages. I also have a lot of experience developing native iPhone applications (however none that have had any significant server-based communication). Also I've worked with Java/C++, and I've developed applications in both languages that have interfaced with MySQL.
I don't anticipate my clients sending/receiving a tremendous amount of data to/from a server. Something on par with a set of strings per a given client-side event.
Another question: Using a VPS - good idea? I obviously don't want to pay for a full-dedicated server (slicehost offers a VPS starting at ~ $20/month), and I'm assuming a VPS will be capable of meeting the requirements of a few initial clients. As more and more users begin to interface with my server, I'm assuming it will be possible to migrate to larger and larger 'slices' and possibly eventually moving to a full-dedicated server if necessary.
Thanks for the advice! :)
I'd say go with the simplicity of HTTP, at least until your needs outgrow its capabilities. (The more stateful your application needs to be, the less HTTP fits).
For low cost and scalability, you probably can't go wrong with a cloud like Rackspace's or Amazon's. But I'm just getting started with those, my servers have been VPSs from tektonic until now.
Is there a distributed application framework (commercial is okay as well) that supports iPhone / iPad ?
What I'm looking for in the framework:
Allows me to focus on the application logic
I don't have to code "low-level" network programming (I've done it too many times that I dont wanna do it again =p)
Should be actively maintained (popular would be nice)
Basically, I can then develop faster.
We plan to develop a soft real-time TCP/IP client/server application where there are many iPhone/iPad clients (30+) connected to single server over LAN. The server most likely will run Windows (unless the framework does not support it).
I've been looking around and I see:
MonoTouch WCF (still looks quite raw ?)
RemObjects (Mono + Objective-C)
Cocoa Distributed Objects
ZeroC Ice Touch (Objective-C)
RakNet ( ? included because it mentions iPhone, but will need to use C++)
Of course, there's also the option of using the plain old MonoTouch System.Net.Sockets
Or, CFNetwork (I dont plan to use this one)
I'm still deciding whether to use Objective-C or MonoTouch, but leaning towards MonoTouch since we will get the .NET framework, and not be tied into just the Mac world.
Please feel free to comment if I added anything that's not related to my question---I'm new to iPhone/iPad world.
We've used WCF/Monotouch with great success - there are some areas of the f/work that arent 100% but for most cases you should find working with WCF on monotouch a breeze.
The ability to share all of our data sync, model, tests etc between monodroid and monotouch and wm7 is seriously cool (with some working - this is easilly possible - you'll need to manage multiple prj files).
Be careful to manage calls to wcf services correctly, keep them to a minimum, keep the archetecture simple. We ended up with a fairly complex dto to minimise the amount of calls to the wcf services to sync the data - this was well worth it as the time needed to sync a device from scratch is now a fraction of what it was.
Using SSL to communicate with the server is a PITA but I think that's more a case of the way apple have managed it.
You need to be a bit more explicit on your requirements. If you need only object serialization (dehydration/hydration) over REST API, then anything that supports POX or JSON will work just fine for you. However, if you need RPC-style method invocation, with authentication, encryption/digital signature, transactions, etc, then you need one of those frameworks you listed above.
If you need a framework, I personally would lean towards the MonoTouch WCF, as it gives you the ability to move your client to other platforms later as well (Windows Phone 7 for example). Then again, as you said, it's a bit rough right now, and if Mono team decides in the future that they don't have the resources to invest in maintaining it, you might end up with having to move to another framework. Of course, there's also the drawback that you need to use MonoTouch for your application, and can't use Objective-C. Granted, with the recent changes in the iOS Developer Agreement, that's not that much of an issue, but it is still something to keep in mind.
(Disclaimer: I used to work on Microsoft's WCF team, so I am biased towards the product itself)
The other option I would go for, would be Cocoa Distributed Objects. However, that would be my choice if the server is also running on OS X. I know there's Bonjour for Windows, but I doubt it's optimized for server scenarios, and I also don't know how rich is Apple's RPC implementation on top of it for the Windows platform. So I would stay with Apple's technology only if I am building exclusively for Apple's platform.
Note that WCF and Distributed Objects would give you RPC-style functionality, but they won't help you with any particular scenarios. If you need/want even higher level of abstraction, for example you need presence information or multi-user chat, you will still need to implement those yourself. It might be worth at this point to look at frameworks that provide those features for you. An example would be RakNet (which you listed above), which abstracts the remoting level and builds additional features on top of it.
You can use JSON Touch + Vitche PHP Emission Framework which provides all server-side you need. Also you can use that Framework to access existing SOAP (WCF, Axis, etc) services.
You can use Google protocol buffers to implement RPC though you will need to do some network programming for transporting your messages anyway. It supports interface generation for C++, Java, Python and Objective-C and .NET so you can create a single set of RPC messages and get code for working with them for almost any mobile platform. Transport layer on your mobile platforms you will have to implement yourself.
http:// code.google.com/apis/protocolbuffers/ - main Protobuf page (C++, Java, Python)
http:// code.google.com/p/protobuf-net/ - Protobuf .NET mentioned in one of the comments
http:// code.google.com/p/metasyntactic/wiki/ProtocolBuffers - Protobuf for Obj-C
I am coding a client-server application using Eclipse's RCP.
We are having trouble testing the interaction between the two sides
as they both contain a lot of GUI and provide no command-line or other
remote API.
Got any ideas?
I have about 1.5 years worth of experience with the RCP framework, I really liked it. We simply JUnit for testing...
It's sort of cliche to say, but if it's not easy to test, maybe the design needs some refactoring?
Java and the RCP framework provide great facilities for keeping GUI code and logic code separate. We used the MVC pattern with the observer, observable constructs that are available in Java...
If you don't know about observer / observable construct that are in Java, I would HIGHLY recommend you take a look at this: http://www.javaworld.com/javaworld/jw-10-1996/jw-10-howto.html, you will use it all the time and your apps will be easier to test.
As a former Test & Commissioning manager, I would strongly argue for a test API. It does not remove the need for User Interface testing, but you will be able to add automated tests and non regression tests.
If it's absolutely impossible, I would setup a test proxy, where you will be able to:
Do nothing (transparent proxy). Your app should behave normally.
Spy / Log data traffic. Add a filter mechanism so you don't grab everything
Block specific messages. Your filter system is very useful here
Corrupt specific messages (this is more difficult)
If you need some sort of network testing:
Limit general throughput (some libraries do this)
Delay messages (same remark)
Change packet order (quite difficult)
Have you considered using a UI functional testing tool? You could check out HP's QuickTest Professional which covers a wide varieties of UI technologies.
we are developing one client-server based application using EJB(J2EE) technology, Eclips and MySQL(Database). pl suggest any open source testing tool for functional testing .
thanks
Hitesh Shah
Separate your client-server communication into a pure logic module (or package). Test this separately - either have a test server, or use mock objects.
Then, have your UI actions invoke the communications layer. Also, have a look at the command design pattern, using it may help you.