Canadian Cybertech assists with Clean Technology adoption ranging from software systems architecture, system design and advancement of user experiences/security. We have over 25 years of experience helping companies gather the full and auditable requirements for IT projects to ensure success.
Friday, September 21, 2007
I've waited 31 years for this
The Canadian dollar is now worth more than the US Dollar. While some have stated that this is primarily due to the fiscal irresponsibility of the current US government, it is also partially due to the strength of the Canadian economy. Should true Republicans be up in arms and have reason to change things? Perhaps, but looking back at the last 31 years, it is actually not bad having a weaker currency. Here are my top predictions for the US and Canada in terms of changes over this new status quo.
1. I think the US will benefit from a weaker dollar in the short and medium terms by keeping some blue collar and other manufacturing related jobs at home. If the US dollar weakens further, it could really help aid the US in terms of foreign orders for the manufacturing sector.
2. The Canadian economy will likely suffer as North American companies with the ability to take advantage of short term fluctuations will likely move manufacturing resources into the US. Canada will likely retain some core natural resource related industries, however processing will likely move south. This is not really bad IMO - it is the real time working of a global economy. Canada built up a good manufacturing sector when it had a weak dollar compared to the US. If this reverses, it should benefit both countries.
3. Pulling out of the war in Iraq will be very desirable for the next US administration. Regardless of Democrat or Republican politics, the economy and relative value of the US dollar will likely be a hot topic in the next 24 months. Luxuries like wars will be also on the table in Canada as mounting costs of our troop presence in Afghanistan also weigh into the national budget debates.
4. Bush is done! He has financially been the most irresponsible president in US history IMO. Forget about morals, he has truly taken a great nation and bankrupted it. Energy costs are at an all time high and the average American still does not have guaranteed health care. America is a great country but it needs to have a good leader. There are about 269,000 or so people in the US I think can do a better job of it than the current leader. Someone please step up and do this.
5. Both Canada and the US will need to work together to maintain competitiveness against the emerging financial superpowers. As globalization is upon us, we must put our petty differences aside and look towards the global stage and figure out how we fit in.
6. The software sector will continue to be profitable, however vendors will have to adjust their strategies to account for disparity in currencies. Currently, the Adobe stock has stayed strong if you live and breathe US dollars. If you are a Canadian shareholder (like me) you have lost 60% of your investments in 3 years on currency issues. Luckily, Adobe is very strong and has doubled in terms of base price leaving us ahead of the game. Nevertheless, foreign investment into Silicon Valley startups might dwindle amid concerns of the weakening US dollar.
Thursday, September 20, 2007
SOA Anti-Patterns: Service Composition and Composite Applications!
FACT: Service Composition is not SOA. It is an anti-pattern of SOA. The same goes for Composite Applications.
I feel like I should have titled this post “The Emperor has no clothes: Part 16” as I have seemingly made a career by challenging the status quo. This post may be a bit of a rant but make sure you read it before passing judgment.
The SOA community has once again used poor judgment in terms of coining titles for aspects of SOA, namely Service Composition and Composite Applications. If these are truly built on an SOA infrastructure, most of them are in fact Service Aggregations and Aggregate Applications. Let me explain where the terms come from and what they really mean.
Composition and Aggregation are both types of Binary Relationships. They are also both specializations of the “whole-part” pattern, a pattern in which a whole “thing” has parts. In both cases, the Whole (in this case the so called Composite Applications and Service Compositions) rely and cannot exist without the Part(s) (the services). There are very subtle yet concrete differences between how Composition and Aggregation work though. The main difference is that in aggregation, the parts can exist without the whole. Wikipedia discusses aggregation (http://en.wikipedia.org/wiki/Object_composition#Aggregation):
“Aggregation differs from ordinary composition in that it does not imply ownership. In composition, when the owning object is destroyed, so are the contained objects. In aggregation, this is not necessarily true”
Composition (as defined by UML) is a special type of relationship where the part and the whole are inextricably linked. In short, the Whole IS MADE UP OF one or more Parts. If the Whole does not exist, neither can the Parts and their life cycle is tied directly to the life cycle of the Whole. The UML composition relationship is depicted below.
Aggregation is a different animal. In an aggregate binary relationship, the Parts may exist without the Whole and be used by more than one “thing”. The Whole CANNOT BE MADE UP OF the Parts. The UML aggregation relationship is depicted below.
Aggregation is akin to how services are utilized within an SOA environment. Services are not contained within the service consumer, services are independent entities within an SOA environment and “consumed” by the consumer. Services can therefore exist without the consumer being present, the opposite of a composition binary relationship. In fact, both services and consumers are usually considered first class entities within an SOA environment as commonly depicted amongst the SOA community. The UML relationship can be depicted below. Note this one is abstract of any stereotype such as <> or <> but these could be added. Consider this more of an existentialist binary relationship.
Given one of the core goals of SOA is the ability to “re-purpose” services amongst several consumers, it would be highly illogical (and an “anti-pattern” of SOA) to tie a service’s life cycle to one single consumer and to constrain that service to exist only within the consumer. That is in effect the pattern SOA strives to avoid. Note that once again, I have changed terms slightly. The term “re-purposed” has been used instead of “re-used”. Services that are re-used only by one consumer do not tend to offer huge advantages other than reducing dependencies and creating agility buy cleanly decoupling the consumer from the core functionality offered via the service.
Business Process Management (BPM), Service Aggregation and Aggregate Software Applications are all specialized types of service consumers. In all three cases they consume services but are not made out of services. The services exist without the consumer.
I am not confident that the industry will change but if you think this makes sense, please take a pledge to start at least making this distinction.
I feel like I should have titled this post “The Emperor has no clothes: Part 16” as I have seemingly made a career by challenging the status quo. This post may be a bit of a rant but make sure you read it before passing judgment.
The SOA community has once again used poor judgment in terms of coining titles for aspects of SOA, namely Service Composition and Composite Applications. If these are truly built on an SOA infrastructure, most of them are in fact Service Aggregations and Aggregate Applications. Let me explain where the terms come from and what they really mean.
Composition and Aggregation are both types of Binary Relationships. They are also both specializations of the “whole-part” pattern, a pattern in which a whole “thing” has parts. In both cases, the Whole (in this case the so called Composite Applications and Service Compositions) rely and cannot exist without the Part(s) (the services). There are very subtle yet concrete differences between how Composition and Aggregation work though. The main difference is that in aggregation, the parts can exist without the whole. Wikipedia discusses aggregation (http://en.wikipedia.org/wiki/Object_composition#Aggregation):
“Aggregation differs from ordinary composition in that it does not imply ownership. In composition, when the owning object is destroyed, so are the contained objects. In aggregation, this is not necessarily true”
Composition (as defined by UML) is a special type of relationship where the part and the whole are inextricably linked. In short, the Whole IS MADE UP OF one or more Parts. If the Whole does not exist, neither can the Parts and their life cycle is tied directly to the life cycle of the Whole. The UML composition relationship is depicted below.
Aggregation is a different animal. In an aggregate binary relationship, the Parts may exist without the Whole and be used by more than one “thing”. The Whole CANNOT BE MADE UP OF the Parts. The UML aggregation relationship is depicted below.
Aggregation is akin to how services are utilized within an SOA environment. Services are not contained within the service consumer, services are independent entities within an SOA environment and “consumed” by the consumer. Services can therefore exist without the consumer being present, the opposite of a composition binary relationship. In fact, both services and consumers are usually considered first class entities within an SOA environment as commonly depicted amongst the SOA community. The UML relationship can be depicted below. Note this one is abstract of any stereotype such as <
Given one of the core goals of SOA is the ability to “re-purpose” services amongst several consumers, it would be highly illogical (and an “anti-pattern” of SOA) to tie a service’s life cycle to one single consumer and to constrain that service to exist only within the consumer. That is in effect the pattern SOA strives to avoid. Note that once again, I have changed terms slightly. The term “re-purposed” has been used instead of “re-used”. Services that are re-used only by one consumer do not tend to offer huge advantages other than reducing dependencies and creating agility buy cleanly decoupling the consumer from the core functionality offered via the service.
Business Process Management (BPM), Service Aggregation and Aggregate Software Applications are all specialized types of service consumers. In all three cases they consume services but are not made out of services. The services exist without the consumer.
I am not confident that the industry will change but if you think this makes sense, please take a pledge to start at least making this distinction.
Subscribe to:
Posts (Atom)