J9 just returned from the Cloud Computing Expo and SOAWorld convention, held last week in San Jose, CA. The most common question we heard from convention participants who came by our booth was "What *is* SOA anyway?" Pretty telling that while there is a need and a place for SOA, it's not for everyone and it's not a trivial adoption.
Perhaps equally telling was the shadow the topic of cloud computing cast. On one hand, there was an expectation that everyone needs a cloud computing strategy, while at the same time murmurs of "it's just a fad." Like most technologies, it will turn out to be somewhere in the middle.
The trends of distributed computing, cheaper and more plentiful hardware, escalating power, cooling, and administration all lead to a situation where cloud computing makes sense for many applications. On the other hand, those pundits who notice the intellectual property, vendor lock-in, security, and reliability concerns of the cloud have valid points. Many companies will find that the potential fiscal savings cannot be outweighed by these business risks.
What's the J9 take on all of this? Pragmatism. For certain customers and applications, SOA and cloud computing make a lot of sense. We've developed deep organizational understanding of how to make customers successful with SOA. We are active consumers of cloud computing and intend to be active proponents where it makes sense for our customer's needs. As vendor offerings mature, we are confident that many of the current concerns, especially around lock-in, will be resolved such that cloud computing will make sense for more and more types of applications.
Monday, December 1, 2008
Wednesday, October 29, 2008
Sometimes it's not about the technology
In a recent conversation, I was asked about tool support for enforcing application architecture. The original team for this project had been increased from under 5 to more than 20, and many of the newcomers failed to grasp the overall architecture, choosing instead to forge their own way ahead for each new functional component. A reflection of this was the copy-paste coding, duplicating blocks of functionality with minor variations throughout the code base. What had started as a an application rewrite aimed at creating a model for future application projects throughout the department was quickly turning into a very sloppy project.
The question I was asked is a common, but unfortunate one. Things have been lean in many IT departments for a long time, even before the current economic downturn. I can't remember the last time I met a development team that was using anything other than cost-free tools and it's becoming very rare to meet any development team that has more than a skeleton crew as so much work has been sent offshore in the name of cost cutting. This is not to complain about either of those factors, but rather to recognize the state of affairs; this is reality, and it isn't going to change. The real frustration is the lack of skilled managers who recognize the difference between management and technology problems, which is directly correlated with the emphasis on cost over quality.
In the particular case I mentioned, it is impractical to try to enforce architecture through technology and even if it were, a poor excuse for good management. Don't misunderstand - the right architecture is addicting and leads developers to want to follow the pattern, so can act as a natural enforcer. My argument is that expecting technology to separate the wheat from the chaff when it comes to talent or productivity is asking for trouble and letting managers act irresponsibly. If a team has "renegade" developers who are creating sloppy, unmaintainable code outside the constraints of a selected architecture, then that's a reflection on ineffective technical management as much as a reflection on those developers. A tool might tell you who broke the build or how many times the same code block has been copied and pasted, but it is the responsibility of technical managers to notice problems, quantify, respond, guide, and otherwise act as stewards. The root cause is that due an endemic lack of training, rampant age discrimination, short sighted yet ineffective cost cutting, and the outright gutting of departments, the IT managers of today are grossly ill-equipped to both understand and handle these problems.
Here's another story. I once worked for a company with a publicly stated policy of never hiring consultants or contractors of any kind in its IT division. The history behind this was that many years before, a large well-known technology consultancy had come in and spent several years and several million dollars evaluating the technology operations. The final deliverable was two binders worth of "best practices." Needless to say, the CIO of the time was less than pleased with the way his money had been spent. The irony of course is that he should have been pointing the finger at himself, not the consultants.
The problem itself in this case wasn't with the vendor, or the technology and methodology being recommended, but with the way the project was mismanaged by that CIO. Anyone who has been in this industry for even a few years has dozens of these stories to tell and a pattern becomes clear. It really doesn't matter what tools you are using or how modern your methodologies. The differentiating factor between successfully delivering working technology solutions and utter disasters boils down to one thing: people. If your managers are simply filling out a space on the organizational chart and not actually being effective, or even worse expecting software itself to act as panacea for personnel matters, then you've got problems regardless of how SOA, Agile, and Cloud you may wish things to be.
The question I was asked is a common, but unfortunate one. Things have been lean in many IT departments for a long time, even before the current economic downturn. I can't remember the last time I met a development team that was using anything other than cost-free tools and it's becoming very rare to meet any development team that has more than a skeleton crew as so much work has been sent offshore in the name of cost cutting. This is not to complain about either of those factors, but rather to recognize the state of affairs; this is reality, and it isn't going to change. The real frustration is the lack of skilled managers who recognize the difference between management and technology problems, which is directly correlated with the emphasis on cost over quality.
In the particular case I mentioned, it is impractical to try to enforce architecture through technology and even if it were, a poor excuse for good management. Don't misunderstand - the right architecture is addicting and leads developers to want to follow the pattern, so can act as a natural enforcer. My argument is that expecting technology to separate the wheat from the chaff when it comes to talent or productivity is asking for trouble and letting managers act irresponsibly. If a team has "renegade" developers who are creating sloppy, unmaintainable code outside the constraints of a selected architecture, then that's a reflection on ineffective technical management as much as a reflection on those developers. A tool might tell you who broke the build or how many times the same code block has been copied and pasted, but it is the responsibility of technical managers to notice problems, quantify, respond, guide, and otherwise act as stewards. The root cause is that due an endemic lack of training, rampant age discrimination, short sighted yet ineffective cost cutting, and the outright gutting of departments, the IT managers of today are grossly ill-equipped to both understand and handle these problems.
Here's another story. I once worked for a company with a publicly stated policy of never hiring consultants or contractors of any kind in its IT division. The history behind this was that many years before, a large well-known technology consultancy had come in and spent several years and several million dollars evaluating the technology operations. The final deliverable was two binders worth of "best practices." Needless to say, the CIO of the time was less than pleased with the way his money had been spent. The irony of course is that he should have been pointing the finger at himself, not the consultants.
The problem itself in this case wasn't with the vendor, or the technology and methodology being recommended, but with the way the project was mismanaged by that CIO. Anyone who has been in this industry for even a few years has dozens of these stories to tell and a pattern becomes clear. It really doesn't matter what tools you are using or how modern your methodologies. The differentiating factor between successfully delivering working technology solutions and utter disasters boils down to one thing: people. If your managers are simply filling out a space on the organizational chart and not actually being effective, or even worse expecting software itself to act as panacea for personnel matters, then you've got problems regardless of how SOA, Agile, and Cloud you may wish things to be.
Friday, October 17, 2008
Tips and tricks for discovering performance issues before they become production issues.
Nobody wants to get the phone call. The one that comes at 6 am, informing you that it is going to be a very long day due to a crisis in the software you built. It could be an outright crash, data corruption, or users fleeing your application due to its lagging performance. It doesn't have to be like this; there are reliable ways to put your application under the microscope within the bounds of reasonable effort.
First and foremost, you need tools. There are a range of tools available for all budgets and as in most things, you get what you pay for. Start simple -- you need a way to generate load against your application and you need a code profiler. Freely available open source tools like JMeter are a good place to start -- you can become productive in under an hour. There are countless inexpensive code profilers available, just a web search away. What these lack in features, they make up for in simplicity and price. If you've never examined the performance of your application, then anything is a step up at this point.
Once we start generating consistent load against our applications and run a code profiler, what should we be looking for? The approach we use at J9 is one of pragmatism: focus on the areas with the largest potential return. For example, many books on Java application performance start with a discussion of String versus StringBuffer or StringBuilder. Perhaps they include information on choosing the appropriate Collection types to reduce synchronization overhead. These are fantastic suggestions, but there are plenty of other, more pragmatic improvements to be made before we get to this level of granularity. Take initial jvm heap sizes as an example. This is now one of the first questions we ask customers when evaluating their application performance -- have you explicitly set an appropriate size? We've seen countless customers pulling their hair out due to server crashes have their concerns dissipate by making this trivial change.
We've seen a common list of problems over the years that yield significant improvements with a few simple changes. Besides the initial jvm heap setting:
-- Object pooling to external dependencies. Are you using it? Are your pools sized correctly to expected demand?
-- XML serialization: This one normally shows up as high-CPU use and causes your application to spend all its effort in processing wrappers rather than the business problem at hand.
-- Poor database interaction: There are a number of basic issues here, like cumbersome sql statements and failure to properly index tables.
-- Lack of caching: Dynamically fetching otherwise static data (like jndi entries) or a weak caching strategy leading to poor hit ratio. This assumes that any caching at all has been implemented.
-- Slow report or page rendering: This is common, especially on pdf generation with large data sets. Typically this is an architectural problem stemming from a monolithic approach.
-- Slow network, inadequate hardware: Need to have the basics in place before we can expect performance.
Under even a consistent, moderate amount of load a rudimentary code profiler should offer hints at the above common problems.
Once we've got our tools selected and set up and we start looking for trouble, what should our approach be? Optimally, we're striving to employ the scientific method, beginning with simple divide-and-conquer. First, I take a look across the entire application, noticing what transactions stand out in terms of latency. My search begins there because that tends to be the low-hanging fruit: many problems, regardless of their root cause, manifest as latency issues. It also allows me to potentially focus on getting an early win -- if I can reduce an annoying 10 second response time to 5 seconds, it's a noticeable difference to an end user versus saving an extra 256 megabytes of ram which only a purist would notice. With the information about the slowest performing transactions, I can then take a tier or layer perspective. This step involves examining the performance of my application at each step -- where are the slow downs in the web tier? Are there bottlenecks in the database? What about web services or message oriented middleware? Maybe there are problems within the business logic itself. The key to this examination is keeping concerns separated: just look at the performance within one layer at a time, ignoring the performance within other layers.
Once you've identified the layer or tier where a problem is occurring, begin looking for data that enables you to build a testable hypothesis. Be careful to not assume the first problem you find is the root cause -- many problems are side-effects of the real issue. For example, is the sql statement slow running because it has not been optimized, because the invoked tables have not been indexed, or because of poor data validation and legitimacy? A typical work flow might be as follows:
-- Slowness is identified at the database.
-- Slowest running sql statements are identified.
-- Statement execution is divided into connection and execution latency. Which one is worse?
-- Assuming connection latency is significant, look for obvious issues:
-- Are we using connection pooling?
-- Are we actually pulling our connections from the pools we have configured?
-- Are the pools sized adequate with the expected transaction throughput?
-- Are there network or connectivity issues that would cause connections to expire or be slow to create?
-- Create a test or collect supporting data to eliminate each of these potential concerns.
-- For each issue identified, devise a solution and test the effectiveness of that solution.
-- Repeat process until application achieves acceptable performance levels.
-- Implement monitoring, thresholds, and alerts to proactively catch future issues.
As you work through problems, be aware of what you can and cannot control. There are physical limits to computing that are outside your control, just like code from a vendor will seldom quickly be repaired.
We can summarize the approach recommended by J9 as follows:
-- Look for solutions with a high probability of success
-- Be aware of the basic limits and issues with your environment.
-- Use a scientific, quantitative approach.
-- Put in place tools that make finding and testing for issues easier
First and foremost, you need tools. There are a range of tools available for all budgets and as in most things, you get what you pay for. Start simple -- you need a way to generate load against your application and you need a code profiler. Freely available open source tools like JMeter are a good place to start -- you can become productive in under an hour. There are countless inexpensive code profilers available, just a web search away. What these lack in features, they make up for in simplicity and price. If you've never examined the performance of your application, then anything is a step up at this point.
Once we start generating consistent load against our applications and run a code profiler, what should we be looking for? The approach we use at J9 is one of pragmatism: focus on the areas with the largest potential return. For example, many books on Java application performance start with a discussion of String versus StringBuffer or StringBuilder. Perhaps they include information on choosing the appropriate Collection types to reduce synchronization overhead. These are fantastic suggestions, but there are plenty of other, more pragmatic improvements to be made before we get to this level of granularity. Take initial jvm heap sizes as an example. This is now one of the first questions we ask customers when evaluating their application performance -- have you explicitly set an appropriate size? We've seen countless customers pulling their hair out due to server crashes have their concerns dissipate by making this trivial change.
We've seen a common list of problems over the years that yield significant improvements with a few simple changes. Besides the initial jvm heap setting:
-- Object pooling to external dependencies. Are you using it? Are your pools sized correctly to expected demand?
-- XML serialization: This one normally shows up as high-CPU use and causes your application to spend all its effort in processing wrappers rather than the business problem at hand.
-- Poor database interaction: There are a number of basic issues here, like cumbersome sql statements and failure to properly index tables.
-- Lack of caching: Dynamically fetching otherwise static data (like jndi entries) or a weak caching strategy leading to poor hit ratio. This assumes that any caching at all has been implemented.
-- Slow report or page rendering: This is common, especially on pdf generation with large data sets. Typically this is an architectural problem stemming from a monolithic approach.
-- Slow network, inadequate hardware: Need to have the basics in place before we can expect performance.
Under even a consistent, moderate amount of load a rudimentary code profiler should offer hints at the above common problems.
Once we've got our tools selected and set up and we start looking for trouble, what should our approach be? Optimally, we're striving to employ the scientific method, beginning with simple divide-and-conquer. First, I take a look across the entire application, noticing what transactions stand out in terms of latency. My search begins there because that tends to be the low-hanging fruit: many problems, regardless of their root cause, manifest as latency issues. It also allows me to potentially focus on getting an early win -- if I can reduce an annoying 10 second response time to 5 seconds, it's a noticeable difference to an end user versus saving an extra 256 megabytes of ram which only a purist would notice. With the information about the slowest performing transactions, I can then take a tier or layer perspective. This step involves examining the performance of my application at each step -- where are the slow downs in the web tier? Are there bottlenecks in the database? What about web services or message oriented middleware? Maybe there are problems within the business logic itself. The key to this examination is keeping concerns separated: just look at the performance within one layer at a time, ignoring the performance within other layers.
Once you've identified the layer or tier where a problem is occurring, begin looking for data that enables you to build a testable hypothesis. Be careful to not assume the first problem you find is the root cause -- many problems are side-effects of the real issue. For example, is the sql statement slow running because it has not been optimized, because the invoked tables have not been indexed, or because of poor data validation and legitimacy? A typical work flow might be as follows:
-- Slowness is identified at the database.
-- Slowest running sql statements are identified.
-- Statement execution is divided into connection and execution latency. Which one is worse?
-- Assuming connection latency is significant, look for obvious issues:
-- Are we using connection pooling?
-- Are we actually pulling our connections from the pools we have configured?
-- Are the pools sized adequate with the expected transaction throughput?
-- Are there network or connectivity issues that would cause connections to expire or be slow to create?
-- Create a test or collect supporting data to eliminate each of these potential concerns.
-- For each issue identified, devise a solution and test the effectiveness of that solution.
-- Repeat process until application achieves acceptable performance levels.
-- Implement monitoring, thresholds, and alerts to proactively catch future issues.
As you work through problems, be aware of what you can and cannot control. There are physical limits to computing that are outside your control, just like code from a vendor will seldom quickly be repaired.
We can summarize the approach recommended by J9 as follows:
-- Look for solutions with a high probability of success
-- Be aware of the basic limits and issues with your environment.
-- Use a scientific, quantitative approach.
-- Put in place tools that make finding and testing for issues easier
Tuesday, October 14, 2008
SOA does not mean agnostic
As a follow up to our last post about the nature of SOA, I wanted to speak to a common misconception. Here are two statements I hear with all-too-common frequency:
1) SOA is about masking the route to a service from its implementation.
2) The underlying transport protocols used in SOA should always be hidden.
It seems in technology there is an ever-pervasive interest in adding more and more layers of indirection. Its a situation where if we don't understand the reason for such layers, we can quickly add unnecessary overhead and complexity to otherwise simple problems. In the case of the above statements, the underlying goal -- to create flexible implementations while masking details from a service user -- is a good one, but without understanding the nuances involve, the commonly heard refrains noted above are in gross error.
Let's address point one. It's true that things like UDDI and other kinds of service discovery help us to change the location or even implementation of our services, but let's be clear that implementing UDDI is not a primary goal of SOA, rather a by-product of an implementation approach. You can do SOA without having an intermediary routing requests between service providers and service consumers; you will simply have a more tightly coupled implementation. To be clear, there have been ways of creating this kind of indirection since long before the word SOA entered our lexicon.
Next we should address the idea of protocol agnosticism. If I had a nickel for every time I heard the statement "SOA masks the underlying protocol" I'd be retired. Let's reflect upon reality for a minute -- even if we ask a service directory for the means of reaching a service, we've made some kind of conscious effort to ask that that service directory, which innately means we've chosen a protocol. On a related example, if we offered access to a service over both message-oriented middleware and via http, we'd be forced to supply an sdk/api to service consumers that would mask the underlying protocol used. Whoops -- sdks? apis? Isn't that part of the very draw to Web Services in the first place, that is not having to support binary apis in multiple languages for all of our consumers? In the end, it's a fallacy and in some cases even undesirable to declare protocol agnosticism realistic or even a desired goal of SOA.
1) SOA is about masking the route to a service from its implementation.
2) The underlying transport protocols used in SOA should always be hidden.
It seems in technology there is an ever-pervasive interest in adding more and more layers of indirection. Its a situation where if we don't understand the reason for such layers, we can quickly add unnecessary overhead and complexity to otherwise simple problems. In the case of the above statements, the underlying goal -- to create flexible implementations while masking details from a service user -- is a good one, but without understanding the nuances involve, the commonly heard refrains noted above are in gross error.
Let's address point one. It's true that things like UDDI and other kinds of service discovery help us to change the location or even implementation of our services, but let's be clear that implementing UDDI is not a primary goal of SOA, rather a by-product of an implementation approach. You can do SOA without having an intermediary routing requests between service providers and service consumers; you will simply have a more tightly coupled implementation. To be clear, there have been ways of creating this kind of indirection since long before the word SOA entered our lexicon.
Next we should address the idea of protocol agnosticism. If I had a nickel for every time I heard the statement "SOA masks the underlying protocol" I'd be retired. Let's reflect upon reality for a minute -- even if we ask a service directory for the means of reaching a service, we've made some kind of conscious effort to ask that that service directory, which innately means we've chosen a protocol. On a related example, if we offered access to a service over both message-oriented middleware and via http, we'd be forced to supply an sdk/api to service consumers that would mask the underlying protocol used. Whoops -- sdks? apis? Isn't that part of the very draw to Web Services in the first place, that is not having to support binary apis in multiple languages for all of our consumers? In the end, it's a fallacy and in some cases even undesirable to declare protocol agnosticism realistic or even a desired goal of SOA.
Monday, October 13, 2008
Systems are not Services
In our ongoing discussion about what SOA is and is not, it's time to address another popular misconception -- that everything is a service. Nothing could be further from the truth, which is why we also have to follow up with this reality check: SOA is hard.
Too often when working with customers, I hear the common misconception that they are already doing SOA. After all, they have a claims service, a billing service, and an order management service that have all been "web-enabled" therefore they are completely buzzword compliant! This is where we need to be able to address some terminology:
-- Service: A concrete, decomposed, independent functional offering.
-- Application: An aggregation of related services
-- System: An aggregation of related applications.
Now time for an example:
-- Service: User login, Change customer address.
-- Application: User account management
-- System: Revenue Management (encompassing applications like user account management, bill pay, and product ordering)
Thus, having two or more monolithic systems or applications now speaking http does not constitute SOA.
Now, on that note about SOA being hard. The reality is, while SOA makes a lot of sense on greenfield development or in times of major IT overhauls, it's a challenge to decompose a system or application into independent, reusable services and to carry through on their implementation. It will take aggressive sheparding by technical architects to both lay out such a vision and to keep services in their appropriate scope. For many organizations, SOA is enticing but will ultimately prove too overwhelming in the face of declining budgets and more pressing priorities. And, as long as vendors benefit from system lock-in, the likelihood of SOA adoption through vendor selection is unclear.
Too often when working with customers, I hear the common misconception that they are already doing SOA. After all, they have a claims service, a billing service, and an order management service that have all been "web-enabled" therefore they are completely buzzword compliant! This is where we need to be able to address some terminology:
-- Service: A concrete, decomposed, independent functional offering.
-- Application: An aggregation of related services
-- System: An aggregation of related applications.
Now time for an example:
-- Service: User login, Change customer address.
-- Application: User account management
-- System: Revenue Management (encompassing applications like user account management, bill pay, and product ordering)
Thus, having two or more monolithic systems or applications now speaking http does not constitute SOA.
Now, on that note about SOA being hard. The reality is, while SOA makes a lot of sense on greenfield development or in times of major IT overhauls, it's a challenge to decompose a system or application into independent, reusable services and to carry through on their implementation. It will take aggressive sheparding by technical architects to both lay out such a vision and to keep services in their appropriate scope. For many organizations, SOA is enticing but will ultimately prove too overwhelming in the face of declining budgets and more pressing priorities. And, as long as vendors benefit from system lock-in, the likelihood of SOA adoption through vendor selection is unclear.
Friday, October 10, 2008
Why J9 is building protocols for HP LoadRunner?
Our experience last week at StarWest was filled with eureka moments. That's really the greatest benefit we get from attending conference like StarWest -- the opportunity to get hands on with IT practitioners and get a dose of honest feedback.
One of the questions we found ourselves answering over and over related to our jms and jdbc protocols for HP LoadRunner offerings, phrased typically as "Why do I need that?" In fact, the most surprising yet common question we answered was "Doesn't HP already offer this?"
Here's how this situation plays out. When you license HP LoadRunner, whether you realize it or not, you are paying for specific protocols that plug into it. The most common scenario involves purchasing the web protocol, which enables you to record and replay a series of actions against a browser-delivered application. This is a fantastic start down the road of performance and scalability testing, but it isn't the complete story. What if in the course of your performance testing, you want to understand just the scalability of your database separate from the overall scalability of your application? With just the web protocol, you can't do it. And, HP doesn't offer anything that will target your databases and message-oriented middleware in their current protocol lineup. This is where HP Partners like J9 are stepping in to fill a gap, with HP's blessing. With J9's JDBC protocol, you record and replay all of the sql statements -- the interactions between your application and the database -- which allows you to measure just the database performance. The same concept applies to your messaging providers. With J9's JMS protocol, JMS messages are captured and both the consumer and provider perspective can be simulated under load conditions.
Using feedback like we received at StarWest, J9 is continuing our road map of building protocols to enable customers to maximize their investment in HP LoadRunner. We encourage you to download our free, full-featured trial version and to send us feedback on your performance testing experiences.
One of the questions we found ourselves answering over and over related to our jms and jdbc protocols for HP LoadRunner offerings, phrased typically as "Why do I need that?" In fact, the most surprising yet common question we answered was "Doesn't HP already offer this?"
Here's how this situation plays out. When you license HP LoadRunner, whether you realize it or not, you are paying for specific protocols that plug into it. The most common scenario involves purchasing the web protocol, which enables you to record and replay a series of actions against a browser-delivered application. This is a fantastic start down the road of performance and scalability testing, but it isn't the complete story. What if in the course of your performance testing, you want to understand just the scalability of your database separate from the overall scalability of your application? With just the web protocol, you can't do it. And, HP doesn't offer anything that will target your databases and message-oriented middleware in their current protocol lineup. This is where HP Partners like J9 are stepping in to fill a gap, with HP's blessing. With J9's JDBC protocol, you record and replay all of the sql statements -- the interactions between your application and the database -- which allows you to measure just the database performance. The same concept applies to your messaging providers. With J9's JMS protocol, JMS messages are captured and both the consumer and provider perspective can be simulated under load conditions.
Using feedback like we received at StarWest, J9 is continuing our road map of building protocols to enable customers to maximize their investment in HP LoadRunner. We encourage you to download our free, full-featured trial version and to send us feedback on your performance testing experiences.
Tuesday, September 30, 2008
Let's try to define SOA, shall we?
I've been holding a kind of informal survey lately, asking everyone I meet to define SOA for me. Not that it stands for Service-Oriented Architecture, but rather what it actually means within their organization and what value it holds. The reality is, while there are many viewpoints on what SOA might entail and a general sense that there's something worthwhile to it, it's a sadly misused term. The reason for that is that SOA is being sold to two different groups for two very different purposes. With this in mind, I'd like to propose two completely distinct, yet equally valid viewpoints:
1) SOA is the abstraction of corporate intellectual property and processes from their method of delivery and provider source.
2) SOA is a software design architecture where applications are decomposed into fine-grained, decoupled, abstracted, multi-purpose services. A hallmark of SOA is an emphasis on loose-coupling through message-format based protocols, rather than the function signature based agreement of earlier distributed architectures.
This second definition involves some delicate thinking about how distributed applications are built from an application performance perspective. At J9, we've been working with this type of application and the performance problems common in distributed applications for a number of years now. SOA is hard to do right, but solves a major, common bottleneck if undertaken with care. This problem is one of course-grained applications, which invariably end up with sizable data sets to be serialized / deserialized on both ends of the connection. Put simply, J9's consultants have seen countless applications where for example, 1 megabyte or more of XML is sent from a server to a client, with high-CPU creation and parsing, and equally-unacceptable latency the result.
SOA really is the answer to this, as companies like Amazon.com will attest to. According to an article based on a conversation with Werner Vogels, titled Learning from the Amazon Technology Platform, Amazon's front page is made up of more than a hundred distinct service invocations which fire simultaneously and are reassembled asynchronously into the page you see. The point here is that each of those actions involved -- like checking who you are, the status of your shopping cart, what favorites to present you, and so on -- have been decomposed and abstracted into fine-grained, light-weight services.
A much misunderstood but highly-touted feature of this type of architecture is the speed of replacing any of those services with an alternative provider. Personally, I have trouble imagining it being possible to replace any sufficiently complex service simply by making a url change, but there's still a nugget of truth to this point. By keeping services extremely granular and general purpose, it's practically innate that such a service will be easier to make changes to and deploy -- a smaller code base means fewer dependencies and potential for conflict.
In this regard, SOA becomes a manifestation of the best practices in software development that have been argued for years:
-- Smaller, more manageable code bases
-- Clearer division of labor
-- Abstraction of systems logic from delivery and access
-- Discrete, unit-testable components
-- Improved performance for both server and network resources
So in the end, while SOA may have begun life as a broad marketing term, there is a concrete definition, the value of which should resonate with technical and business-minded people alike.
1) SOA is the abstraction of corporate intellectual property and processes from their method of delivery and provider source.
2) SOA is a software design architecture where applications are decomposed into fine-grained, decoupled, abstracted, multi-purpose services. A hallmark of SOA is an emphasis on loose-coupling through message-format based protocols, rather than the function signature based agreement of earlier distributed architectures.
This second definition involves some delicate thinking about how distributed applications are built from an application performance perspective. At J9, we've been working with this type of application and the performance problems common in distributed applications for a number of years now. SOA is hard to do right, but solves a major, common bottleneck if undertaken with care. This problem is one of course-grained applications, which invariably end up with sizable data sets to be serialized / deserialized on both ends of the connection. Put simply, J9's consultants have seen countless applications where for example, 1 megabyte or more of XML is sent from a server to a client, with high-CPU creation and parsing, and equally-unacceptable latency the result.
SOA really is the answer to this, as companies like Amazon.com will attest to. According to an article based on a conversation with Werner Vogels, titled Learning from the Amazon Technology Platform, Amazon's front page is made up of more than a hundred distinct service invocations which fire simultaneously and are reassembled asynchronously into the page you see. The point here is that each of those actions involved -- like checking who you are, the status of your shopping cart, what favorites to present you, and so on -- have been decomposed and abstracted into fine-grained, light-weight services.
A much misunderstood but highly-touted feature of this type of architecture is the speed of replacing any of those services with an alternative provider. Personally, I have trouble imagining it being possible to replace any sufficiently complex service simply by making a url change, but there's still a nugget of truth to this point. By keeping services extremely granular and general purpose, it's practically innate that such a service will be easier to make changes to and deploy -- a smaller code base means fewer dependencies and potential for conflict.
In this regard, SOA becomes a manifestation of the best practices in software development that have been argued for years:
-- Smaller, more manageable code bases
-- Clearer division of labor
-- Abstraction of systems logic from delivery and access
-- Discrete, unit-testable components
-- Improved performance for both server and network resources
So in the end, while SOA may have begun life as a broad marketing term, there is a concrete definition, the value of which should resonate with technical and business-minded people alike.
Thursday, September 25, 2008
J9 Technologies is going to SOAworld!
We are hitting up as many conferences as we can without pulling out our hair in pre- and post-conference angst, this is yet another one that we will be giving bottle openers away at! And that is not all. We will have bookmarks! (In case you still read that paper stuff – and lest you forget about the digitized ordeal when you do.) And of course, you can get a free trial for our new LoadRunner Protocol Add-ins, or a login to our cool On Demand Testing Suite.
Here is the plug from the SOAworld conference organizers. When we find out our booth number, we will be sure to post it here first.
The 14th International SOA World Conference & Expo 2008 West will take place on November 19-21, 2008 at The Fairmont Hotel in San Jose, CA.
The most important business benefit that service-oriented architecture (SOA) can provide is the ability to respond swiftly to change: changes in the market, the supply chain, strategic processes, and regulations. Make sure that you are able in 2008/9 to declare your own company's SOA journey toward such responsiveness and agility a success. Come to SOA World Conference & Expo 2008 West and learn just how much SOA can do for your business and for your developers.
There is no other event in the USA with as rich and varied opportunities for learning, networking, and tracking innovation occurring in the IT infrastructure, architecture, and standards communities. The speakers are all seasoned SOA practitioners with a passion for helping to usher in the new era of IT agility made possible by standardized best practices, pervasive communication & data protocols, and a general movement toward openness and interop in the industry.
Here is the plug from the SOAworld conference organizers. When we find out our booth number, we will be sure to post it here first.
The 14th International SOA World Conference & Expo 2008 West will take place on November 19-21, 2008 at The Fairmont Hotel in San Jose, CA.
The most important business benefit that service-oriented architecture (SOA) can provide is the ability to respond swiftly to change: changes in the market, the supply chain, strategic processes, and regulations. Make sure that you are able in 2008/9 to declare your own company's SOA journey toward such responsiveness and agility a success. Come to SOA World Conference & Expo 2008 West and learn just how much SOA can do for your business and for your developers.
There is no other event in the USA with as rich and varied opportunities for learning, networking, and tracking innovation occurring in the IT infrastructure, architecture, and standards communities. The speakers are all seasoned SOA practitioners with a passion for helping to usher in the new era of IT agility made possible by standardized best practices, pervasive communication & data protocols, and a general movement toward openness and interop in the industry.
StarWest 2008 Conference Update - We will be in Booth #9
As you may already know* the folks at J9 Technologies are pleased to announce that we will be attending the StarWest 2008 Conference in Anaheim, CA next week. The conference runs for days and days, but we will be participating as an exhibitor, so as far as we are concerned the most important part of the conference goes from Sept. 30th through Oct. 2nd. We will be showing off our new Protocol Add-ins for LoadRunner, giving demos and free trial licenses for them, unveiling to our new On Demand Testing Suite, and generally schmoozing with strangers. Come by and visit us at Booth #9 and see the only one-handed bottle opener you will probably ever get for free.
And if all of that doesn’t give you reason enough, and you are still in the fence about such a proposition, here are the top ten reasons to attend this event – as compiled by the StarWest organizers themselves. Some of which may seem boring, yet informative.
1. Over 100 learning sessions: tutorials, keynotes, conference sessions, bonus sessions, and more
2. In-depth tutorials, half- and full-day options—double the number of classes from last year
3. Cutting-edge testing answers from top testing experts
4. Presentations from highly experienced testing professionals
5. Networking opportunities with your peers in the industry
6. Special events—welcome reception, bookstore, meet the speakers, and more
7. The largest testing EXPO anywhere
8. Group discounts—bring your whole team
9. The perfect balance of learning and fun in Southern California
10. All this at the happiest place on Earth—Disneyland® Hotel!
We hope to see you there!
*If you don’t already know about a certain Belated Disneyland Fetish that one marketing manager in our company has, please scroll down to the posting featuring keyword “Disneyland” to learn all about the excitement first hand.
And if all of that doesn’t give you reason enough, and you are still in the fence about such a proposition, here are the top ten reasons to attend this event – as compiled by the StarWest organizers themselves. Some of which may seem boring, yet informative.
1. Over 100 learning sessions: tutorials, keynotes, conference sessions, bonus sessions, and more
2. In-depth tutorials, half- and full-day options—double the number of classes from last year
3. Cutting-edge testing answers from top testing experts
4. Presentations from highly experienced testing professionals
5. Networking opportunities with your peers in the industry
6. Special events—welcome reception, bookstore, meet the speakers, and more
7. The largest testing EXPO anywhere
8. Group discounts—bring your whole team
9. The perfect balance of learning and fun in Southern California
10. All this at the happiest place on Earth—Disneyland® Hotel!
We hope to see you there!
*If you don’t already know about a certain Belated Disneyland Fetish that one marketing manager in our company has, please scroll down to the posting featuring keyword “Disneyland” to learn all about the excitement first hand.
Monday, September 22, 2008
JMS Protocol Add-in for LoadRunner is now available
With the explosion of Message Oriented Middleware (MOM) applications and their SOA counterparts, QA professionals must face the challenge of creating real-world testing conditions for these complicated, multi-node, composite applications. From a testing perspective…How do you generate hundreds of unique messages every second? How do you simulate a transaction that consists of HTTP, SOAP, JMS and JDBC protocols? What is the maximum de-queue rate of the application’s Message-Driven Beans? How can you test all of the possible routes a message may take through the application without requiring the Java knowledge to hand-code an extensive test harness?
The JMS Protocol Add-in helps you tackle these problems head on. By extending the capabilities of HP LoadRunner, the JMS Protocol Add-in help stress and isolate problems in the messaging tier and ensure applications are deployed with confidence. Turn a new page on middleware performance testing In today’s multi-tier distributed applications, some of the most critical bottlenecks reside in connections to backend systems, such as a database, message queue or the mainframe. In the past, the crucial task of isolating, testing and tuning messaging operations required creation of complex scripts that rely on in-depth Java and application knowledge. This adds a
tremendous burden to the already full plates faced by many quality assurance teams.
The JMS Protocol Add-in from J9 Technologies helps you stress the messaging middleware
layer and identify bottlenecks before deploying in production. Based on years of testing and diagnostics expertise in helping some of the world’s largest enterprises,
this solution automatically captures all JMS traffic going from a Java application to the backend message queues and plays them back to directly exercise the messaging tier
for high concurrency testing.
The JMS Protocol Add-in for HP LoadRunner helps you:
• Verify messaging infrastructure
supports a high volume of messages
• Obtain an accurate picture of backend
system performance
• Isolate and eliminate performance
bottlenecks in the messaging tier
How it works
Leveraging HP LoadRunner and VuGen technology, the JMS Protocol Add-in records all JMS put and get operations and captures them in standardized scripts. These scripts can be used to simulate targeted loads in terms of concurrent users to almost any JMS provider. This easy-to-use solution helps QA teams scale up backend testing by applying very measurable and repeatable loads that expose any potential problems early in the development cycle. The JMS Protocol Add-in eliminates the dependency on the application tier for direct testing of the messaging tier. Autogenerated scripts represent real-world load, and can be easily parameterized to create accurate and realistic mix of users for stressing the messaging tier. Detailed measurements are captured and provided to the HP LoadRunner Analysis application for side-by-side metric comparisons between test runs.
Get more out of Hp LoadRunner
HP LoadRunner is the market leading performance validation solution embraced by 77% of all QA professionals. J9’s HP LoadRunner Protocol Add-ins are fully integrated into the full suite of HP LoadRunner solutions. The JMS Protocol Add-in can be used alongside all other HP LoadRunner protocols to create a more realistic and comprehensive load test. With the simplicity of the solution, any skilled HP LoadRunner user can start using JMS Protocol Add-in with no additional training, and be productive immediately. With the JMS Protocol Add-in, recording of all JMS put and get operations happen exactly as they occur in sequence, and entirely on the server side. This unique feature is very beneficial in situations where client side recording is not feasible, and allows for server-side only testing that does not require installing VuGen on the backend systems.
The JMS Protocol Add-in helps you tackle these problems head on. By extending the capabilities of HP LoadRunner, the JMS Protocol Add-in help stress and isolate problems in the messaging tier and ensure applications are deployed with confidence. Turn a new page on middleware performance testing In today’s multi-tier distributed applications, some of the most critical bottlenecks reside in connections to backend systems, such as a database, message queue or the mainframe. In the past, the crucial task of isolating, testing and tuning messaging operations required creation of complex scripts that rely on in-depth Java and application knowledge. This adds a
tremendous burden to the already full plates faced by many quality assurance teams.
The JMS Protocol Add-in from J9 Technologies helps you stress the messaging middleware
layer and identify bottlenecks before deploying in production. Based on years of testing and diagnostics expertise in helping some of the world’s largest enterprises,
this solution automatically captures all JMS traffic going from a Java application to the backend message queues and plays them back to directly exercise the messaging tier
for high concurrency testing.
The JMS Protocol Add-in for HP LoadRunner helps you:
• Verify messaging infrastructure
supports a high volume of messages
• Obtain an accurate picture of backend
system performance
• Isolate and eliminate performance
bottlenecks in the messaging tier
How it works
Leveraging HP LoadRunner and VuGen technology, the JMS Protocol Add-in records all JMS put and get operations and captures them in standardized scripts. These scripts can be used to simulate targeted loads in terms of concurrent users to almost any JMS provider. This easy-to-use solution helps QA teams scale up backend testing by applying very measurable and repeatable loads that expose any potential problems early in the development cycle. The JMS Protocol Add-in eliminates the dependency on the application tier for direct testing of the messaging tier. Autogenerated scripts represent real-world load, and can be easily parameterized to create accurate and realistic mix of users for stressing the messaging tier. Detailed measurements are captured and provided to the HP LoadRunner Analysis application for side-by-side metric comparisons between test runs.
Get more out of Hp LoadRunner
HP LoadRunner is the market leading performance validation solution embraced by 77% of all QA professionals. J9’s HP LoadRunner Protocol Add-ins are fully integrated into the full suite of HP LoadRunner solutions. The JMS Protocol Add-in can be used alongside all other HP LoadRunner protocols to create a more realistic and comprehensive load test. With the simplicity of the solution, any skilled HP LoadRunner user can start using JMS Protocol Add-in with no additional training, and be productive immediately. With the JMS Protocol Add-in, recording of all JMS put and get operations happen exactly as they occur in sequence, and entirely on the server side. This unique feature is very beneficial in situations where client side recording is not feasible, and allows for server-side only testing that does not require installing VuGen on the backend systems.
Wednesday, July 23, 2008
JDBC Protocol Add-in for LoadRunner now available from J9 Technologies
Some of the most critical bottlenecks reside in connections to backend systems, such as a database or the mainframe. But testing the connections to these systems is no trivial matter. This often requires creation of complex scripts that rely on in-depth application knowledge and even Java development skills.
JDBC Protocol Add-in helps you stress the data connections and isolate any bottlenecks before deploying in production. It captures all SQL traffic going from a Java application to the backend database and plays them back to directly exercise the data tier for high concurrency testing. This solution leverages J9's expertise in testing and diagnostics of enterprise Java applications and is fully complementary to HP's industry-leading LoadRunner product. This perfect marriage helps reduce testing costs and prevent potential problems in production.
Features
Test application backend without writing Java code
Scale up and perform load tests to simulate hundreds of simultaneous users accessing the database without needing to create a front-end application. This singles out any potential bottlenecks in the critical data connection layer without putting additional burden on the QA teams.
Captures and Plays back JDBC statements
Records and replays all Java SQL statements, including all prepared statements and callable statements.
Enables Simple Parameterization
It's easy to parameterize within the generated test scripts to create a realistic mix of users and data for the high concurrency load tests.
Heterogeneous Platform Support
Works seamlessly with any database, on any OS platform.
Benefits
Shorten testing cycles
Deliver significant time savings in the testing of middleware and backend tiers.
Improve application service levels
Fully stress the critical JDBC connection to prevent potential problems after the applications are deployed.
Baseline data tier performance
With stress tests targeted exclusively at the backend, realistic SLAs can be created to measure and benchmark future performance.
Empower QA Engineers
Enable QA engineers to extensively test the JDBC connection without requiring Java knowledge and without additional training. Fully leverage existing skills in knowledge of HP LoadRunner solution.
Supported Platforms
- all common Java application servers including Weblogic and Websphere.
- all common Databases including Oracle, DB2 and SQL Server
- Java 1.4 and up
Subscribe to:
Posts (Atom)
