I saw a news article today talking about a judge who banned "intelligent design" in school curriculums:
http://today.reuters.com/news/newsarticle.aspx?type=topNews&storyid=2005-12-20T164925Z_01_EIC059334_RTRUKOC_0_US-LIFE-EVOLUTION.xml
It seems there are zealots on both sides of this argument who think their way is the only correct way. Well, I am going to end it once and for all on this blog. Here is the solution for the final end to this controversy in three easy steps:
1. Draft a MoU between both groups issuing an edict that "god created evolution". This dovetails nicely into both points of view without offending anyone.
2. Both sides need to note that this theory ties up all the loose ends and explains everything. No one need be upset anymore.
3. Let individuals believe what they want, keep religion out of schools and government and move on to more important problems to solve.
To offer more help, I have made this partial list of problems that these people can turn their attention to now that the religious debate over the origins of human life is officially over.
Problems that we need to solve:
1. Getting our fellow humans to be nicer to each other.
2. Ending the conflicts in various regions around the world.
3. Figuring out a good way to provide cheap, non-polluting, sustainable energy to the masses of the planet.
4. Showing compassion for our fellow man when he is in times of need.
5. (add your own here...)
Move along - nothing to see here anymore....
Tuesday, December 20, 2005
Monday, December 12, 2005
Bio-mass: Sustainable Energy?
My Great Cousin Stig Nickull is the managing director at the world's largest (and most efficient) biomass energy conversion plant in Finland. The plant is in Pietarsaari and was specially designed to convert biomass fuel sources into electrical energy.
http://www.tekes.fi/opet/pdf/Alholma_2002.pdf
I write about this for two reasons. First and foremost, I am very proud of the heritage of my family and their contributions to the world. Stig is a brilliant scientist and seems to be causing positive change in the world. Imagine energy being freed from materials currently deemed garbage at an almost zero pollution factor? He has done it. We could definitely use this model in Canada since we have an abundance of wood chips, waste products etc.
The second is due to Carmen's comments about my hydrogen bashing on the previous blog entry:
http://technoracle.blogspot.com/2005/12/hydrogen-again-tweedle-dumb-and.html
Carmen points out that we need to change our thinking on this planet. She points out that these poor decisions are causing more problems and I agree. Politicians - try thinking - it doesn't hurt!!!!!
When evaluating alternative energy, please always question the Why, What, How and make sure you use the equation I wrote on the Hydrogen blog entry. We have to start thinking of solutions in terms of NET energy savings.
Peace to all!!
http://www.tekes.fi/opet/pdf/Alholma_2002.pdf
I write about this for two reasons. First and foremost, I am very proud of the heritage of my family and their contributions to the world. Stig is a brilliant scientist and seems to be causing positive change in the world. Imagine energy being freed from materials currently deemed garbage at an almost zero pollution factor? He has done it. We could definitely use this model in Canada since we have an abundance of wood chips, waste products etc.
The second is due to Carmen's comments about my hydrogen bashing on the previous blog entry:
http://technoracle.blogspot.com/2005/12/hydrogen-again-tweedle-dumb-and.html
Carmen points out that we need to change our thinking on this planet. She points out that these poor decisions are causing more problems and I agree. Politicians - try thinking - it doesn't hurt!!!!!
When evaluating alternative energy, please always question the Why, What, How and make sure you use the equation I wrote on the Hydrogen blog entry. We have to start thinking of solutions in terms of NET energy savings.
Peace to all!!
Tuesday, December 06, 2005
Hydrogen again - Tweedle Dumb and Tweedle Dumber!
I saw an article on truckers deciding to adopt hydrogen. As reported on Slashdot,
hipernoico writes to tell us Wired News is reporting that hundreds of semi trucks now on the roads are being partially powered by hydrogen. From the article: "These 18-wheelers make hydrogen as they go, eliminating the need for high-pressure, cryogenic storage tanks or hydrogen filling stations, which, by the way, don't yet exist. These truckers aren't just do-gooders. They like Canadian Hydrogen Energy's Hydrogen Fuel Injection, or HFI, system because it lets them save fuel, get more horsepower and, as a bonus, cause less pollution."
http://science.slashdot.org/article.pl?sid=05/11/15/2314241&from=rss
Let’s be straight about this. Using Hydrogen as a terrestrial fuel carrier is very stupid. The mathematics do not add up nor do the IQ points of those who continue to propose this for mainstream use. Any student who has passed Physics 101 knows this is true yet the dreamers seem to persist in disillusioning the masses about the benefits of using hydrogen.
The first rule of physics is that energy can be neither created nor destroyed. Energy may be converted from one form to another. A good fuel source for terrestrial use is one that occurs in abundance naturally, is easy to harvest, store and distribute and also converts cleanly with minimal impact on our environment. Coal, wood, oil all match some of this criteria. For example, wood is very abundant on our planet. It grows by converting the sun’s energy into biomass that may be easily harvested and transported then subsequently burned to release thermal energy. Thermal energy can be converted into kinetic energy very easily.
As with everything on this blog, do not take this for granted. Question it and do your own research.
So why is hydrogen as a fuel source for terrestrial application a bad idea? Let examine some facts and what hydrogen’s role is.
In most hydrogen powered vehicle scenarios, Hydrogen essentially acts as a battery or transporter of energy. It exists to store energy to allow it to be mobile. Similar to how recharge-able batteries work, it takes energy to produce hydrogen pure enough to be useful as a power source. At the target, the hydrogen’s stored energy is essentially converted to electrical energy, although it may also be converted to thermal energy which may be more efficient to convert to kinetic energy.
Hydrogen is highly unstable as a gas and does not readily occur in nature. Unlike hydrocarbons, which are relatively stable compounds, hydrogen will do everything it can dissipate or change state if released into the atmosphere of our little green planet. As such, pure hydrogen is extremely rare on this planet. Even if you found a reserve of hydrogen, you would still need to harvest and transport it to distribution centre’s which in itself may take more energy than the hydrogen you harvested had in it.
Let’s look at the pattern.
1. A natural process leaves energy stored in a manner that is easily harvested by human actors. Examples – the energy of the sun creates wind patterns on the surface of the planet which may be harvested by windmills or solar energy is converted via photoelectric arrays into electrical energy.
2. The energy is distributed in some form. Example - a power grid distributes electricity via wires or it may be used to charge a battery which may be transported physically to the site.
3. The energy is consumed. In reality – it is simply converted into some other form since energy can neither be created nor destroyed.
To make this work, the energy used to retrieve and initially convert the energy from its natural state (rE) plus the energy to refine, store, transport and distribute the energy to the point of consumption (tKw) must be less than the energy retrieved in step 3 when the energy is consumed (nKw). If rE + tKw > nKw, the process is a net waste of energy and this is before you consider the energy used to create the specialized mechanisms to consume an energy transport medium like hydrogen. Remember, fuel cells take more energy to design, manufacture, test and integrate into industry.
In general, we should not even consider anything less than a situation where
Hydrogen is not dense enough in a gaseous state to even contain enough energy to overcome the energy required to create, purify, store and transport it. Hydrogen as a terrestrial carrier of energy is a very dumb idea.
hipernoico writes to tell us Wired News is reporting that hundreds of semi trucks now on the roads are being partially powered by hydrogen. From the article: "These 18-wheelers make hydrogen as they go, eliminating the need for high-pressure, cryogenic storage tanks or hydrogen filling stations, which, by the way, don't yet exist. These truckers aren't just do-gooders. They like Canadian Hydrogen Energy's Hydrogen Fuel Injection, or HFI, system because it lets them save fuel, get more horsepower and, as a bonus, cause less pollution."
http://science.slashdot.org/article.pl?sid=05/11/15/2314241&from=rss
Let’s be straight about this. Using Hydrogen as a terrestrial fuel carrier is very stupid. The mathematics do not add up nor do the IQ points of those who continue to propose this for mainstream use. Any student who has passed Physics 101 knows this is true yet the dreamers seem to persist in disillusioning the masses about the benefits of using hydrogen.
The first rule of physics is that energy can be neither created nor destroyed. Energy may be converted from one form to another. A good fuel source for terrestrial use is one that occurs in abundance naturally, is easy to harvest, store and distribute and also converts cleanly with minimal impact on our environment. Coal, wood, oil all match some of this criteria. For example, wood is very abundant on our planet. It grows by converting the sun’s energy into biomass that may be easily harvested and transported then subsequently burned to release thermal energy. Thermal energy can be converted into kinetic energy very easily.
As with everything on this blog, do not take this for granted. Question it and do your own research.
So why is hydrogen as a fuel source for terrestrial application a bad idea? Let examine some facts and what hydrogen’s role is.
In most hydrogen powered vehicle scenarios, Hydrogen essentially acts as a battery or transporter of energy. It exists to store energy to allow it to be mobile. Similar to how recharge-able batteries work, it takes energy to produce hydrogen pure enough to be useful as a power source. At the target, the hydrogen’s stored energy is essentially converted to electrical energy, although it may also be converted to thermal energy which may be more efficient to convert to kinetic energy.
Hydrogen is highly unstable as a gas and does not readily occur in nature. Unlike hydrocarbons, which are relatively stable compounds, hydrogen will do everything it can dissipate or change state if released into the atmosphere of our little green planet. As such, pure hydrogen is extremely rare on this planet. Even if you found a reserve of hydrogen, you would still need to harvest and transport it to distribution centre’s which in itself may take more energy than the hydrogen you harvested had in it.
Let’s look at the pattern.
1. A natural process leaves energy stored in a manner that is easily harvested by human actors. Examples – the energy of the sun creates wind patterns on the surface of the planet which may be harvested by windmills or solar energy is converted via photoelectric arrays into electrical energy.
2. The energy is distributed in some form. Example - a power grid distributes electricity via wires or it may be used to charge a battery which may be transported physically to the site.
3. The energy is consumed. In reality – it is simply converted into some other form since energy can neither be created nor destroyed.
To make this work, the energy used to retrieve and initially convert the energy from its natural state (rE) plus the energy to refine, store, transport and distribute the energy to the point of consumption (tKw) must be less than the energy retrieved in step 3 when the energy is consumed (nKw). If rE + tKw > nKw, the process is a net waste of energy and this is before you consider the energy used to create the specialized mechanisms to consume an energy transport medium like hydrogen. Remember, fuel cells take more energy to design, manufacture, test and integrate into industry.
In general, we should not even consider anything less than a situation where
Hydrogen is not dense enough in a gaseous state to even contain enough energy to overcome the energy required to create, purify, store and transport it. Hydrogen as a terrestrial carrier of energy is a very dumb idea.
Monday, November 28, 2005
Introducing Serena!
My second daughter was born Friday November 18 at 18:39 Pacific time. At birth she weighed in at 4.3 Kg (about 9 lbs, 5 ounces for those of you who keep the metric system supressed). Here she is at home a week later being held by her big sister Bianca. I am the luckiest man in the world - what can I say!
A photo of two angels...
A photo of two angels...
Friday, November 11, 2005
What is meant by “Service Opacity” and “Managed Transparency”?
Okay – so you all know about Service Oriented Architecture (SOA) and have your ideas of what it is. While we all are likely to disagree with the finer points of SOA, most will agree on a few core tenets of SOA. If you want to discuss this with me, the standard contribution of a vintage Bordeaux applies.
Core to SOA is the existence of services as autonomous entities that act as a boundary between some “functionality” and the entity that consumes that functionality via the service. Service implementers should take care to design services as opaque as possible. This means that as a service consumer, you should talk to the service, but not really care about how the service implements the functionality it provides. This Black Box aspect of SOA is really a specialized notion of the definition of software architecture in the great green book “Documenting Software Architectures: Views and Beyond” by Clements, Bachman et al. In this book, software architecture is defined as “the structure or structures of the system, which consist of elements and their externally visible properties, and the relationships among them”. The key words here are “externally visible properties”. A service provider adhering to this basic axiom should strive to only reveal externally visible properties that are critical for the consumer to know, but no more.
Critique: That is a broad statement. Why? As with anything in technology, don’t run out and do it just because I said so. Question everything. Critique this if you don’t agree.
Rationale: Services provide a healthy abstraction between functionality and those using the functionality. By not revealing the specific implementation behind the service, no consumer of that service has to create a tighter integration than necessary. This frees the service provider to implement, maintain, replace or update the functionality behind the service with the least amount of concern for dependencies from consumers. As long as the replacement, update still supports the existing service interface, the consumer will not notice changes. Please note that I qualified my statement with “than necessary” – the exact level of this is specific to each implementation and it is unlikely anyone could create a hard and fast rule for this.
Specific details of how the service is fulfilling its’ functions are generally not relevant to the consumer either. One should not make assumptions about specific interactions that may happen behind the service and only stick to the externally visible real world effect (RWE). A service is a black box with an interface. As long as the interface allows you to do what you want, you shall be happy. Like this blog, all you need to know is that you enter a URI into the location window of your browser and you get this content back, formatted in HTML. You should not care whether or not this is static text residing on an Apache server or if I just typed into a blackberry really fast to give you this real time.
Example:
Some people have advocated that a service must provide a guarantee of delivery assurances between the service itself and the ultimate (application) destination. This delivery assurance effectively suggest that a service must deliver messages it receives to another destination, possibly with additional guarantees for “in order” and “eliminate duplicates” amongst other functions. I strongly disagree with this for a number of reasons. Is this really an externally visible property of a service we should expose? Perhaps in some cases it can be justified but I have trouble making any normative statements for such that apply to all cases. A functionality similar to this may be a higher level matter which I will try to explain at the end of my rant below.
Rant:
First, even specifying in a standard or protocol that there is an “application destination” behind a service is errant since it implies a specific model for infrastructure to be implemented behind the service interface. If this were accepted within the standard, does it imply that all implementations must now have a specific architecture where nothing can be processed locally on the service?
Secondly, assuming you are going to send a sequence of six messages to a specific service and invoke a delivery assurance/guarantee that all messages in that sequence are delivered “in order”, this now implies a cardinality of 1:1 between a service and the “thing” that must process the messages. Does this disallow the service itself to process part of the message?
Third, this model constrains implementers from dividing up an incoming message to distribute it to several processing classes or applications. The mechanism as it stands today essentially requires a sequence number for each incoming message which must monotonically increase by a factor of one. The intentions are that the service will forward incoming messages to the application destination in the same order it received them in. A cardinality of 1:1 is sub-optimal for scaling IMO. What about pooling? Does this count as one application or several? And why should the service consumer care about this?
The UML model above captures the implied infrastructure. It implies that all incoming messages in a sequence flagged with “in order” delivery MUST be forwarded intact as whole units to one application destination. Why should an implementer not be able to forward messages 1 and 3 to one application destination and messages 4 and 6 to another then simply coordinate those activities to ensure they are “processed” in order? Is the following second diagram below illegal if a guarantee of “in order” delivery is requested? Note that in the following diagram, I have replaced Service.forward() with Service.coordinateProcessing() since this is really what the service consumer is after. After all, even if messages *are* delivered “in order”, there is no guarantee that they have been processed in order.
Note: Please excuse my poor UML style of multiple ApplicationDestination classes but I felt compelled to depict it this way to illustrate the splitting of various messages to different endpoints.
An operation such as “forward()” (from the first diagram) should not be a mandatory externally visible property of a service. It implies a specific model for implementing a service and any specifications that deal with service interoperability should not try to impose specific implementation styles on service providers. My argument does not mean that implementers cannot do this if they see fit or determine that it is necessary, but this is not a one size shoe that should force all to fit within.
A higher level look at the goal.
The real goal is to allow a service consumer to flag that a sequence of messages are meant to be “processed sequentially”. It should not care how that is done, just that this is done or, in the alternative, the service generates a fault. What mechanisms do we need to do this?
1. We need to ensure that the message on the wire between the service consumer and the service carries with it all the tokens to enable the service to understand what type of serial/cardinal processing assurances it requires.
2. We also need a messaging mechanism that allows a service to reassemble the complete stream representing the message in a deterministic manner matching the stream exactly as it was when it left the service consumer.
3. Another requirement is that services must have some form of service description that allows them to declare what their exact capabilities are WRT serial processing of multiple calls.
Does it look something like this?
Note that the cardinality between Service and ApplicationDestination is “any”. It is possible that a service may simply process an invocation request locally. Not all attributes and operations have been explicitly called out to avoid confusion but hopefully this will give you the idea.
Conclusion:
Managed transparency should be a core consideration of a service provider. Services should remain as opaque as possible but may need to expose some aspects of their operations to facilitate their use but consumers. Those implementing services must take both of these into account lest we risk building a world wide network of interdependent, tightly bound applications – the very thing that SOA is attempting to save us of.
What do you think?
Core to SOA is the existence of services as autonomous entities that act as a boundary between some “functionality” and the entity that consumes that functionality via the service. Service implementers should take care to design services as opaque as possible. This means that as a service consumer, you should talk to the service, but not really care about how the service implements the functionality it provides. This Black Box aspect of SOA is really a specialized notion of the definition of software architecture in the great green book “Documenting Software Architectures: Views and Beyond” by Clements, Bachman et al. In this book, software architecture is defined as “the structure or structures of the system, which consist of elements and their externally visible properties, and the relationships among them”. The key words here are “externally visible properties”. A service provider adhering to this basic axiom should strive to only reveal externally visible properties that are critical for the consumer to know, but no more.
Critique: That is a broad statement. Why? As with anything in technology, don’t run out and do it just because I said so. Question everything. Critique this if you don’t agree.
Rationale: Services provide a healthy abstraction between functionality and those using the functionality. By not revealing the specific implementation behind the service, no consumer of that service has to create a tighter integration than necessary. This frees the service provider to implement, maintain, replace or update the functionality behind the service with the least amount of concern for dependencies from consumers. As long as the replacement, update still supports the existing service interface, the consumer will not notice changes. Please note that I qualified my statement with “than necessary” – the exact level of this is specific to each implementation and it is unlikely anyone could create a hard and fast rule for this.
Specific details of how the service is fulfilling its’ functions are generally not relevant to the consumer either. One should not make assumptions about specific interactions that may happen behind the service and only stick to the externally visible real world effect (RWE). A service is a black box with an interface. As long as the interface allows you to do what you want, you shall be happy. Like this blog, all you need to know is that you enter a URI into the location window of your browser and you get this content back, formatted in HTML. You should not care whether or not this is static text residing on an Apache server or if I just typed into a blackberry really fast to give you this real time.
Example:
Some people have advocated that a service must provide a guarantee of delivery assurances between the service itself and the ultimate (application) destination. This delivery assurance effectively suggest that a service must deliver messages it receives to another destination, possibly with additional guarantees for “in order” and “eliminate duplicates” amongst other functions. I strongly disagree with this for a number of reasons. Is this really an externally visible property of a service we should expose? Perhaps in some cases it can be justified but I have trouble making any normative statements for such that apply to all cases. A functionality similar to this may be a higher level matter which I will try to explain at the end of my rant below.
Rant:
First, even specifying in a standard or protocol that there is an “application destination” behind a service is errant since it implies a specific model for infrastructure to be implemented behind the service interface. If this were accepted within the standard, does it imply that all implementations must now have a specific architecture where nothing can be processed locally on the service?
Secondly, assuming you are going to send a sequence of six messages to a specific service and invoke a delivery assurance/guarantee that all messages in that sequence are delivered “in order”, this now implies a cardinality of 1:1 between a service and the “thing” that must process the messages. Does this disallow the service itself to process part of the message?
Third, this model constrains implementers from dividing up an incoming message to distribute it to several processing classes or applications. The mechanism as it stands today essentially requires a sequence number for each incoming message which must monotonically increase by a factor of one. The intentions are that the service will forward incoming messages to the application destination in the same order it received them in. A cardinality of 1:1 is sub-optimal for scaling IMO. What about pooling? Does this count as one application or several? And why should the service consumer care about this?
The UML model above captures the implied infrastructure. It implies that all incoming messages in a sequence flagged with “in order” delivery MUST be forwarded intact as whole units to one application destination. Why should an implementer not be able to forward messages 1 and 3 to one application destination and messages 4 and 6 to another then simply coordinate those activities to ensure they are “processed” in order? Is the following second diagram below illegal if a guarantee of “in order” delivery is requested? Note that in the following diagram, I have replaced Service.forward() with Service.coordinateProcessing() since this is really what the service consumer is after. After all, even if messages *are* delivered “in order”, there is no guarantee that they have been processed in order.
Note: Please excuse my poor UML style of multiple ApplicationDestination classes but I felt compelled to depict it this way to illustrate the splitting of various messages to different endpoints.
An operation such as “forward()” (from the first diagram) should not be a mandatory externally visible property of a service. It implies a specific model for implementing a service and any specifications that deal with service interoperability should not try to impose specific implementation styles on service providers. My argument does not mean that implementers cannot do this if they see fit or determine that it is necessary, but this is not a one size shoe that should force all to fit within.
A higher level look at the goal.
The real goal is to allow a service consumer to flag that a sequence of messages are meant to be “processed sequentially”. It should not care how that is done, just that this is done or, in the alternative, the service generates a fault. What mechanisms do we need to do this?
1. We need to ensure that the message on the wire between the service consumer and the service carries with it all the tokens to enable the service to understand what type of serial/cardinal processing assurances it requires.
2. We also need a messaging mechanism that allows a service to reassemble the complete stream representing the message in a deterministic manner matching the stream exactly as it was when it left the service consumer.
3. Another requirement is that services must have some form of service description that allows them to declare what their exact capabilities are WRT serial processing of multiple calls.
Does it look something like this?
Note that the cardinality between Service and ApplicationDestination is “any”. It is possible that a service may simply process an invocation request locally. Not all attributes and operations have been explicitly called out to avoid confusion but hopefully this will give you the idea.
Conclusion:
Managed transparency should be a core consideration of a service provider. Services should remain as opaque as possible but may need to expose some aspects of their operations to facilitate their use but consumers. Those implementing services must take both of these into account lest we risk building a world wide network of interdependent, tightly bound applications – the very thing that SOA is attempting to save us of.
What do you think?
Wednesday, November 09, 2005
Any minute now...
Yes - my wife is *very* pregnant. We are due to give birth any second. Since I have been innundated with requests for photos, I decided to make a short blog entry to illustrate exactly why I am the luckiest man alive. Our official due date is November 11th (two days from now).
It is hard to believe Bianca is now 2 and a half years old. Time flies.
Monday, November 07, 2005
Anti-patterns for SOA: Part Two
Three general rules for service granularity and redundancy
I recently made a blog entry about “anti-patterns” for SOA. This is funny since I never took the time to define either "SOA" or “anti-patterns” at the beginning of the blog which lead to almost everyone reading it walking away with a different opinion. I say funny because I am the sort of person who finds that type of thing amusing ;-)
Okay – seriously, before I continue, I would like to put some definitions around both of these. For SOA, I will rely on the OASIS Service Oriented Architecture Reference Model Technical Committee’s work to develop a Reference Model for SOA. While only an editors’ draft at this time, the basic premise is that SOA is an architectural paradigm or simply stated – a way of viewing/doing things that center’s around the concept of a service. Revision 10 is coming out soon.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
SOA definitions are like a tush. Everyone has one. Anti-pattern definitions are similar. To lexically scope the rest of this blog, I will rely on the following definition introduced by Hayes McCormick, a lead engineer from Mitre:
“Anti patterns are negative patterns that present more problems that they produce”
http://www.antipatterns.com/briefing/sld003.htm
Hays also compares various types of anti-patterns. In IT, anti pattern examples may be the god class ( one large class that does everything), spaghetti code (procedural and un-ordered/unstructured), Design by Committee (always problematic) and those of you who use vi instead of emacs or pico (miscreants – you know who you are!!). Social anti-patterns include terrorism, pyromania, drug abuse and those or you who use vi instead or emacs of pico.
Rule 1: Granularity is in the eye of the beholder.
The question of service granularity seems to be a pervasive and confusing topic. Someone recently told me that an SOA with ten million services is probably a bad practice since it has too large a number of services and hence is hard to manage. I argued that number of services as a sole metric for whether or not SOA is implemented correctly is not a good metric given that it is subjective to the eye of the beholder. The point is that the rationalization for these things is not always obvious to the viewer.
Case in point? How about the Internet. The internet has over ten million individual services yet each of those services have a unique and valid function, at least to the owners of the content and those wishing to retrieve it. So look at this in terms of granularity. Should clusters of those services be bundled together? No. You are reading this blog which aggregates a few things (my posts plus thousands of comments calling for my banishment for heresy), however I will argue that IMO this blog should remain its’ own service.
If someone also owned a distributed grid computing network, they may wish to allow consumers to make leases to individual nodes via services. This means that each node in the cluster would have at least one service. The alternative is to implement an uber-service that then locates and leases the appropriate node on the cluster on behalf of the consumer and forces the consumer to remain agnostic with respect to the physical contract to the cluster node. So which is valid? Well, both. There are advantages to doing it each way.
So how far could you take the granularity/number of services concept before it becomes a legitimate anti-pattern? In J2EE many have made assertions about patterns and anti-patterns. The issue of granularity is measured by java programmers in terms of what they deem efficient or justifiable based on expected overhead. Puneet M. Sangal wrote:
“Accessing Fine-grained EJB Interfaces
Marshaling and unmarshalling data involved in a remote call across the network can cause major time latency in applications. Latency can also occur due to multiple remote calls. Based on the needs on the application, the solution might involve redesigning the EJBs, but if that's not the case, servlets should not remotely access an EJB entity via a fine-grained API. If the EJB's expose both fine and coarse-grained APIs then servlets should use single calls to the coarse-grained API in preference to making multiple calls to the fine-grained methods.”
Is this view justified? IMO, it gives us hints about some concepts upon which to base our decisions.
Convoluted SOA Contest Winning Idea?
Let’s take this to an extreme case. Imagine you wanted to render a raster graphic of some new platform. Let’s assume that the native format for the graphic returned a large hash of pixel values in Hex format. I will use text to make this easy to understand:
1, 1, #C0C0FF //pixel located at quadrant 1 from top, 1 from left, color is Hex #C0C0FF
1, 2, #C0C0C0
1, 3, #FFFFFF
Etc.
Now imagine that each pixel’s value had to be parameterized to web service call that would return the Hex value in RGB values. We can make this more granular by forcing the consumer to call a different service for each Hex value. Accordingly, the service endpoints would be http://www.domain-example.com:port/[hex_value]/ws
If you sent in #FFFFFF, the response would be rgb(255,255,255) which would render white. It is possible to make rendering software for your new raster graphic format make one service call for each pixel in the image.
I probably don’t have to tell you that this is a bad idea. It is very black and white (no irony intended) however there are other examples that are less ambiguous.
Rule 2: It is probably not possible to write a rule for granularity that is applicable to all situations.
For the record, the preceding idea was not original, it is merely a new twist on an old ploy to make a picture using an HTML table with hundreds of rows and columns, each having its’ own background color. Collectively, the table cells being rendered in an HTML client application would look like a picture. Hey – maybe we could produce that table by linking up the results of all the service calls……? Somebody shoot me now!!
In the preceding case, it would have made sense to call a single service that returned a large lookup table for all values, then simply iterate each Hex value against that for the corresponding value locally. My gut instinct would have been to architect it this way, but others may object (for various and perhaps legitimate reasons).
There are several questions that I will pose to you on this subject, interspersed with my answers. YAMMV (Your actual mileage may vary):
1. Should service calls be used in places where the overhead of incurring them exceeds the resources required to enable the functionality locally?
[Duane]: My gut reaction is that this is a consideration but will not always be the largest factor in the equation.
2. Would it be prudent to state that the call to the service should be coded in less lines that it would take to reproduce the functionality locally. For example, making a call to multiply two numbers together may take 25 lines of code in Java, including wrapping it in a “try/catch” construct. Doesn’t it always make more sense to simply write:
…
int var1;
int var2;
int result;
try {
result = var1 * var2;
}
catch (Exception e) {
//do something with error here…
}
…
[Duane]: Many programmers will probably not make remote calls for simple functions they can easily write. I am not sure if any rule can be made from this.
3. Is there any chance that “catch all” rules can be made to determine whether or not services are too granular? Consider the fact that some programming languages allow for sentences to be of type “String” and also allow them to be treated as an array of chars.
[Duane]: I do not believe this will be possible given we all tend to look at problems form different aspects.
4. If any of these rules are violated, is the thing still SOA?
[Duane]: SOA is SOA, whether good or bad design.
All of this is dependent upon your own views and principles.
I started thinking about this in terms of how other related efforts handle this. The first thing that struck me is the use of inheritance in object oriented programming has a strong effect on whether or not you use a local method or make a remote call. For example, imagine the following example as a class hierarchy.
If you need to do a multiplication operation on two or more integers, you would logically use the Calculus class. If you are writing a new class, you would import the Calculus class then call the multiply() method and feed it parameters. This would return a result. Importing the class gives you access to all the methods that class has.
It would be highly illogical to make a remote procedure call to another class for some functionality your imported class already possesses such as the multiply() method.
You will notice that in the hierarchy I established above, there are two methods on the language side that are very similar – WriteBookReport() in the English Literature class and writeReport() in the Grammar class. This illustrates another problem that exists within SOA – the number of similar or overlapping services. This has also been raised as a possible anti-pattern of SOA by a number of people.
In this case, the designer of the overall programming language would have the ability to re-architect the class hierarchy to form a more generic operation that may be called “writeReport()” and take a parameter of reportType (which might have a value of “book report” in certain instances).
This often has not been addressed within the context of SOA. class hierarchies are commonplace in every modern language. Service classification hierarchies are not as common. This may be an interesting thing to look at.
Conceptually, it the writeReport() operation the same as the writeBookReport() operation? This depends upon your perspective on the problem and the granularity of which you examine the operation.
A simple table with some generic aspects highlighted seems to indicate that the two operations are the same:
The two operations seem pretty similar from this perspective. Of course, when you examine other aspects, this starts to fall apart.
Okay – so this example was a little daft. Let’s look at a more relevant issue. Is an HTTP get() different from an HTTP post()? The patterns are both the same. You marshall a message into text and route it over the internet using an established protocol. It reaches a service which then evaluates the message and forms a response message which is then routed back to the sender. They both do this. So do the HTTP put(), delete() and other operations. Where they differ in functionality is not at the wire level, it is at the conceptual or real world effect level. This is an important consideration for SOA. What is the real world effect of invoking the service.
Rule 3: Duplication of Services is in the eye of the beholder.
Conclusion:
Alongside the issue of service granularity, we have a similar issue of duplication of services. Both of these issues are probably beyond some form of an immediate “best practices” guide that is applicable in all situations.
What do you think?
I recently made a blog entry about “anti-patterns” for SOA. This is funny since I never took the time to define either "SOA" or “anti-patterns” at the beginning of the blog which lead to almost everyone reading it walking away with a different opinion. I say funny because I am the sort of person who finds that type of thing amusing ;-)
Okay – seriously, before I continue, I would like to put some definitions around both of these. For SOA, I will rely on the OASIS Service Oriented Architecture Reference Model Technical Committee’s work to develop a Reference Model for SOA. While only an editors’ draft at this time, the basic premise is that SOA is an architectural paradigm or simply stated – a way of viewing/doing things that center’s around the concept of a service. Revision 10 is coming out soon.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
SOA definitions are like a tush. Everyone has one. Anti-pattern definitions are similar. To lexically scope the rest of this blog, I will rely on the following definition introduced by Hayes McCormick, a lead engineer from Mitre:
“Anti patterns are negative patterns that present more problems that they produce”
http://www.antipatterns.com/briefing/sld003.htm
Hays also compares various types of anti-patterns. In IT, anti pattern examples may be the god class ( one large class that does everything), spaghetti code (procedural and un-ordered/unstructured), Design by Committee (always problematic) and those of you who use vi instead of emacs or pico (miscreants – you know who you are!!). Social anti-patterns include terrorism, pyromania, drug abuse and those or you who use vi instead or emacs of pico.
Rule 1: Granularity is in the eye of the beholder.
The question of service granularity seems to be a pervasive and confusing topic. Someone recently told me that an SOA with ten million services is probably a bad practice since it has too large a number of services and hence is hard to manage. I argued that number of services as a sole metric for whether or not SOA is implemented correctly is not a good metric given that it is subjective to the eye of the beholder. The point is that the rationalization for these things is not always obvious to the viewer.
Case in point? How about the Internet. The internet has over ten million individual services yet each of those services have a unique and valid function, at least to the owners of the content and those wishing to retrieve it. So look at this in terms of granularity. Should clusters of those services be bundled together? No. You are reading this blog which aggregates a few things (my posts plus thousands of comments calling for my banishment for heresy), however I will argue that IMO this blog should remain its’ own service.
If someone also owned a distributed grid computing network, they may wish to allow consumers to make leases to individual nodes via services. This means that each node in the cluster would have at least one service. The alternative is to implement an uber-service that then locates and leases the appropriate node on the cluster on behalf of the consumer and forces the consumer to remain agnostic with respect to the physical contract to the cluster node. So which is valid? Well, both. There are advantages to doing it each way.
So how far could you take the granularity/number of services concept before it becomes a legitimate anti-pattern? In J2EE many have made assertions about patterns and anti-patterns. The issue of granularity is measured by java programmers in terms of what they deem efficient or justifiable based on expected overhead. Puneet M. Sangal wrote:
“Accessing Fine-grained EJB Interfaces
Marshaling and unmarshalling data involved in a remote call across the network can cause major time latency in applications. Latency can also occur due to multiple remote calls. Based on the needs on the application, the solution might involve redesigning the EJBs, but if that's not the case, servlets should not remotely access an EJB entity via a fine-grained API. If the EJB's expose both fine and coarse-grained APIs then servlets should use single calls to the coarse-grained API in preference to making multiple calls to the fine-grained methods.”
Is this view justified? IMO, it gives us hints about some concepts upon which to base our decisions.
Convoluted SOA Contest Winning Idea?
Let’s take this to an extreme case. Imagine you wanted to render a raster graphic of some new platform. Let’s assume that the native format for the graphic returned a large hash of pixel values in Hex format. I will use text to make this easy to understand:
1, 1, #C0C0FF //pixel located at quadrant 1 from top, 1 from left, color is Hex #C0C0FF
1, 2, #C0C0C0
1, 3, #FFFFFF
Etc.
Now imagine that each pixel’s value had to be parameterized to web service call that would return the Hex value in RGB values. We can make this more granular by forcing the consumer to call a different service for each Hex value. Accordingly, the service endpoints would be http://www.domain-example.com:port/[hex_value]/ws
If you sent in #FFFFFF, the response would be rgb(255,255,255) which would render white. It is possible to make rendering software for your new raster graphic format make one service call for each pixel in the image.
I probably don’t have to tell you that this is a bad idea. It is very black and white (no irony intended) however there are other examples that are less ambiguous.
Rule 2: It is probably not possible to write a rule for granularity that is applicable to all situations.
For the record, the preceding idea was not original, it is merely a new twist on an old ploy to make a picture using an HTML table with hundreds of rows and columns, each having its’ own background color. Collectively, the table cells being rendered in an HTML client application would look like a picture. Hey – maybe we could produce that table by linking up the results of all the service calls……? Somebody shoot me now!!
In the preceding case, it would have made sense to call a single service that returned a large lookup table for all values, then simply iterate each Hex value against that for the corresponding value locally. My gut instinct would have been to architect it this way, but others may object (for various and perhaps legitimate reasons).
There are several questions that I will pose to you on this subject, interspersed with my answers. YAMMV (Your actual mileage may vary):
1. Should service calls be used in places where the overhead of incurring them exceeds the resources required to enable the functionality locally?
[Duane]: My gut reaction is that this is a consideration but will not always be the largest factor in the equation.
2. Would it be prudent to state that the call to the service should be coded in less lines that it would take to reproduce the functionality locally. For example, making a call to multiply two numbers together may take 25 lines of code in Java, including wrapping it in a “try/catch” construct. Doesn’t it always make more sense to simply write:
…
int var1;
int var2;
int result;
try {
result = var1 * var2;
}
catch (Exception e) {
//do something with error here…
}
…
[Duane]: Many programmers will probably not make remote calls for simple functions they can easily write. I am not sure if any rule can be made from this.
3. Is there any chance that “catch all” rules can be made to determine whether or not services are too granular? Consider the fact that some programming languages allow for sentences to be of type “String” and also allow them to be treated as an array of chars.
[Duane]: I do not believe this will be possible given we all tend to look at problems form different aspects.
4. If any of these rules are violated, is the thing still SOA?
[Duane]: SOA is SOA, whether good or bad design.
All of this is dependent upon your own views and principles.
I started thinking about this in terms of how other related efforts handle this. The first thing that struck me is the use of inheritance in object oriented programming has a strong effect on whether or not you use a local method or make a remote call. For example, imagine the following example as a class hierarchy.
If you need to do a multiplication operation on two or more integers, you would logically use the Calculus class. If you are writing a new class, you would import the Calculus class then call the multiply() method and feed it parameters. This would return a result. Importing the class gives you access to all the methods that class has.
It would be highly illogical to make a remote procedure call to another class for some functionality your imported class already possesses such as the multiply() method.
You will notice that in the hierarchy I established above, there are two methods on the language side that are very similar – WriteBookReport() in the English Literature class and writeReport() in the Grammar class. This illustrates another problem that exists within SOA – the number of similar or overlapping services. This has also been raised as a possible anti-pattern of SOA by a number of people.
In this case, the designer of the overall programming language would have the ability to re-architect the class hierarchy to form a more generic operation that may be called “writeReport()” and take a parameter of reportType (which might have a value of “book report” in certain instances).
This often has not been addressed within the context of SOA. class hierarchies are commonplace in every modern language. Service classification hierarchies are not as common. This may be an interesting thing to look at.
Conceptually, it the writeReport() operation the same as the writeBookReport() operation? This depends upon your perspective on the problem and the granularity of which you examine the operation.
A simple table with some generic aspects highlighted seems to indicate that the two operations are the same:
The two operations seem pretty similar from this perspective. Of course, when you examine other aspects, this starts to fall apart.
Okay – so this example was a little daft. Let’s look at a more relevant issue. Is an HTTP get() different from an HTTP post()? The patterns are both the same. You marshall a message into text and route it over the internet using an established protocol. It reaches a service which then evaluates the message and forms a response message which is then routed back to the sender. They both do this. So do the HTTP put(), delete() and other operations. Where they differ in functionality is not at the wire level, it is at the conceptual or real world effect level. This is an important consideration for SOA. What is the real world effect of invoking the service.
Rule 3: Duplication of Services is in the eye of the beholder.
Conclusion:
Alongside the issue of service granularity, we have a similar issue of duplication of services. Both of these issues are probably beyond some form of an immediate “best practices” guide that is applicable in all situations.
What do you think?
Friday, November 04, 2005
Anti-patterns for SOA: Part One
This is a quick paper to explain some of the core tenets of SOA and illustrate a potentially unhealthy practice of trying to make functionality that exists behind a service interface visible to service consumers. Sadly, this practice seems to be growing in popularity lately which makes me question if people really understand why we are trying to move to SOA in the first place.
I came across this situation as editor of a requirements document for what may be a service oriented architecture for content management. In an early draft, I had copied what someone wrote:
"..a derived requirement that services would need to exist for Search, Read, Write, Copy, Move, Update, Merge, Version, Lock, Access Control Introspect type methods for content management. "
I received a comment back that stated :
“Content transformation – might be overloaded on copy… alternatively might want to be able to create complex transformation pipelines (splits, branches and merge…)“
It turns out that this insightful comment was extrenmely useful and lead to an epiphany. I now believe that the set should be shortened to only the following services:
Search – to locate a reference from which the content may be retrieved.
Read/Retrieve – essentially the ability to retrieve a copy of content.
Write – a method that would make subsequent retrieval of the content via a service possible. Note that I did not state „to write it to some persistent media“. This will be explained more later.
Update – a method to update content without over-writing an existing version. This assumes some form of version control.
Move – the ability to associate content with an additional URI, IRI or similar reference pointer. Note that I did not state „to migrate content from one persistent location to another“. That makes assumptions of some specific functionality or mechanism behind a service interface.
Lock – lock permissions for content so no one else can invoke the other methods.
Delete – make the content no longer reference able via the service interface. This does not necessarily imply removing the binary sequence that represents the content.
Access Control Introspect – inspecting the access control policies associated with content.
The following should not be core services, but should be optional:
Copy – essentially, this is akin to a combination of read and a subsequent write. This could optionally be implemented but should not be core since it is redundant.
Move – implies the ability to migrate content from one persistent location to another and is nothing more that a combination of retrieve, write and delete. Note that in some cases, content may not actually physically move, it may simply just have a different reference. Many operating systems work this way.
Merge – merge is really retrieval of two or more bits of content, a port-retrieval join and then an write() of a new aggregate content. It can also take place entirely behind the service interface by the creation of a method that will enable the end result of the merge to be retrieved from a service call. This does not mean that the content is actually merged – it is simply possible to get aggregated content.
So you are probably seeing a pattern by now. The core tenet is the externally visible properties or effects of invoking an action VS. the functionality that enables the end result. In SOA, one should not try to focus on the latter, the focus is brought to the service itself. The implementation is not relevant to the consumer.
Case in point. Microsoft engineers have engineered windows so via the user interface, it appears that you can move something from one location on a hard disk to another. But did it really move? No. In fact, in many cases, all you are really doing is changing the pointers which results in a change in the way the view is created for the user via the GUI. Those of you who have programmed in C and CPP will be familiar with this concept.
One service should probably be out of scope for the first phase of the project:
Transform – implying custom manipulations of content.
So why should the first group be core and transform be not in scope?
Rationale:
Services are autonomous and manage their transparency. A service should remain as opaque as possible to mitigate creating dependencies from those who invoke the service. When you make a service request, you enter parameters based on what you want. If for example, a blob of data exists in XML format (let’s call it FOO), and you desire a copy of it in HTML format, you should ask for it like this:
Please retrieve FOO for me in HTML format?
Or
get(FOO, html);
may represent a call to a java class. FOO in this case represents the thing you want and html may be an optional parameter to force the class to provide it in html rather than some default format.
When invoking this method, you should not care how the method gets you FOO in html format. It is not your job to question that. You only care about one thing. It either gives you FOO in html or it fails. Whether or not FOO.html was created by applying a complex transformation, aggregation or forced composition is irrelevant in most cases. Perhaps monkey’s banging out machine byte code randomly created it for you. It really doesn’t matter.
Bad Practice:
You should not be forced to ask for it in any manner that attempts to control processes behind the service interface like this:
“Please retrieve FOO for me and transform it from XML to HTML.”
The latter is bad architecture since it introduces unnecessary dependencies. When you ask for FOO in HTML format, you should not care whether or not it persists in HTML or some other format, only that you get what the interface promises you can retrieve.
The same principle applies for versioning and many other functions. Versions are merely parameters that can be entered into the server, but you should not specify how the functionality behind the service interface evaluates which one is the latest version or how it finds and serializes a specific version. All you need to know is that you either get the version you requested or a notice that the service failed.
Resolution:
There are multiple correct ways to architect a solution for allowing transformations. The first is based on the transformation happening behind the service interface. The service description can declare this is happening but should only do this if that information is necessary for the service consumer to know. Keep in mind that the Service Consumer cannot and should not see anything behind the service interface.
Example One – Good Practice:
Explanation:
The service consumer makes a call to the service and asks for a specific chunk of content in a specific format. In this case, it asks for FOO and specifies a parameter stating what format it wants foo in (HTML). The service takes the request, then retrieves a copy of FOO in xml format. Before passing it back to the service consumer, it calls an internal (and invisible to the service consumer) method to transform foo.xml into foo.html. It gets back the result then passes it back to the service consumer.
In this diagram, everything above the service consumer or below the service itself should be out of scope since there are no externally visible properties nor should assumptions be made about them. To introduce these dependencies would introduce unnecessary dependencies and assumptions and violate the core axioms of SOA.
Example Two – Good Practice
The second variation involves post–retrieval transformations and is also acceptable. Note that the patterns of interaction between service consumer and service provider are not broken.
In this case, the service is only capable of retrieving the FOO content in xml and passes the xml back to the service consumer. The service consumer subsequently transforms it to the HTML format.
In this scenario, the post retrieval use of the content is clearly out of scope for this particular SOA since it’s job is to facilitate the retrieval. There are an unlimited number of things that the user of the service consumer may do once it has retrieved the content. In Phase II, we MAY tackle a few of these however at present, all post retrieval uses should be out of scope until we have the core layer defined since there is a dependency on the base layer.
It should be noted that in this example, it is possible the Transformation component’s interface is visible to the service. That leads us to the third example.
Example Three – suboptimal
In this final scenario, the service consumer calls the service, and requests that the service redirect the response to a transformation service, with instructions to tell the transformation service to do something with it then return the result back to the service consumer.
This introduces several things that I would fire an architect for.
First – it mixes two tasks into one process. If something goes wrong, the service consumer will have great difficulty knowing where things went wrong. The service consumer also cannot accurately know the state of the service call since it would likely have no idea when the service passed the work to the transformation component.
Secondly, it also blurs two unique functions into one. This lessens the probability of uncomplicated reuse but building unnecessarily complex interfaces. The service interface, instead of handling simple requests, now has to handle requests overloaded with details of where to forward things, what protocol to use and what instructions to forward. Inelegant.
This scenario also introduces another potentially unhealthy risk – the service does not know if the transformation service is even available when it accepts the service request. The Service consumer may get some form of acknowledgement back from the service leading it to believe its request is being processed when in fact it cannot be completed. This would become much more complex in the real world if you layered protocols like WS-RX over top of the transactions.
Finally - As with OO programming and analysis, object should break large jobs down into several smaller tasks which can be completed and orchestrated at will. The third example above is akin to procedural web services. It also introduces dependencies between three components which may result in problems maintaining the system.
Conclusion:
A core tenet of SOA is managed transparency. Consumers should not make assumptions about what happens behind the service, nor should they demand to see details of such they do not really need.
So what do you think? I wm interested in hearing some counter points but please feel free to agree also.
Wednesday, November 02, 2005
What are Open Standards?
The topic of open standards and open source is often confusing. A colleague of mine, Klaus Dieter-naujoks, once tried in vain to impart his wisdom on this subject to me. Being young and naive, I did not let it sink in until years later.
The official definition from Wikipedia
1. Open standards are publicly available specifications for achieving a specific task. By allowing anyone to use the standard, they increase compatibility between various hardware and software components since anyone with the technical know-how and the necessary equipment to implement solutions can build something that works together with those of other vendors.
en.wikipedia.org/wiki/Open_standard
2. A standard that is easy for companies to produce and market products or services conforming to the standard. Essentially there is a competitive market without monopoly profits in products or services conforming to the standard. Some standards that are marketed as "open" aren't open in this sense. ...
www.jmcgowan.com/avigloss.html
It avoids a situation where those who buy products are locked in to one specific vendor. It is often more important to ascertain that there is good vendor support for a specific standard than the standardÂ’s process to meet this goal. This is generally applicable to many things. Light bulbs, cars, toasters etc. all follow standards. The software industry is no different.
Major Wine find!!
I picked up a case of vintage Bordeaux today in Vancouver. The wines have lots of colour, good concentration and fine tannic structure.They are without doubt good keeping wines whatever the vintage. Robert Parker Jr. includes Château Dalem as one of the “Top Châteaux of Bordeaux” and considers it to be one of the best wines of the appellation. Just looking at this picture makes me drool.
I tasted on of the 1983's and it s amazing. A full blooded classic Bordeaux blend if I ever tasted one.
Reference - http://www.seacove.com/frcdalem.htm
Monday, October 17, 2005
Autocross - four 1sts, one second for 2005
My first year of racing a twin turbo Porsche has been an overwhelming success. In 5 races, I managed to finish first 4 times. The car is nothing short of amazing. The Ruf wheels and Michelin Pilot Sport II "R" comps really keep this thing hooked up. Weissach motorsports really helped me out well. Stuart Davidson, a former racer himself, really got my car balanced and set up well.
Not sure what next year is brining. We will have a new addition to our family this fall so things may be more hectic.
Possible updates for next year:
1. A child seat in the back so my 2.5 year old daughter and I can spend some quality time together. Hmm - better think about that one.
2. Ruf Turbos - boost the BOP to over 550. NICE!!!
3. Fabspeed Exhaust - another 50 BOP
4. A cup holder to ensure my starbucks cappucino does not spill while weaving through cones.
or
5. A tripod so I can share videos from the car via this blog?
Comments?
Friday, October 07, 2005
Socially Unhealthy Text Messages?
I saw this article on Techdirt (http://techdirt.com/articles/20051007/082252_F.shtml)
"Last week, we noted that China had come out with new official rules for online news sites, saying that they could only report on news that was socially beneficial. It appears they're going beyond just news sites to personal communications as well, saying that mobile operators needs to start blocking socially "unhealthy" text messages. Apparently, these text messages have "polluted society and spread very bad influence." Sense a pattern here?"
Analysis? What is socially unhealthy? Even the term SPAM is contextual at best. An SMS offering me viagra is spam and not socially healthy IMO, however if the goal of a society is to survive, it demand procreation which in turn may be saved by viagra if some men have troubles with ... uhh .. you know what.
So what is socially unhealthy and what is not? How would you rate the following SMS's:
1. Asking you out for a date (same or opposite sex)?
2. Introducing a new band to you?
3. Advising you that some song by that band has been censored by your government?
4. An invitation to eat at McDonald's?
5. An invitation to do nude yoga poses while watching reruns of Baywatch?
6. An invitation to watch Pamela Anderson doing (nearly) nude yoga poses in Baywatch?
7. An SMS from Pam asking you if you want to go on a date, then do some naked Yoga poses?
8....
The point is that each of these may be healthy or unhealthy based on your own metrics. I would certainly presume that yoga is much healthier than eating at MacDonalds. No government should try to force ideals upon its citizens or censor their activities. I wonder why some of them still do?
"Last week, we noted that China had come out with new official rules for online news sites, saying that they could only report on news that was socially beneficial. It appears they're going beyond just news sites to personal communications as well, saying that mobile operators needs to start blocking socially "unhealthy" text messages. Apparently, these text messages have "polluted society and spread very bad influence." Sense a pattern here?"
Analysis? What is socially unhealthy? Even the term SPAM is contextual at best. An SMS offering me viagra is spam and not socially healthy IMO, however if the goal of a society is to survive, it demand procreation which in turn may be saved by viagra if some men have troubles with ... uhh .. you know what.
So what is socially unhealthy and what is not? How would you rate the following SMS's:
1. Asking you out for a date (same or opposite sex)?
2. Introducing a new band to you?
3. Advising you that some song by that band has been censored by your government?
4. An invitation to eat at McDonald's?
5. An invitation to do nude yoga poses while watching reruns of Baywatch?
6. An invitation to watch Pamela Anderson doing (nearly) nude yoga poses in Baywatch?
7. An SMS from Pam asking you if you want to go on a date, then do some naked Yoga poses?
8....
The point is that each of these may be healthy or unhealthy based on your own metrics. I would certainly presume that yoga is much healthier than eating at MacDonalds. No government should try to force ideals upon its citizens or censor their activities. I wonder why some of them still do?
Didgeridu, Djembe and Guitar
Last night I had the pleasure to perform live with Wade Imre Morissette and Kirsten (lastname??) for an event at Unlimited Yoga. Playing music is my first love and the reason I moved to Vancouver. I love the way it clears your head gets rid of all the buzzword laden drivel inherit in the high tech world. Speaking of which, I guess I need to eventually either post something techie-ish on this blog or change the name to something else. Hmmm.
The night was really cool. My wife lead a 5 rhythms for the first hour, then we switched to Kirtan, a repetitive chanting with Sanskrit lyrics. Not really my style of music to listen to but I found it immensely fun to play. I felt like I had been performing with these guys for years. Sometimes in music you just sort of "click".
We are performing live again Oct 24th. http://www.wadeimremorissette.com/lululemon.html
The night was really cool. My wife lead a 5 rhythms for the first hour, then we switched to Kirtan, a repetitive chanting with Sanskrit lyrics. Not really my style of music to listen to but I found it immensely fun to play. I felt like I had been performing with these guys for years. Sometimes in music you just sort of "click".
We are performing live again Oct 24th. http://www.wadeimremorissette.com/lululemon.html
Tuesday, October 04, 2005
CGI Movies with Live controls?
I wonder what would happen if someone got really creative and made a movie based on Computer Generating Images (CGI) that also allowed members of the public to randomly control aspects of it real time during screening? Think about this. The technology is there today. So how could it work?
Certain characters in the movie would be controllable via an API. People could bid for the right to control those characters during certain time frames when they know the film would be seen by friends etc. The glyphs would only be able to interact with certain aspects of the 3D environment and would have to be constrained not to affect the overall movie plot, yet they could perform some pretty cool stuff (such as driving cars in the background of a movie) or even playing a small role such as deliver a pizza. Glyphs would be controlled similar to online gaming.
To me, this would be an interesting social experiment. I think it would be funny to observe how some would try to maximize their appearance and notoriety within a movie while others may actually use it for embellishing their acting resume.
So there is the idea. Someone go out and implement it. Send me a royalty check if you feel compelled for the idea ;-)
Certain characters in the movie would be controllable via an API. People could bid for the right to control those characters during certain time frames when they know the film would be seen by friends etc. The glyphs would only be able to interact with certain aspects of the 3D environment and would have to be constrained not to affect the overall movie plot, yet they could perform some pretty cool stuff (such as driving cars in the background of a movie) or even playing a small role such as deliver a pizza. Glyphs would be controlled similar to online gaming.
To me, this would be an interesting social experiment. I think it would be funny to observe how some would try to maximize their appearance and notoriety within a movie while others may actually use it for embellishing their acting resume.
So there is the idea. Someone go out and implement it. Send me a royalty check if you feel compelled for the idea ;-)
Saturday, April 02, 2005
Speech given to UN - Kuala Lumpur
While attending a UN Fourm meeting in Malaysia, I was both surprised by the generous hospitality of the Malaysian people and saddened by the all too familiar site of a small percentage of a population left behind economically. Click on the image to the left to see the shanty-town next to our hotel). Don't get me wrong - Malaysian's in general are probably better off than people in many countries. Even the poorest of the poor managed to put on a smiling face to greet us as we walked by the shanty town's behind our 5 star hotel. If you are a traveller, Malaysia is a "must visit" country. It is not just a few people - the entire country seems to be friendly. I think we should let the Malaysians run the rest of the world.
The point of all this was that I was inspired to give a speech to remind people that while life can be good, there is still a lot of work to do to ensure we all prosper fairly. The following is the result of that speech. Oh yes - I learned some Malay too ;-)
*****************************************************
Speech given by Duane Nickull (dnickull@adobe.com), Senior Standards Strategist, Adobe Systems for the 6th annual UN/CEFACT Forum and UN/ECE Capacity Building workshop in Kuala Lumpur, Malaysia, March 17, 2005.
>>
Hello and welcome to the afternoon session of the UN/ECE – UN/CEFACT Capacity Building Workshop 2005 in Kuala Lumpur, Malaysia. My name is Duane Nickull, a vice chair of the UN/CEFEFACT Bureau and Senior Standards Strategist for Adobe Systems. If you will indulge me, I would like to address our gracious hosts in their native language.
[Malaysian] Selamat Datang, Tuan-tuan dan puan-paun. Apa Khabar? Saya Barasa amat gembira bersama Tuan-tuan dan Puan-puan sekalian di Kuala Lumpur. Bagi Pihak United Nations, saya ingin mengucapkan ribuan terima kasih, di atas jemputan kita ke Negara Malaysia yang amat cantik sekali. (drew both applause and histerical laughter based on my poor pronunciation)
I want to provide a tremendous thank you to our hosts. Whenever we visit countries, we get a “feel” for the local culture. If I had to sum up Malaysia in two words, I would chose “energetic and enthusiastic”. The positive energy in this country is unparalleled in my experience and only second to the amazing hospitality. The energetic and enthusiastic feeling is also contagious and I invite you all to use this energy to help accomplish your work.
I would like to ask you to expand your definition of “Capacity Building” too. In addition to the UN helping build capacity in your nations, we also need to build our learning capacity to understand how we can continue to be relevant and credible. We need to understand what work items you need form us so I will invite all of you to make this session and open and informal dialog to facilitate information sharing. The UN speaking is only part of this capacity building – what we really are intent on doing is listening as much or more than we talk.
On a personal note, I want to point out that each and every one of you has the capacity to make a difference in this world. You are the talent, the policy makers, decision makers and implementers of standards and technology for many people on the planet. You can and will make a difference. When contemplating the significance of making a difference, I want to bring to your attention the shanty-town less than 200 meters from where we sit. The worlds of luxury and the needy meet. I would like to personally invite you to never lose sight of the fact that we work for the people who live there. We must strive to help those who cannot help themselves and protect their interest in society. This is a large undertaking and a very worthwhile cause.
Teach each other; learn from each other. Share your successes; share your failures; but never stop learning.
The Japanese have a word that is applicable – Kaizen. It means continuous improvement. That is our work and you will make a difference in this world. I will now turn to the agenda items...
Subscribe to:
Posts (Atom)