Friday, January 28, 2011
funpiper.com - Plan Events and Parties, Broadcast and Share
My Two Cents on SOA & Startups
An organization needs to spend a lot (COST) to achieve a true SOA based architecture just because SOA is not only limited to Service and their interactions. Following are areas which needs to be considered for achieving an “Agile SOA” platform:
- Service
- Governance
- Architecture
- Process
- People
- Engagement & Delivery Operation
Trust me, really speaking, it would not be very SMART & INTELLIGENT if we tell to our clients that we offer SOA based solutions. WE COULD SIMPLY BE CAUGHT UNAWARE! Simply because if we get an SOA expert across the table, we would simply find ourselves struggling with some real tough questions on SOA governance, process, service discovery, Delivery & Operations Management (ITIL) aspects of SOA. So, we rather should take caution (MAKE RIGHT CHOICE OF WORDS) when we speak to our clients that we offer SOA-based solution as it could simply backfire!
And, this is very natural that an organization cannot achieve “Agile SOA” status in first few years as no organization (especially start-ups) could IGNORE COST-EFFECTIVENESS of the solutions. Or, it will simply be DEAD!
Its very natural that in the initial years, organization would want to be happy with SOA based solution rated as “Ad-hoc SOA” status. That said, pl feel free to ask for various transitions for SOA and roadmap that an organization need to take to transition from “Ad-hoc SOA” to “Agile SOA” status.
Tuesday, January 25, 2011
Is the Java Dynasty Seeing the Beginning of the End?
Tuesday, January 18, 2011
JBoss AS 6 out with JEE 6 Web Profile Specs
Monday, January 17, 2011
Performance management and Monitoring strategy for SOA
- Simple strategy: The Simple Strategy runs the specified number of requests with the specified delay between each run to simulate a "breathing space" for the server.
- Fixed rate strategy: Fixed rate strategy guarantees a fixed number of requests in a given time period.
- Variable load strategy: This strategy related to vary the load. Following are key strategies for variable load:
- Variance: This varies the number of requests over time in a “sawtooth” manner as configured; set the Interval to the desired value and the Variance to the how much the number of requests should decrease and increase.
- Burst: this strategy is specifically designed for Recovery Testing and takes variance to its extreme; it does nothing for the configured Burst Delay, then runs the configured number of requests for the “Burst Duration” and goes back to sleep.
- Thread: This lets you linearly change the number of requests from one level to another over the run of the stress test. It’s main purpose is as a means to identify at which level certain statistics change or events occur, for example to find at which request count, the maximum TPS or BPS can be achieved or to find at which request count, at which functional testing errors start occurring.
- Grid: this strategy allows to specifically configure the relative change in number of requests over time, its main use for this is more advanced scenario and recovery testing, where you need to see the services behaviour under varying loads and load changes.
- Script: the script strategy is the ultimate customization possibility; the script you specify is called regularly and should return the desired number of requests at that current time.
Sunday, January 16, 2011
Top five scripting languages on the JVM
Some cool features of Tomcat 7
LazyLogger for Optimal Logging
public void log(Level level, Object... params) {
// Check logging level before continuing
if (logger.isLoggable(level)) {
String message;
if (params != null) {
if (params.length == 1) {
message = String.valueOf(params[0]);
} else {
StringBuilder buf = new StringBuilder();
for (Object param : params) {
buf.append(param);
}
message = buf.toString();
}
} else {
message = "null";
}
logger.log(level, message);
}
}