Welcome to SOA Thinker
By Jeff Davies-Oracle on Sep 22, 2008
Welcome to SOA Thinker
Welcome to my new blog, SOA Thinker. The purpose of this blog is to discuss various ideas about SOA. Architecture, governance and code will all find a home here. I will also use this blog as a platform to help connect you to internal experts in order to get your real-world issues resolved, and to document those resolutions for the benefit of all readers.
SOA is first and foremost about architecture, but architecture alone has never been enough. Solid, professional code must realize the architecture, just as steel, glass and other building materials realize the architecture of any large scale building. Governance plays it role in this analogy by providing the rules and regulations for the enterprise.
While it is necessary to specialize in a specific discipline (architecture, governance and coding), the more we can learn of the other two disciplines will help us all better communicate, and that is my goal for this blog: not to espouse a particular tool or approach, but promote a fuller understanding of all aspects of SOA. We will leave the ideology out.
I will also use this platform to question the "common sense" ideas that are often bandied about as being fact. The emperor really does not have any clothes on, no matter what the common opinion of the day may be. The simple categorization of ideas as being, "good" or "bad" rarely applies in modern engineering, especially when everyone is learning so much, so quickly. The only way to truly know an idea is to examine it, try it out in a test environment, and discuss its strengths and weaknesses with you peers. I will use this blog as a vehicle for those ideas, allowing everyone to examine these ideas and make up their own minds.
The Definitive Guide to SOA: Oracle Service Bus (second edition)
The second edition of the books hits the shelves today. Published by Apress, you can purchase it through Amazon.com. It has been updated to cover the coming release of Oracle Service Bus 10gR3 and covers the new features with tons of sample code. If you are interested in the Oracle Service Bus, or enterprise service buses in general, this book will help you better understand how to use a service bus in your environment to help your company save money by increasing agility.
The Emperor Has No Clothes
At least once a month I will write about the misconceptions or questionable perceptions that I see in the industry. This month's topic is speed.
I routinely meet people in the field that are convinced that, "speed is king". These are usually the same folks that are very concerned about the impact of web services and XML on the overall performance of their enterprise. A few weeks ago I was conducting a training session and I asked the audience if speed was the most important aspect of their software development. Fifty percent of the class raised their hands. The class was comprised of very senior developers and consultants in the SOA field. Even when I asked the obviously leading question, "So there is nothing more important than execution speed?" the hands remained up. This is a common perception and I attribute the fact that only 50% of the class thought speed was the #1 concern to the fact that they were so senior. With less experienced folks the percentage is much higher.
I argue that speed is not the #1 concern anymore. This is a legacy belief from the 60's and 70's. In those times, speed really was king! Enterprise systems were tiny compared to today's standards, often comprising a single mainframe computer. The computer users of that era were largely highly trained (or at least specialized) computer engineers. Reuse occurred at the subroutine level only. Change within the computing environment moved at a glacial pace when compared to today's rapid stream of change. In that era each CPU clock cycle had a dollar value assigned to it. If you didn't write fast code, it cost the company money and possibly the coder his job.
Fast-forward to today's computing environments. A medium-sized enterprise will have several hundred to a thousand servers in their data centers. Interfaces are created to allow comparatively unskilled users (i.e. non-software engineers) to get their work done remotely over a network. EAI and ETL work behind the scenes to enable federated systems to behave as one meta-computer.
If execution speed really was king, none of that would exist. Each enterprise would have a single, massively parallel computer that ran everything in a single, highly complex application. That single application would be written in native assembly code.
It wasn't that many years ago that people thought Java was too slow to run enterprise software. I remember when the C language was considered to be slow by many software engineers. The same holds true for distributed computing. "Crossing the wire" was an expensive prospect, with regard to time.
The pure fact is that speed is not king. We went to smaller, cheaper computers in a distributed environment because money is the real king. We are moving to SOA because re-use helps to save money. We are moving to SOA because interoperability saves money. We are moving to SOA because tightly integrated environments may be fast, but they surely are not agile. The business cannot wait for a year or more while IT reconfigures the software systems to better support the needs of the business. Marketing opportunities will come and pass during that time, costing the company money in lost sales opportunities
Modern businesses demand an IT organization that is highly responsive and cost effective. The trend of doing more work with less resources is nothing new in this world. In fact, the original mainframes offered the same benefit: more work for less money. The trend will continue into the foreseeable future. We, as IT professionals must continue to adapt to this pressure.
Ask the Experts
Because I co-authored a book on SOA and the Oracle Service Bus, people often assume that I am an expert in every detail of the product. That is simply untrue. I am fortunate to be surrounded by experts here at Oracle and I make liberal use of their expertise. As a result of my unique position here, I am able to comb through both the internal and external questions from the field, looking for interesting questions to share with you.
In this installment, the question is about the aggregation interval settings and how they are used by the Oracle Service Bus. On a legal note, I do reserve the right to modify the format and the content of all questions before I post them here.
Please teach me about the sample interval in the aggregation Intervals.
In the following document says that statistics are recomputed by the sample interval.
Statistics are recomputed at regular intervals known as the sample interval.
According to my research, the sample interval is valid only when the alert rule is evaluated.
In the following document it says that the statistic are recomputed every minute.
I think that the sample interval influences only the aggregation interval in alert rule. Is this right?
Here's how they relate together.
Statistics are reported either since last reset or for a particular aggregation interval. Aggregation interval is a moving window of time. However it moves in discrete steps called sample interval. Each aggregation interval has a different sample interval, e.g., if ai=5, then si=1, if ai=4 hours si=1 hour.
You can obtain the value of a particular statistic for the aggregation interval defined for the service any time. However it will only be accurate if you obtain it to coincide with its sample interval. For example suppose the aggregation interval for a service is 15 minutes. This means its sample interval is 5 minutes. Let's assume you obtain (query) the values of the statistics at 10:23 am. The statistical values you obtain will not represent the last 15 minutes (i.e., since 10:13). Rather, they will be derived from the data collected in the last 18 minutes (i.e., since 10:05 am.) and interpolated to approximate 15-minute value. Therefore the accurate values are only available at minutes/hours that are multiples of the sample interval associated with the aggregation interval.
Since values are only accurate on sample interval boundaries, an alert is evaluated only at the sample interval associated with its own aggregation interval. An alert with ai=5 is evaluated every minute, but an alert with an ai of 4 hours is evaluated every hour.
There is a separate "aggregation" processes which has nothing to do with the aggregation intervals. This aggregation process gathers statistics every minute from all members of the cluster and adds them up to construct the clusterwide statistical values.
Hope this helps.
Many thanks to Tolga Urhan for this information.
Thanks for Reading!
I promise to keep this blog insightful, critical and useful! If you have any questions, you can always reach me at firstname.lastname@example.org. Until next time...