There has been a tremendous amount of research on migrating Java threads between different JVMs on different machines, but is there some publicly available, maintained, de facto implementation that everyone uses? If there is not one good implementation, but multiple ones, which one do you guys recommend and why?
(Note: I'm not talking about database migrations, I'm not asking about Hadoop, RMI, actors, or looking for any other way of doing distributed computing, I need information specifically on thread migration for Java, not Scala [yes I'm aware of the continuations in bleeding edge] or anything else which can sit on the JVM.)
Not sure this is what you are after but...
I know of a couple projects using javaflow to migrate between JVMs. The project needs a few more users to finally see a release though. And contributors that are up to the task are hard to come by. But maybe give it a try. It has a few restrictions/overhead compared to jvm-native migrations.
You might also might want to have a look into this paper about mobile agent migrations.
Related
I'm looking for free open source framework/tool for Java applications and Tomcat cluster monitoring.
The are pretty much tools and frameworks out there (Zabbix, Nagious) but most has GPL license, what makes them impossible for use withing commercial products. Others, has limited charts (JavaMelody) and does not support, or very weak support, for cluster data aggregation.
Recently, I came across MoSKito which looks very promising and has MIT license but I can't really find any reviews on that and not sure how active is that project.
So, would appreciate to get any feedbacks on MoSKito ?
Thanks,
Pavel
well I am a little bit biased, because I am also a commiter in the MoSKito project, but I'll answer nevertheless ;-)
There were like 9 releases (2 major) of the project alone this year, which I think is an indicator that the project is active.
Personally I use it in 3 projects on daily base. The biggest installation I am aware of consists of over 100 JVMs running on 18 machines.
The source code is on github:
https://github.com/anotheria/moskito
https://github.com/anotheria/moskito-control
https://github.com/anotheria/moskito-central
https://github.com/anotheria/moskito-control-agent
If you have any further questions feel free to PM me ;-)
regards
Leon
We have been using MoSKito for more than three years to monitor an onlive platform with about 20 machines and around 100 JVMs running on them, which Leon mentioned above.
Our experience with MoSKito was good. It is very robust. Has a relatively low performance impact, as far as I can tell. Attaching monitoring points can be done quite easily with Annotations. And it does what it shows on the Web-Site and does that well. The developers are always open for suggestions and discussions. The projects is very active.
We did not yet use the relatively new MoSKito central, which can aggregate and store performance data, so I can not say anything about that.
MoSKito does not record all the performance data for each request. It only records averages. On the other hand you can track single requests/sessions by marking them with a request parameter, which can be very handy to analyse performance problems. Doing so shows you a full "stacktrace" of the request with all the performance data and parameters recorded at each MoSKito monitoring point.
I can't compare MoSKito to other tools, since MoSKito is the only tool I used extensively, but I was happy with it.
I am interested in learning how web application are evolving. The idea is that if new technologies or design methodologies should be introduced in java based web application, what would be the top 5-10 technologies worth exploring? Also it would be helpful if someone can point out good books or online resources to conduct this research.
One key aspect is developer productivity. There has been some excellent research and presentations done in this space by Matt Raible (generally, the non-EE space) and Adam Bien for the EE6 space.
The ability of your application to successfully evolve over time has more to do with your software architecture than it has to do with either your technology or methodology. However, your choice of technologies and methodologies will influence how you architect your software.
First off, know what you are up against. In that late 1960s, people started studying what happens to applications over time. Over the last 40 years, those observations have been turned into a set of laws (c.f. Meir Lehman). This stuff might seem obvious, but it is a good starting place:
As a system evolves, its complexity increases unless work is done to maintain or reduce it.
The functionality of a system must be continually increased to maintain user satisfaction over its lifetime. The quality of a system will appear to decline unless it is rigorously maintained and adapted to operational environment changes.
If your in this for the long haul, the biggest questions are probably organizational and not technical. For example, what technologies does the development staff already know and enjoy using? If the developers plan to stick with the company for 5-10 years, ask what it is about the future that excites them. The best places to collect ideas about "hot" Web app technologies is http://www.infoq.com/.
Consider what methodologies are a good fit to both the technical and business culture of your organization. Agile development is great, but it isn't the right fit for every organization or every environment.
Consider vendors. I worked at a site once that was a true-blue IBM shop because IBM made solid software and hardware. However, the client was really locked into the vendor. The client was still using token ring networks and OS/2 in 1997. Give yourself some room to switch tools and technologies when the need arises. A living, breathing application almost never survives a decade of use without switching technology stacks at least once.
To really create a software design that will hold up to changes in the business environment, follow the old adage "build one to throw away". We once built a new system using a new operating system, a new programming paradigm, a switch from green-screen terminal to fat-client GUIs... it was a complete reinvention of the company's information technology. We would have never succeeded if we had not build a prototype and throw it away. We didn't pick all the right technologies and methods the the first time around, when we build the prototype. But we got the chance to correct those mistakes when we built the production system. This only works if you can create a prototype and then throw it away before it is used for real business needs. Once the application goes into production, the window to "throw one away" is gone.
Best of luck!
-Aaron
For all my quick and working web solutions I use Grails. It gives productivity, reasonable performance. It is supported by VMWare, so long term support looks OK.
In a big company I work for, a very (costfull) ESB has been bought, the purpose is to be able to align with business goal quickly by resusing legacy infrastructure wrapping them with webservices, that is to say no more coding needed. Are ESB/BPM now really mature enough for that because it's now more than 10 years old or is it just an other vendor promise ?
Almost certainly just a vendor promise. If this becomes a reality for your company, they'll be the first to be so lucky!
This is the same sales job being done again and again for over a dozen years now (remember 4GLs?).
Most companies find the reality is that 1) it takes far more effort to install, integrate the ESB/BPM tool than they were led to believe, 2) only the most trivial changes can be made with the tool - it still takes coders to perform any meaningful process change / addition, 3) whenever the ESB/BPM tool vendor upgrades their tool, it's a huge effort to upgrade and be eligible for support (look into the history of any of these tools and what pains shops go through to upgrade, particularly Webmethods and BEA/Oracle's products over the years), 4) support services are expensive and rarely provide help (I know of companies that have paid for premium support who have filed dozens of tickets only to have one or two of them resolved by the idiots on the phone before someone in-house finally found the solution / work-around themselves.
You certainly can use an ESB / BPM to wrap legacy infrastructure and facilitate a migration towards a more modern target architecture. In fact that's one of the best reasons to adopt an ESB/SOA strategy in a complex application environment.
However, it's a complete fallacy to say that this implies "no more coding needed". After all, you will need to orchestrate a potentially complex sequence of web services with detailed knowledge of the state and transactional semantics of the legacy systems. Another word for that is.... coding.
p.s. It may be too late for you now but, for the sake of others reading this, I feel obliged to point out that costly prorprietary ESBs are often a waste of money. What you need can be done perfectly well (and sometimes even better!) by the open source solutions. JBoss and Mule spring immediately to mind. Since you are going to need to do most of the hard work in-house anyway, you might as well spend the time learning a great open source toolkit rather than locking yourself in to a vendor's proprietary solution.
I have to develop an ERP System for a 2,000+ end users organisation.
Could you please suggest me with comparable points that among (Java or .Net)
in which technology I should invest money and time? Although I have done
some average projects in both, but this project is going to be very big in near
future in terms of scalability.
I want to know your experiences and some tips from you people, so that I can develop
and deploy this project efficiently.
I rate .Net > Java for this project only due to less development time available.
We have to use some Rapid App Development technology.
I have to deploy this on Cloud (Azure or Google App engine).
It will be better if I got answers from those people who works in both (.Net and Java).
I will appreciate answers from your experiences.
I would suggest creating a very small proof-of-concept project in both technologies, which do something real - like allow people to log in, see messages, and allow them to type in new messages, and log out again.
Even if the project is laughably small, if you do it well, you will have a finished product on each platform which have shown you by experience how things works and if you like the way you had to do them. You will be able to see if you can debug in the cloud, if you can profile when load testing, if you can do fast work inhouse which then works well when deployed to the cloud.
And you will need to figure out things. Are the online resources good? How responsive is the StackOverflow community for each platform when you ask questions?
Personally, I consider the ".NET is Windows-only" to be important. Except for that I do not believe there is any technical showstopper for either platform.
I think both approaches can be used to deliver this successfully. I would expect you to have the same amount of success/pain with either choice. When it comes to making a decision you should base it on the amount of expertise that you have to hand. That is, your own and that of your existing colleagues and the resources that you can acquire (new recruits, contractors, consultants etc.).
That said a couple of technical notes:
The Java approach tends to have more freedom, i.e. more frameworks and choice of technologies for various solutions (although GAE will bring in some restrictions).
There is less choice in the .NET space, but that is not always a bad thing. E.g. you tend not end up in tireless debates about the logging frameworks.
Java is starting to age as a language and C# is a bit nicer, however there a number of newer languages that run on the Java VM (Scala, Groovy, Ruby, Clojure).
Just want to shout out to the community to see what peoples thoughts are on Java process servers in general.
IBM in particular tend to make a lot of noise about Websphere process server. I can see the idea behind the process servers if your working in a web service world but in practice are they really effective or are they just overkill?
BPEL is another closely linked technology that tends to get a lot of hype from IBM but I am yet to see an implementation in real life.
General thoughts welcome.
Some projects/companies do have complex business processes that involve many services, applications, human interactions for which using a BPM engine, its connectors, its modeling tools can be justified. But this is clearly not for everybody.
Now, to use IBM Process Server, you'll need a license, you'll need an app server to deploy it (at random, WebSphere), some (IBM) machines, maybe some expensive connectors, some licenses for the modeling tools, etc. So I'm not surprised that IBM makes noise about it (even if don't really have the same feeling), selling such a solution must be a good deal for them (not even mentioning the consulting they will add to the bill).
And BPEL, which is a standardized language to describe flows as a sequences of services consuming or producing XML messages, i.e. a generalization of BPM through XML and Web Services, is another brick allowing to promote SOA a bit further, feeding the marketing soup. So, again, there is nothing surprising in the fact that software vendors try to promote it.
Conceptually, I don't think that BPM, BPEL, etc are bad ideas. But as I said, they are not for everybody. If they don't solve anything for you, then using them would be a bad idea. But this does not necessarily invalidate them as concepts.
IBM has multiple offerings now in this space.
The acquisition Lombardi and heritage WPS are not merged as IBM Business Process manager. There is also a FileNet BPM that is available from IBM which are targetted towards Document centric BPM solutions.
Lombardi stack effectively uses BPMN while WPS uses BPEL as the orchecstration mechanism.
The IBM/Oracle camp had chosen the BPEL path while the others like Appian, Lombardi, Pega etc had come in from using BPMN as the execution model for the business process.
Both of them are widely used and have a meaningful reason to exist.
HTH
Manglu