Valley at the epicenter
Tech firms, employees help victims of China’s massive 2008 earthquake rebuild
By John Boudreau
jboudreau@mercurynews.com
DUJIANGYAN, China — Louis Choi sees ghosts. They are in the heaps of concrete that once sheltered schoolchildren. They are in the new school buildings in recovering Sichuan province. They are in his dreams.
“It was devastating, those early days,” he said about arriving in this city where about 900 children and teachers died when their school collapsed during last year’s 7.9 magnitude earthquake. Choi, a Cisco Systems engineer, was at the scene as soldiers pulled children, limp like rag dolls, from the wreckage — as they neatly stacked school book bags of crushed students for the parents to pick up — as mothers and fathers ceaselessly called out the names of their buried offspring. “I saw it over and over again. You couldn’t avoid it,” he said between deep exhales, his face reddening.
Choi immediately left his job in Cisco’s Beijing office, where he developed technology plans for the banking industry, and moved to China’s southwestern region to oversee the San Jose-based net-working company’s $45 million earthquake assistance program. He is one of hundreds of employees from many of Silicon Valley’s elite companies who headed to the quake zone after the life-shattering disaster on May 12, 2008 — killing about 70,000 people and with 18,000 missing and leaving nearly 5 million people homeless — to help with the healing and rebuilding.
It serves foreign companies well to play the role of good corporate citizen in China, where gaining favor with local Communist officials can pave the way for smoother business relations. It can showcase new technology in a nation growing at a rapid clip. But the primary motivation for most technology company workers was emotional: to do something constructive in the face of nature’s fury.
Deeply personal event
For many, it was a deeply personal event. Their legs went wobbly as the ground buckled underneath them that spring afternoon. They lost family and homes. “People huddled on the floor, trembling, assuaging each other. Everyone was calling home, but rarely could anyone get through,” recalled Intel employee Tony Li. “I had no way to know about the safety of my grandmothers, my parents and my brothers. Were they alive? I didn’t know. All I knew was they lived only kilometers away from the epicenter.” He later learned two relatives died in the quake. Powerful aftershocks, some more than magnitude 6, continued to cause casualties and damage.
Intel regularly dispatches buses full of workers to assist schools rising from the ruins. Google’s foundation has sponsored a nearly $3 million program through U.S.-based nonprofit MercyCorps to help children cope with the visions of friends buried alive. And Cisco assigned Choi to manage the three-year installation of equipment to create state-of-the-art classrooms.
They joined the more than 1 million Chinese who raced to the destruction zones — an unprecedented outpouring of volunteerism in this country — and more than 145,000 soldiers mobilized to pick through the rubble for survivors, as well as the flood of nearly $1 billion in donations from the nation’s corporations. The disaster had employees and companies competing to out-give each other. The Chinese media goaded them on — publishing the names of top corporate givers to prod others to donate more. Soon after the earthquake, former Intel Chairman Craig Barrett visited the disaster area, as did Cisco CEO John Chambers.
“I remember saying, ‘Even Jackie Chan gave more than Intel (about $1.5 million). We’ve got to up the ante,’” said Mike Mendenhall, general manager of Intel’s chip testing and assembly plant in nearby Chengdu. His company has since committed $5 million for computer labs, e-learning software for 200 schools and teacher training plus about $2 million for general relief raised from employees with matching company funds and Intel’s foundation. In addition, Intel employees volunteer to teach classes and lead other activities.
Choi, 55, was told by a top Cisco executive in China that the company could not guarantee he’d have a job after this three-year stint in Sichuan province. “This is an uncertainly I’m totally willing to accept,” said the engineer, who has deep family ties to the region. “I told him right away, ‘I’ll go.’”
Hitting kids hard
The destruction was particularly severe for schools and children. School buildings crumpled like paper, killing 5,335 students. Meanwhile, nearby government buildings remained virtually untouched, adding to the anguish of parents who faulted shoddy construction for the deaths of their children.
The earthquake’s epicenter was 19 miles from Hanwang township of Mianzhu city, where the hands on a tower clock are frozen at 2:28 p.m. Buildings with collapsed floors, missing walls and leaning this way and that still have clothes hanging in balconies. A 2008 Beijing Olympics banner droops from a street archway.
“How can I describe it? It felt like it was the end of the world,” said Wu Qi Lu, who fled his violently swaying building into the street. “We had no hope.”
Though Chengdu, the capital of Sichuan province, survived virtually unscathed, the city of 11 million nonetheless received a horrifying shaking that people call the longest three minutes of their lives. “We could see the floor rolling. Everybody was running everywhere,” recalled Intel’s Mendenhall, a former Fremont resident.
Scores camped out at Intel’s campus, which became a temporary tent city for a month. “You could feel their fear,” said Hu Minxian, Intel’s volunteer facilitator whose first day on the job was when the quake hit.
Now, in addition to company- sponsored volunteer time, many spend free hours helping children piece their lives back together. They teach special classes on math and computers — or simply hang out on campus with students still battling nightmares. More than 90 percent of the company’s 3,000 Chengdu employees volunteer.
“One student painted a picture of a ghost chasing him,” Hu recalled. “He had such a strong fear in his heart.”
On a recent outing to Longfeng Zhen school in Pengzhou County, Intel employees showed up to teach courses such as digital moviemaking and organized team-building exercises.
“The first time we saw the children here, there was no light in their eyes,” recalled CY Yeung, Intel’s director of corporate responsibility. “They had this dazed stare.”
The school complex, which houses nearly 2,000 elementary and junior high students, has been rebuilt.
Nerves remain jangled
On this early September day, students streamed by, rice bowls in hands, in lines to the cafeteria for lunch. Spotting foreigners, they giggled, pointed and called out, “Hello.” But more than a year later, nerves remain jangled. Teachers say they had a tough time getting students to enter the new second-floor classrooms. Amid the crumbling of the buildings during the earthquake, adults had to plead with panicked children not to jump off the second floor as the stairways jammed with fleeing students. “It’s still a little bit hard for all of us,” said Eugene Yu, a 26year-old Intel systems analyst. “The children are very excited to see us. But if you mention what happened, they can get emotional very quickly.”
More than 3,300 schools were destroyed in the earthquake, said Liu Cong, a director with the Sichuan Province Education Department. By the end of this year, most will have been rebuilt, he said.
Choi, Cisco’s on-site liaison, has zigzagged across the province the past 16 months, revisiting areas that lost hundreds of children. There is the village of Xiange that, he said, saw a generation wiped out when its middle school collapsed. “That’s why they don’t have a middle school anymore,” said Choi, removing his glasses and wiping his eyes.
At the Friendship School in Dujiangyan, Choi inspected the campus as networking equipment was being installed. The newly opened school for grades one through nine has also been outfitted with wheelchair ramps and handicap assistance bars in bathrooms.
Nearly 150 disabled students — children who lost limbs after being trapped under tons of classroom concrete — attend the school. Fourteen-year-old Huang SiYu, whose leg was amputated after her school collapsed in Yingxiu, has just enrolled in the school. Because of her injury, she missed a year of school.
Before “the thing” happened — her phrase for the earthquake — she wanted to be a dancer, she said. Now, Huang added, “I want to learn English well.”
Choi watched her move stiffly down the hall, leaning on a teacher and another student, who also lost her leg. “This really helps to ease my sorrow,” he said.
2009年11月12日星期四
2009年10月10日星期六
it’s time for real soccer
刚刚结束的阿根廷与秘鲁的比赛中，技战术含量极低，双方机会均不多，配合也相当不流畅，但就是这样一场看起来质量差的离谱的比赛，却注定会成为阿根廷国家队历史上的经典比赛之一，因为他诠释了足球为什么是纯爷们运动的全部真谛。
上半场乏善可陈，阿根廷的前场基本没有任何机会，梅西被冻结，伊瓜因在苦苦寻找机会，艾马尔灵光闪现，而其他队员基本毫无作用。但下半场换上的老将帕勒莫，一个在我心中一直是一个笑料的球员，却彻底改变了比赛。
多年前的美洲杯中，帕勒莫面对哥伦比亚的门将，毅然决然推开了萨内蒂，决定主罚全场比赛第三个点球，结果依旧被扑出的时候，一场比赛点球不进帽子戏法的大帽子一辈子扣在了他的头上。帕勒莫很快就从国家队彻底消失，之后短暂效力比利亚雷亚尔期间，庆祝进球的时候还被主场看台砸骨折，休息了五个月，这个“疯子”出现在球迷嘴中时，往往就带着这两样事迹，成为了人们的笑料。
但就是这样一位老将，在之后回到博卡青年后一直没有放弃返回国家队的梦想，尽管在马拉多纳上任后他就立刻返回了国家队并站稳一席之地，但始终没有摆脱马拉多纳嫡系的身份，直到今天，他在第93分钟的绝杀，以及之后彻底释放自己的脱衣庆祝，终于摆脱了几乎即将困扰自己一生的幽灵，让全场观众夹杂着狂风暴雨呼啸声的疯狂尖叫，将自己身上的全部霉运一扫而光。
帕勒莫完全配得上这个进球，他比场上其他的所有前场队友至少都要大10岁，跑动距离却是他们的两倍。而秘鲁队也并非配不上取得这场比赛的胜利，尽管早早就被淘汰出世界杯，但他们从一开始就没让阿根廷人有好果子吃，90分钟的准绝杀扳平，以及最后时刻的吊射打中横梁，让人完全了解了为什么老球迷总是说“南美10个球队谁出线都正常”。
巴塞罗那在场上统治场面的霸气和华丽是真正的足球，但并不仅仅是这种足球才是真正的足球，即使在场面上一无是处，只要你足够男人，依然有纯爷们的方式取得比赛的胜利，这也是真正的足球；即使成绩糟糕透顶，水平远逊任何对手，只要足够男人，也依然能够得到观看了整场比赛的真正球迷们的热烈掌声，这些东西，绝对不是某些人信心满满准备花几个亿欧元买上几个金球奖得主就能轻松买来的，也不是一些平时看个比分看个帅哥就到处炫耀到处骂人的所谓球迷们能够理解的。
It’s time for real soccer。
RVL
2009年9月22日星期二
苏格拉底的预言
苏格拉底（bc.469 --- 399?） 对特拉马库斯说：
强权不是真理，强权的基础是暴力。
真理只能以正义为基础。在正义得到实现的国家,每一个公民的自由，全体国民在政治和司法权利上基于自由的平等，都得到法律的确认和保障。
在极端不正义的情形下，暴君就是盗匪。
如果窃贼掌握了武力，窃贼就会用欺骗和暴力掠夺他人的财产，不论是神圣的或者是世俗的，公共的或者私人的：不是零敲碎打，而是一扫而光。
如果窃贼掠夺了全部的财产，还以暴力为基础炮制出匪徒的法律，
去奴役全体暴力下的人民，那么掠夺了全部的财产的武装窃贼就不会受到法律的制裁和处罚，反而会把他们的首领塑造成为一个无所不能的神。
因为在凡夫俗子看来，无所不能的神自然是正义的。
在罪恶登峰造极的国度里，欺骗和暴力掠夺就成为法律。
皮奎：天之骄子
17岁做出那个决定，离开巴塞罗那后，他依然没有放弃回到诺坎普效力的梦想
也许看起来无法相信，但用手推一把人，能够让对方受益终身。也许普通男人之间经常会发生这种事情，但如果说这是一个成年人把一个小孩子推了一把，还是在那个小孩子的家长面前的话，那这个故事就要有意思的多了。这个成年人还是在作为这一家人的座上宾，平日的关系非常融洽的话，想知道这个疯狂的成年人是谁？显然只能是路易斯-范-加尔。而这个在自己家长面前被“体罚”的倒霉的孩子是谁呢？答案就是：赫拉德-皮奎。
当时还只有12岁的皮奎，就是在这种情况下，接受了范加尔的一次特殊的考试。当时的巴萨主帅范加尔是巴萨董事会成员阿玛多-伯纳乌的好友，他当时正是接收了伯纳乌的邀请，来到他家做客。伯纳乌先生当时还经常随队南征北战，因此也与范加尔接触颇多，然后成为了朋友，这也是这位极其注意职业素养的教练为什么能与一个球队高层成为朋友的原因。
在那个周日，伯纳乌邀请范加尔来他家吃饭。席间，伯纳乌向范加尔介绍了他的孙子，当时这个小伙子正在巴萨效力，踢中后卫的位置。伯纳乌先生想让范加尔认识认识这个孩子，如果有可能的话，能够对他指点一二。
范加尔的执教生涯中从来没有与孩子打过交道，于是他灵机一动，想了个办法，他向孩子点了点头，然后突然推了他一把，孩子毫无准备，立刻摔了一跤，倒在了地上。这真是范加尔典型的行事风格。
而这个小伙子，正是赫拉德-皮奎-伯纳乌，这就是他与巴萨一线队的主教练的第一次互动，对方的手伸了出来，不过没有友好的握手，而是立刻把他推倒在了地上。不过显然事情不会这么结束。
小皮奎坐在地上害怕地看着这个将自己一把摔在地上的男人，一言不发，等着这个男人能够对他的这个行为有什么解释，毕竟他好像“的确”是他的爷爷的好朋友。
“你太瘦弱了！”范加尔开口了，“想踢上巴塞罗那的主力中后卫，你必须变得更加强壮。如果你几年后还是这种身体条件，你就不要踢中后卫了。好好锻炼你的身体！”说完后范加尔转身回到了自己的座位上。
这可不是每一个孩子都能够经历的场面，而皮奎恰恰接受了一堂当时他所经历过的最难忘的理论课。以前小皮奎最喜欢的是传统西班牙孩子们的项目：脚下技术。但在这之后，他明白现在锻炼自己的身体也是自己将来职业生涯重要的保证之一。
皮奎随后的职业生涯都很顺利，在17岁的时候，他和梅西、法布雷加斯、维克托-巴斯克斯等人一起，拿到了那一级青年队能够拿到的所有冠军。但当时的巴萨高层出现了动荡，努涅斯和加斯帕特的势力已经被拉波尔塔彻底清洗，而皮奎在看到俱乐部动荡的情况下，外加自己祖父之前的特殊身份，决定接受来自曼联的邀请。他的朋友法布雷加斯之前去了阿森纳，并在那里已经走上了顺利发展的正轨，因此当巴萨提出希望他继续为巴萨征战西丙联赛的时候，他已经不愿意继续在青年队“浪费”时间了。
事实上，在曼联的时候，他依然牢记着范加尔当年告诉他的那句话，把自己的身体练得有如英式中卫一样强壮。20岁的那年他被租借到萨拉戈萨一个赛季，并证明了自己已经能够在西甲联赛立足。之后返回曼联一个赛季后，他终于完成了范加尔9年前给他定下的这个目标：练好身体，出任巴萨的主力中后卫。
皮奎小资料：
出生日期：1987年2月2日
处子战：2008年8月13日维斯拉 0-4 巴塞罗那（欧冠资格赛）
合同：2012年6月30日到期
最小违约金：5000万欧元
最爽的一天：在伯纳乌6-2血洗皇马并打进第六球
最糟糕的一天：在萨拉戈萨被教练安排踢左后卫，盯防罗比尼奥，结果表现糟糕。
皮奎的秘密：
--1米92的身高，83公斤的体重，皮奎这个大个子人如其表，是瓜迪奥拉手下最容易饿的球员，比赛结束后，他总是拉着他的队友们一起去买巧克力。
--在曼彻斯特，皮奎经历了很多事情，其中不少是好事，但也有这样的倒霉事：皮奎请一个人帮他安装电视卫星接收器（俗称大锅—译者），结果那个人下午趁着皮奎去球队训练，就把东西偷走了。后来皮奎发现东西丢了，还找那个人又买了一件，结果又被偷走。皮奎就这样被这个家伙坑了多次后才被皮奎的父亲发现。
--皮奎后来换了公寓，与范德萨住在同一座公寓里。
--他一直是女球迷的宠儿，在英格兰甚至比在西班牙更加有人气。
塞尔吉奥-布斯克茨：十年磨一剑
他和他父亲一样，像个邻家大男孩；他和他父亲一样，是在土生土长的巴迪亚人；他和他父亲一样，是巴塞罗那的球员。不过仅仅一年，塞尔吉奥就超过了他父亲当年在巴萨的成就。去年还在为巴萨竞技队升上乙B联赛而奋战，今年塞尔吉奥就已经在巴萨一线队取得了成功，并在自己成年队第一个赛季就拿到了三冠王。
--塞尔吉奥的第一个赛季就已经比绝大多数球员一生的成就都要高
2008年9月13日，塞尔吉奥第一次为巴萨一线队出战，对手是桑坦德竞技。
10月22日，他在客场对阵巴塞尔的欧冠中收获自己第一个一线队进球。
而在这个进球的11天前，他第一次为西班牙U21国家队出战。
两个月后，巴萨与他续约到了2013年。
2009年2月6日，他第一次被召入西班牙国家队，并在4月1日对阵土耳其的比赛中完成处子战。
之后，他拿到了联赛冠军，并在国王杯决赛和欧冠决赛双双首发，帮助球队拿到三冠王。
赛季结束后，他将随西班牙国家队征战联合会杯（已结束，出场3次，共180分钟，表现稳定—译者）
这就是塞尔吉奥-布斯克茨过去这一个赛季所发生的故事，包含着如此多的内容，很多球员的一生都难以完成其中的一项，但这个小伙子一年之内全都做到了。他是巴萨前门神卡洛斯-布斯克茨的儿子，一出生就注定了要成为一个职业球员。与他父亲不同，他从小就显示出了在中场的天赋，并迅速取得了成功。他在过去的九个月里的故事可以被所有年轻球员们用来激励自己：一年前还只是个西丙联赛的菜鸟，一年后作为队中重要球员拿到了三冠王。如果赛季开始前瓜迪奥拉没有将布斯克茨纳入自己的计划，一切显然完全不会发生，但上赛季布斯克茨在巴萨竞技队的出色表现让瓜迪奥拉执掌一线队后迅速做出了决定。这也是巴萨各级青年队年轻人的骄傲：只要你有机会，就可以在诺坎普取得成功。
塞尔吉奥从很小的时候就开始拿职业球员的标准要求自己，确切的说，这种情况甚至在他出生后不久就开始了。他出生后不久，就给了父亲送给他的小足球一脚，完成了自己人生中第一脚触球。当他结交到自己第一个朋友前，就已经开始沉迷于足球之中，直到现在。塞尔吉奥后来得到了属于自己的第一个真正的足球，而与此同时，他在运动上的天赋开始展现在他的多面性上：在不得不决定选择足球作为职业前，他曾经练过篮球，游泳和网球，而且每个项目表现都不错。即使到现在，他也经常说当年练习的那几项运动到现在都对他踢足球有帮助。他的父母在他不到六岁的时候就让这些运动充斥在他的业余时间里，后来他随他父亲从巴迪亚移居到了列达，并先后效力当地的特拉费尔马俱乐部以及亚巴克俱乐部，直到加盟巴塞罗那。
尽管塞尔吉奥-布斯克茨曾经擅长不同项目，但在球场上他可没那么具有多样性。他进入巴萨后一直在出任后腰，也就是现在图雷-亚亚的位置。瓜迪奥拉上任后认为图雷-亚亚还需要一个替补，于是他就想到了塞尔吉奥。也许塞尔吉奥小时候练过门将（追随他父亲），但在俱乐部里，他始终没有严肃尝试过门将这个位置。事实上在刚刚接触足球的时候，布斯克茨还踢过前锋，一度在当地少年队进球如麻，是个经典的9号中锋，但不久后就放弃了这个位置。而这也对他现在的比赛有不少帮助，只要比赛中有机会，他也会争取把握住并破门得分。本赛季他在门前的嗅觉不错，联赛打进一个球，欧冠也有两球进账。
今年7月16日，塞尔吉奥-布斯克茨就将迎来21岁生日，但他永远不会忘记他20岁这年都发生了什么。“这是我从小的梦想：某一天能够为巴萨效力，进球，并拿到冠军，并重复这些很多年。”布斯克茨以前曾经对记者这么说过。结果过去一个赛季这些梦想瞬间就都实现了。然而这一年的辉煌，是布斯克茨过去十年努力换来的结果，之后他要做的，就是争取在整个职业生涯中一直保持这样的表现。
布斯克茨的秘密：
El 13 de septiembre del año pasado jugó, por primera vez, con el primer equipo del Barça. Sergio Busquets ha vivido, en un solo año, lo que muchos futbolistas viven, si es que lo hacen, en toda una carrera.
n 左臂上有个阿拉伯语纹身，只有他自己知道他这个纹身真正含义是什么
n 他曾经踢过前锋，但后来厌倦了进球，才改踢后腰
n 他小时候还曾经是个优秀的游泳运动员，网球手和篮球手
n 他的学习成绩非常不错，尽管后来他由于踢球，没有完成高二的课程
n 他最喜欢的歌唱组合是El Canto del Loco，但也听其他乐队的歌曲
n 他是iPod的忠实发烧友
n 他祖父有他的所有进球的录像
n 他以前在伯纳乌参加一个活动的时候，大胆高喊“巴萨万岁！加泰罗尼亚万岁”
2009年6月21日星期日
我们的英雄们（1） -- 伊涅斯塔
从布鲁内特到诺坎普
--阿尔瓦塞特人当年与巴萨签约后，在拉玛西亚的第一个晚上险些跑回去找妈妈
如今已经成为巴萨传奇的伊涅斯塔，在1984年的5月11日出生于阿尔瓦塞特的Fuentealibilla，在这个人口稀少却热爱足球的小镇里，伊涅斯塔开始了自己与足球相伴的一生，而他的家人很快就高兴地看到这个从小就和大孩子一起踢球的小家伙进入了阿尔瓦塞特当地的球队。而直到他随这支来自阿尔瓦塞特省会的球队参加了一项叫做布鲁内特杯的赛事，通往辉煌职业生涯的大门就此向他打开了。
事实上伊涅斯塔一共参加了两次这项在马德里举行的赛事。第一次阿尔瓦塞特人获得第四，而一年后，1996年，该队获得季军，而伊涅斯塔则当选最有价值球员。巴萨的球探显然不会错过这种比赛，当时专门考察该级别年龄段球员的巴萨球探阿尔伯特-维奈格斯被伊涅斯塔的表现所征服，赛事结束后立刻通过他在阿尔瓦塞特的关系网与伊涅斯塔的家人取得了联系。维奈格斯说服了伊涅斯塔的父母带着孩子在周末去一趟巴塞罗那，了解一下巴萨的青训营的硬件设施。而在那之后，伊涅斯塔最终决定，这里将是他的新家，并在这个城市度过了12年的职业生涯，直到现在。
伊涅斯塔对自己在拉玛西亚的第一天印象非常深刻，在他的官网（http://www.andresiniesta.es）上，这位如今已经成为世界顶级巨星的巴萨中场描述道：“我是晚上过去的，当时所有的孩子还在吃晚饭，不过我基本什么都没吃就直接去宿舍睡觉去了。第二天早上起来我看见我父亲和祖父在接待处聊天，我的第一感觉就是‘我真的身处巴塞罗那吗？还是依然在我的老家？’。之后他们对我说，如果我真的感觉不适应这里，可以在第二天就接我回我的老家，不过后来我那坚强的母亲立刻喝止了这种提案。”
伊涅斯塔的第一场比赛是在代表巴萨Alevín A级别的少年队（第九级别，12岁年龄段）面对普拉特少年队，结果他立刻就成为了全场最佳。之后他就开始了一连串跳级，逐步迈向了诺坎普。而当他刚刚16岁的时候，时任巴萨主帅费雷尔就给了他第一次与一线队一起训练的机会。伊涅斯塔本人在刚到巴塞罗那的时候度过了好几年的适应期，球探维奈格斯几乎担当起了他的父亲的责任，平时陪他去电影院，或者陪他一起散步。刚来巴萨的时候，伊涅斯塔是那个年龄段里最小的球员，与豪尔赫-托罗泰罗（目前效力于西乙B球队卢塞纳）一个房间。他的室友的家就在巴达罗那（离巴塞罗那不远），但伊涅斯塔就不得不经受思乡之苦了。
这些年过去后，伊涅斯塔也在各种锻炼中成熟了起来。当时被召入西班牙U16国家队的那段经历是他年轻的时候最艰难的时刻之一。那支拥有托雷斯的球队最终获得了冠军，但伊涅斯塔则在对德国队的比赛中被对手踹伤，腿上印上了四个大鞋钉印，肌肉受伤的同时，膝盖侧韧带也重伤。伊涅斯塔不得不返回了巴塞罗那，而他的队友则含泪送别了他，并在夺冠后特意去巴塞罗那探望了他。因此从小伊涅斯塔就知道，因为受伤而告别决赛有多么痛苦，这也是为什么今年他在受伤后宁可打封闭导致伤情加重，也要在罗马的欧冠决赛中出场。
2002年的10月29日，18岁的伊涅斯塔在巴萨对布鲁日的欧冠比赛中被范加尔派遣上场，完成了处子秀，而2004-05赛季他在里杰卡尔德手下成为了一线队的重要球员，尽管更多是扮演超级替补的角色。
荷兰人逐渐给他更多的出场机会，但在巴黎进行的欧冠决赛中，尽管之前的比赛中曾经扮演重要角色（对本菲卡和米兰的比赛中担任单后腰），伊涅斯塔却没有首发。时光飞逝，如今伊涅斯塔在斯坦福桥那脚世界波后，已经彻底迈入了当今足坛大师的行列，也已经成为了巴萨史上的传奇人物。
小资料：
出生地点和时间：1984年5月11日，出生于阿尔瓦塞特大区的Fuentealbilla
处子秀：2002年10月29日，18岁，布鲁日对阵巴塞罗那，欧冠小组赛
合同：2014年6月30日到期
违约金：1.5亿欧元
最美好的回忆：2009年，伦敦绝杀切尔西
最糟糕的回忆：2009年，对比利亚雷亚尔的比赛中最后时刻受伤
兴趣：摄影
--阿尔瓦塞特人当年与巴萨签约后，在拉玛西亚的第一个晚上险些跑回去找妈妈
如今已经成为巴萨传奇的伊涅斯塔，在1984年的5月11日出生于阿尔瓦塞特的Fuentealibilla，在这个人口稀少却热爱足球的小镇里，伊涅斯塔开始了自己与足球相伴的一生，而他的家人很快就高兴地看到这个从小就和大孩子一起踢球的小家伙进入了阿尔瓦塞特当地的球队。而直到他随这支来自阿尔瓦塞特省会的球队参加了一项叫做布鲁内特杯的赛事，通往辉煌职业生涯的大门就此向他打开了。
事实上伊涅斯塔一共参加了两次这项在马德里举行的赛事。第一次阿尔瓦塞特人获得第四，而一年后，1996年，该队获得季军，而伊涅斯塔则当选最有价值球员。巴萨的球探显然不会错过这种比赛，当时专门考察该级别年龄段球员的巴萨球探阿尔伯特-维奈格斯被伊涅斯塔的表现所征服，赛事结束后立刻通过他在阿尔瓦塞特的关系网与伊涅斯塔的家人取得了联系。维奈格斯说服了伊涅斯塔的父母带着孩子在周末去一趟巴塞罗那，了解一下巴萨的青训营的硬件设施。而在那之后，伊涅斯塔最终决定，这里将是他的新家，并在这个城市度过了12年的职业生涯，直到现在。
伊涅斯塔对自己在拉玛西亚的第一天印象非常深刻，在他的官网（http://www.andresiniesta.es）上，这位如今已经成为世界顶级巨星的巴萨中场描述道：“我是晚上过去的，当时所有的孩子还在吃晚饭，不过我基本什么都没吃就直接去宿舍睡觉去了。第二天早上起来我看见我父亲和祖父在接待处聊天，我的第一感觉就是‘我真的身处巴塞罗那吗？还是依然在我的老家？’。之后他们对我说，如果我真的感觉不适应这里，可以在第二天就接我回我的老家，不过后来我那坚强的母亲立刻喝止了这种提案。”
伊涅斯塔的第一场比赛是在代表巴萨Alevín A级别的少年队（第九级别，12岁年龄段）面对普拉特少年队，结果他立刻就成为了全场最佳。之后他就开始了一连串跳级，逐步迈向了诺坎普。而当他刚刚16岁的时候，时任巴萨主帅费雷尔就给了他第一次与一线队一起训练的机会。伊涅斯塔本人在刚到巴塞罗那的时候度过了好几年的适应期，球探维奈格斯几乎担当起了他的父亲的责任，平时陪他去电影院，或者陪他一起散步。刚来巴萨的时候，伊涅斯塔是那个年龄段里最小的球员，与豪尔赫-托罗泰罗（目前效力于西乙B球队卢塞纳）一个房间。他的室友的家就在巴达罗那（离巴塞罗那不远），但伊涅斯塔就不得不经受思乡之苦了。
这些年过去后，伊涅斯塔也在各种锻炼中成熟了起来。当时被召入西班牙U16国家队的那段经历是他年轻的时候最艰难的时刻之一。那支拥有托雷斯的球队最终获得了冠军，但伊涅斯塔则在对德国队的比赛中被对手踹伤，腿上印上了四个大鞋钉印，肌肉受伤的同时，膝盖侧韧带也重伤。伊涅斯塔不得不返回了巴塞罗那，而他的队友则含泪送别了他，并在夺冠后特意去巴塞罗那探望了他。因此从小伊涅斯塔就知道，因为受伤而告别决赛有多么痛苦，这也是为什么今年他在受伤后宁可打封闭导致伤情加重，也要在罗马的欧冠决赛中出场。
2002年的10月29日，18岁的伊涅斯塔在巴萨对布鲁日的欧冠比赛中被范加尔派遣上场，完成了处子秀，而2004-05赛季他在里杰卡尔德手下成为了一线队的重要球员，尽管更多是扮演超级替补的角色。
荷兰人逐渐给他更多的出场机会，但在巴黎进行的欧冠决赛中，尽管之前的比赛中曾经扮演重要角色（对本菲卡和米兰的比赛中担任单后腰），伊涅斯塔却没有首发。时光飞逝，如今伊涅斯塔在斯坦福桥那脚世界波后，已经彻底迈入了当今足坛大师的行列，也已经成为了巴萨史上的传奇人物。
小资料：
出生地点和时间：1984年5月11日，出生于阿尔瓦塞特大区的Fuentealbilla
处子秀：2002年10月29日，18岁，布鲁日对阵巴塞罗那，欧冠小组赛
合同：2014年6月30日到期
违约金：1.5亿欧元
最美好的回忆：2009年，伦敦绝杀切尔西
最糟糕的回忆：2009年，对比利亚雷亚尔的比赛中最后时刻受伤
兴趣：摄影
2009年5月3日星期日
6-2 6-2 madrid cabron saluda al campeon!
6-2 6-2 madrid cabron saluda al campeon!
6-2 6-2 madrid cabron saluda al campeon!
6-2 6-2 madrid cabron saluda al campeon!
6-2 6-2 madrid cabron saluda al campeon!
改日再写文章庆祝，工作第一
RVL
6-2 6-2 madrid cabron saluda al campeon!
6-2 6-2 madrid cabron saluda al campeon!
6-2 6-2 madrid cabron saluda al campeon!
改日再写文章庆祝，工作第一
RVL
2009年3月12日星期四
Component API Design Evaluation
five major issues, difficulties, and challenges in component API design
Major Issues:
Define useful API’s characteristics: To define the key factors making API more helpful for coders .
Define usable API’s characteristics: To define the key factors making the API document better on easiness, Learnability and rememberability.
Making useful APIs: Follow the defined characteristics and make the APIs useful.
Making usable APIs: Follow the defined characteristics and make the APIs usable.
The factors affecting usable useful API: Check the defects of early design and optimize the document.
Difficulties:
When an API has such following troubles, the users will have difficulties to use this API:
Bad Learnability: Loose organization, bad logic, and other things to make API difficult to learn.
Bad Rememberability: A huge set of concepts or function lists will have the coders to search in the API document time by time.
Hard to write client codes
Hard to interpret client codes:
Frequent misuse: Bad naming and misunderstanding description may cause the coders to select the wrong function and get in troubles.
five major causes which lead to poor component API usability
Complex! : The number of functions exceed the need of users, and leads to the unnecessary complexity.
Too simple! : Only a few words for a very complex function will not help the coders at all.
Bad naming! : call1(), call2(), call3() are much more confused than callclient(), calladmin()…
Ignorance of caller’s perspective! : APIs should be designed from the perspective of the caller , otherwise it may loose usability.
Concept incorrectness! : If the definition itself is not correct, how can coders get correct function in this document?
five component API design tips to increase component API usability )
Easy to learn.
Easy to remember.
Easy write client code.
Easy to interpret client code.
Difficult to misuse.
Major Issues:
Define useful API’s characteristics: To define the key factors making API more helpful for coders .
Define usable API’s characteristics: To define the key factors making the API document better on easiness, Learnability and rememberability.
Making useful APIs: Follow the defined characteristics and make the APIs useful.
Making usable APIs: Follow the defined characteristics and make the APIs usable.
The factors affecting usable useful API: Check the defects of early design and optimize the document.
Difficulties:
When an API has such following troubles, the users will have difficulties to use this API:
Bad Learnability: Loose organization, bad logic, and other things to make API difficult to learn.
Bad Rememberability: A huge set of concepts or function lists will have the coders to search in the API document time by time.
Hard to write client codes
Hard to interpret client codes:
Frequent misuse: Bad naming and misunderstanding description may cause the coders to select the wrong function and get in troubles.
five major causes which lead to poor component API usability
Complex! : The number of functions exceed the need of users, and leads to the unnecessary complexity.
Too simple! : Only a few words for a very complex function will not help the coders at all.
Bad naming! : call1(), call2(), call3() are much more confused than callclient(), calladmin()…
Ignorance of caller’s perspective! : APIs should be designed from the perspective of the caller , otherwise it may loose usability.
Concept incorrectness! : If the definition itself is not correct, how can coders get correct function in this document?
five component API design tips to increase component API usability )
Easy to learn.
Easy to remember.
Easy write client code.
Easy to interpret client code.
Difficult to misuse.
2009年3月7日星期六
A Comparative Study: Component-based software engineering V.S. Service-oriented software engineering
A Comparative Study: Component-based software engineering V.S. Service-oriented software engineering
1 Project introduction 3
2 Component based software engineering 3
2.1 Definitions(Component based software engineering) 3
2.2 Concepts (Component, Module, Interface, Object) 3
2.3 Objectives 6
2.4 Benefits and disadvantages 6
2.5 Needs and Motivation 7
3 What is SOA-based software engineering? 7
3.1 Definitions 7
3.2 Concepts 8
3.3 Objectives 9
3.4 Benefits: 12
3.5 The future of SOA 13
4 What are the major differences and similarity between these two approaches? 15
5 What are the differences between service components and modern components? 20
5.1 What is service? 20
5.2 What is modern component? 21
6 Building SOA-based software system is same as building a component-based system using service components? 24
7 Tools and technologies for building service components 26
7.1 Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft 26
7.2 IBM Service Component Architecture Explorer Tool 26
8 Discussions and justification comments 27
8.1 What is SOA? Can we buy it? 27
8.2 What’s the base system of SOA? 27
8.3 How to design service contract? 28
9 A summary, conclusions, and future directions 31
Reference 32
1 Project introduction
There are people who start to accept the “new idea” and try to change their software product structure into component based, and there are also people who start to research on new concepts on software structure to replace the “nearly old fashioned and full of overestimate” – Service oriented architecture. Things might be worse under the current economic crisis as adopting new business architecture are lacking of funds, even some specialists pointed out “SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession” [1]. That’s the IT industry, which seems they never have the latest and the best technique in all kinds of areas.
Neutrally speaking, component based architecture is still enough for most of current requirements, despite of its “old” age of more than 20 years. And after the depression, SOA will still be the most prospective architecture within a few years, but there are already articles that doubt if SOA will be easily applied by most enterprises and easily get the expected positive results after applying SOA.
This paper will briefly compare component based software engineering and service oriented software engineering. The concepts, comparison, tools and methods will show how these two major software architectures play their roles in current enterprise software.
2 Component based software engineering
2.1 Definitions (Component based software engineering)
Component based software engineering (Abbreviation: CBSE), Component based development, Component based programming, are exactly the same thing in software industry. In Wikipedia, CBSE is defined as “a branch of the software engineering discipline, with emphasis on decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components”
This definition introduces the basic unit forming the CBSE – Component (Software component). The architecture is built by the relations between the components “decomposed” from the whole system. The interfaces enable these components communicate with each other and connected to form the whole system.
2.2 Concepts (Component, Module, Interface, Object)
To explain the concepts in component based software engineering and their functions, relationships, we would like to introduce a kind of toys which was very popular in our childhood – Electronic bricks, as the example. Each brick has outer plugs to be connected with other bricks, and have different functions: line, battery, bulb, diode… Under the instructions, players could build up a radio with easy functions or a speaker, etc.
Component
A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.[2] Clement Szyperski lists three major properties of software component: a unit of independent deployment ; a unit of third-party composition ; no observable state (Encapsulated).
Let’s consider the CBSE as a set of Electronic Bricks. Here is what a single brick is designed in this toy: An opaque plastic shell, with sockets in the bottom, and outlets in the top, and a kind of electronic component or a set of circuit inside. The sockets and outlets are used to connect with other bricks or the main board to install these bricks. Players could only see the corresponding electronic symbol instead of the inside structure of the brick.
Let’s conclude the properties of this brick and compare them with the properties of CBSE to get the ones of CBSE much clearer and organized:
Figure 1 “Electronic bricks” – Components
Unit of independent deployment: a brick is the basic unit of setup any kind of “product”, so do the software component.
Third-party composition: The players are not the producers of these electronic bricks.
Encapsulated: The players could not see the inside structure of the bricks. They can only judge the function of the brick by its electronic sign on the top.
Communicating with other components: A brick could connect to others with its sockets and outlets.
Multiple use (Reusable): These bricks could be used by many times to setup many kinds of products.
Component Interface
Return to the electronic bricks, the board which has specified placed outlets to install the bricks, is exactly playing the role of component interface.
Figure 2 “Bricks and board” - Components and interface
In CBSE, connecting and enable communication between components is not so easy as plug the bricks on the outlets. First of all, a good designed interface is required. An interface of software component could be defined as a specification of its access point.
The interface doesn’t offer any implementation of its operations, only provides the descriptions and protocols. Thus, it enables itself to replace implementation with interface changes, or add new interfaces and implementation without any change on implementation.
Other concepts
Patterns : a pattern defines a recurring solution to a recurring problem. It could be employed in the design and documentation of a software component. It could be used to describe the low-level implementation details of the behavior and structure of the components, or the relationships between components in the context of a particular programming language.
Component model: A component model defines a set of standards and conventions used by the computer developer, whereas a component framework is a support infrastructure for the component model.
2.3 Objectives
There comes out the question, what should CBSE do after they are applied? Why the definitions of CBSE are clinched to those principles? Let’s list out those obvious things which will benefit the whole software production.
First of all, under CBSE the components could be reused many times, the designers don’t need to mess with the inside code of the component, just get it, setup on the interface, and then connect them together. CBSE has very specified detail document to provide support for these operations so that the designers would not confuse on the component functions.
Thus, applying component based software engineering should have these objectives :
To reduce system production cost and time by reusing existing reusable and high quality components
To provide support for the development of systems as assemblies of components
To support the development of components as reusable entities
To facilitate the maintenance and upgrading of systems by customizing and replacing their components
2.4 Benefits and disadvantages
By achieving these goals, CBSE has several advantages towards the old software architectures:
a) Lead time reduced : by building applications from reusable components
b) Cost reduced : Multiple reusing components could save the cost of developing new components
c) Higher quality: more times a component has been used, more times it has been tested. Retesting is one of the most powerful methods to enhance coding quality.
d) Easy Maintenance: easy updating with simply replace the old version components by new version, which could also save the maintenance cost.
Of course, CBSE is not the answer to every problems in software designing, that’s why SOA is grabbing more and more users. Before we talk about SOA, let’s see what the things CBSE lacks of are.
e) Difficult specification: it’s not easy to specify component standards during first time design.
f) Lacks of ideal component models: there are still many existing component models which are incomplete, inconsistent, and have problems during deployment. In one word, they are not standardized.
g) Life cycle problems: As components are not observable, there will be more problems during independent component development process.
Production from scratch is a very expensive undertaking. Suboptimal solutions in all but the local areas of expertise are likely. Maintenance and “chasing” of the state-of-the-art, such as incorporating web access, can become a major burden. Interoperability requirements further the burden, with other in-house systems and, more critically, also with business partners and customers. As a result, most large projects fail partially or completely, leading to a substantial risk. [3]
2.5 Needs and Motivation
CBD claims include reductions both in development costs and time and the increase of the developed software system’s overall quality [4]. These improvements result from reuse: building software from existing well tested building blocks is more effective than developing similar functionalities from scratch. It is important to analyze the reuse related improvement achieved through CBD. The bulk of component related research has been mainly focused on the functionality and composability of components, as well as their specification. The research niche of component quality assessment, with an emphasis on quantitative approaches , is fairly unexplored. The few existing evaluations are performed at a qualitative level, which makes the assessment of the true impact of the above-mentioned claims harder. In our research, we are particularly interested in the quantitative evaluation of software components and their impact on the systems they are integrated in.
3 What is SOA-based software engineering?
3.1 Definitions
It is hard to find an exact definition of the term SOA. The problem is not that there aren't any definitions; the problem is that there are many different definitions. To give you an idea of how they are similar and dissimilar, a selection of published definitions are sidebars in this chapter. You'll find some common phrases and attributes as you read them, but you will also find a lot of differences in the context, level of abstraction, and wording [5].
However, at least all definitions agree that SOA is a paradigm for improved flexibility. Here are some definitions
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
- OASIS (the Organization for the Advancement of Structured Information Standards)
In computing, service-oriented architecture (SOA) provides methods for systems development and integration where systems group functionality around business processes and package these as interoperable services. An SOA infrastructure allows different applications to exchange data with one another as they participate in business processes. Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. [6] SOA separates functions into distinct units, or service [7]. which developers make accessible over a network in order that users can combine and reuse them in the production of business application [8]. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.
- Wikipedia
SOA is not a concrete architecture: it is something that leads to a concrete architecture. You might call it a style, paradigm, concept, perspective, philosophy, or representation. That is, SOA is not a concrete tool or framework you can purchase. It is an approach, a way of thinking, a value system that leads to certain concrete decisions when designing a concrete software architecture.[9]
3.2 Concepts
Here are the key technical concepts of SOA that allow it to cope with the system characteristics just described [10]:
Services
Software development is the art of abstraction. We have to abstract reality in such a way that only the relevant aspects of a problem are handled. However, we all know that we can abstract from different perspectives. SOA aims to abstract by concentrating on the business aspects of a problem. The fundamental term introduced here is service. In essence, a service is an IT representation of some business functionality. The goal of SOA is to structure large distributed systems based on the abstractions of business rules and functions.
This gives a clear structure to the IT systems we design and develop. Although internally they are, of course, technical systems, the external interfaces should be designed in such a way that business people can understand them. Externally, you should not see the technical details. The smart consequence of this approach is that at this level of abstraction, platform-specific details don't matter. Thus, platforms can be heterogeneous.
Besides this broad definition, it is not clear what exactly a service is or can be. There are very different opinions about the exact attributes a service must, can, or should have. I will discuss services in detail in the next chapter (presenting several different existing definitions for services as well). As a rule of thumb, however, you can consider a service to be the IT representation of self-contained business functionality, such as "create a customer," "get a customer's contracts," "transfer money," "turn on the radio," "calculate the best route for my car," and so on.
Interoperability
With heterogeneous systems, the first goal is to be able to connect those systems easily. This is usually called "high interoperability." High interoperability is not a new idea. Before SOA, we had the concept of enterprise application integration (EAI), and regarding interoperability, SOA is nothing new.
However, for SOA, high interoperability is the beginning, not the end. It is the base from which we start to implement business functionality (services) that is spread over multiple distributed systems.
Loose coupling
As I've already mentioned, we live in a world ruled by marketing guys. We don't always have time to analyze, design, and implement carefully. We need fast times to market, so flexibility is often valued over quality. This leads to several problems.
Consider that at the same time we are integrating more and more systems, and implementing business processes by distributing them over different systems. In principle, data flows in such a way that processes run successfully in all the affected systems: we create a customer in all our systems, transfer money from one system to the other, or process a customer's order by shipping a product and sending a bill.
3.3 Objectives
The upcoming set of sections describes each of these strategic goals:
Overall goals [11]:
Increased Intrinsic Interoperability
Interoperability refers to the sharing of data. The more interoperable software programs are, the easier it is for them to exchange information. Software programs that are not interoperable need to be integrated. Therefore, integration can be seen as a process that enables interoperability. A goal of service-orientation is to establish native interoperability within services in order to reduce the need for integration.
Increased Federation
A federated IT environment is one where resources and applications are united while maintaining their individual autonomy and self-governance. SOA aims to increase a federated perspective of an enterprise to whatever extend it is applied. It accomplishes this through the widespread deployment of standardized and composable services each of which encapsulates a segment of the enterprise and expresses it in a consistent manner.
Increased Vendor Diversification Options
Vendor diversification refers to the ability an organization has to pick and choose “best-of-breed” vendor products and technology innovations and use them together within one enterprise. It is not necessarily beneficial for an organization to have a vendor-diverse environment; however, it is beneficial to have the option to diversify when required. To have and retain this option requires that its technology architecture not be tied or locked into any one specific vendor platform (Figure 3).
Figure 3 A service composition consisting of three services.
Increased Business and Technology Domain Alignment
The extent to which IT business requirements are fulfilled is often associated with the accuracy with which business logic is expressed and automated by solution logic. Although initial application have traditionally been challenging to keep applications in alignment with business needs when the nature and direction of the business changes.
Service-oriented computing introduces a design paradigm that promotes abstraction on many levels. One of the most effective means by which functional abstraction is applied is the establishment of service layers that accurately encapsulate and represent business models. By doing so, common, pre-existing representations of business logic can exist in implemented form as physical services
System goals [12]:
Flexibility
Scalability
Fault tolerance
The key to fulfilling these goals is loose coupling. Loose coupling is the concept of minimizing dependencies. When dependencies are minimized, modifications have minimized effects, and the systems still runs when parts of it are broken or down. Minimizing dependencies contributes to fault tolerance and flexibility, which is exactly what we need.
In addition, loose coupling leads to scalability. Large systems tend to challenge limits. Therefore, it is important to avoid bottlenecks; otherwise, growing might become very expensive. Avoiding bottlenecks is important from both a technical and an organizational point of view. All large systems only work if the usual business can be done in as decentralized a manner as possible. One way to introduce loose coupling is to avoid introducing any more centralization than is necessary (unfortunately, you need some centralization to establish SOA because you need some common base).
Needs:
Having read that the key technical concepts for SOA are services, interoperability, and loose coupling, you might conclude that all you have to do to enable SOA is to introduce services, interoperability, and loose coupling [13]:.
But as I stated earlier, you can't buy SOA. What's important is that you introduce these concepts in the appropriate fashion. That is, you have to find the right degree of centralization, you have to set up the corresponding processes, and you have to do your homework. A lack of these "ingredients" is what I most often find as the problem in real SOA projects. To establish SOA successfully, you have to care for your infrastructure, architecture, and processes (including the metaprocess, governance).
Infrastructure
Infrastructure is the technical part of SOA that enables high interoperability. The infrastructure of a SOA landscape is called an enterprise service bus (ESB). This term is taken from enterprise application integration, where it was called the EAI bus or just enterprise bus.
The key feature of the ESB is that it enables you to call services between heterogeneous systems. Its responsibilities include data transformation, (intelligent) routing, dealing with security and reliability, service management, monitoring, and logging.
Architecture
Architecture is necessary to restrict all the possibilities of SOA in such a way that it leads to a working, maintainable system. SOA concepts, SOA tools, and SOA standards leave room for specific decisions that you must make in order to avoid a mess. You have to classify different types of services, you have to decide on the amount of loose coupling, you have to restrict the data model of service interfaces, you have to define policies, rules, and patterns, you have to clarify roles and responsibilities, you have to decide on the infrastructure technology, you have to decide which (version of) standards to use, and so on.
Processes
One thing that makes large systems complicated is that many different people and teams are involved in them. As a consequence, it is a long path from an initial business idea or requirement to a solution running in production mode.
Governance
The metaprocess of all processes and a SOA strategy as a whole is governance. You have to set up the right process to establish SOA in your organization. This includes finding the right people who are able to combine all the different SOA ingredients to create a result that works and is appropriate. There is usually a central team (sometimes called the SOA competence center) that deals with infrastructure, architecture, and processes. This team is also responsible for establishing a common understanding, and doing the homework right. This requires management support, because in addition to time and resources, courage is required to deal with the organizational impacts of SOA Understanding, governance, management support, and homework are key factors for the success of SOA.
3.4 Benefits:
[14] An SOA can be evolved based on existing system investments rather than requiring a full-scale system rewrite. Organizations that focus their develop¬ment efforts around the creation of services, using existing technologies, combined with the component-based approach to software development will realize several benefits.
Leveraging existing assets. This benefit is the first, and most important, of the requirements discussed earlier in this paper. You can construct a business service as an aggregation of existing components, using a suitable SOA framework and made available to your enterprise. Using this new service requires knowing only its interface and name. The service’s implementation specifics (such as its component architecture) or discrete functional components—as well as the complexities of the data flow through the components that make up the service—are transparent to callers. This component anonymity lets organizations leverage current investments, building services from a conglomeration of components built on different machines, running different operating systems, developed in different programming languages. Legacy systems can be encapsulated and accessed using Web services interfaces. More important, legacy systems can be transformed, adding value as their functionality is transformed into services.
Infrastructure as a commodity. Infrastructure development and deployment will become more consistent across all your different enterprise applications. Existing components, newly developed components and components purchased from a range of vendors can be consolidated within a well-defined SOA framework. Such an aggregation of components will be deployed as services on the existing infrastructure. As a result, the underlying infrastructure becomes more of a commodity. Over time, as services become more loosely coupled from the supporting hardware, you can optimize the hardware because the service assembler is no longer dependent upon the hardware environment on which the service operates at run time.
Faster time-to-market. Organizational Web services libraries will become your organization’s core assets as part of your SOA framework. Building and deploying services with these Web services libraries will reduce your time to market dramatically, as new initiatives reuse existing services and components, reducing design, development, testing and deployment time in the process. As services reach critical mass in your organization or trusted network, the larger ecosystem emerges — enabling you to assemble composite applications using services, rather than developing custom applications.
Reduced cost. As business demands evolve and new requirements are introduced, the cost to enhance and create new services by adapting the SOA framework and the services library, for both existing and new applications, is greatly reduced. The learning curve for the development team is reduced as well, as they may already be familiar with the existing components.
Risk mitigation. Reusing existing components reduces the risk of introducing new failures into the process of enhancing or creating new business services. You will also reduce the risk in the maintenance and management of the infrastructure supporting the services.
Continuous business-process improvement. An SOA allows a clear representation of process flows identified by the order of the components used in a particular business service—and provides business users with an ideal environment for monitoring business operations. Process modeling is reflected in the business service. Process manipulation is achieved by reorganizing the pieces in a pattern (components that constitute a business service). This function allows you to change the process flows while monitoring the effects to facilitate continuous improvement.
3.5 The future of SOA
So far, this white paper discussion centers around the need to increase speed of business changes, and to improve business performance and efficiency. These requirements mandate a set of IT imperatives for flexibility where SOA becomes a key enabler. But what if a completely new model for application development emerges? Will the notion of an SOA still be meaningful or required? The answer is a resounding, yes. Two new, emerging concepts are beginning to be implemented: grid computing and on demand computing. While these models are distinct and have developed separately, they are closely related; and each makes the evolution to SOA even more imperative. Representing every application, resource or business capability as a service with a standardized interface allows you to quickly combine new and existing applications to address changing business needs and improve operational effectiveness — the essence of SOA. As a result, SOA becomes the DNA of grid computing and on demand computing.
Grid computing
An in-depth discussion of grid computing is beyond the scope of this paper, but a couple of points are worth mentioning. First, grid computing is much more than just the application of large numbers of millions of instructions per second (MIPS) to effect a computing solution to a complex problem. It enables you to divide resources into multiple execution environments by applying one or more concepts, such as hardware or software partitioning, or time-sharing, machine simulation, emulation and quality of service. This virtualization, or on demand deployment, of all your distributed computing resources lets you use them wherever and however they are needed within the grid. Virtualization is simply a form of resource management for devices, storage, applications, services or data objects. Hence, applying SOA allows you to maximize resource utilization in a grid environment. You can deploy and migrate a services ecosystem onto appropriate nodes in a grid environment to respond efficiently to changes in your internal and external business environment.
On demand computing
An in-depth discussion of on demand computing is also beyond the scope of this paper. But, again, SOA can be an essential prerequisite for on demand computing. SOA is an enabling architecture for on demand applications. Thus, applications must operate in an SOA to realize the benefits of on demand. Web service is an enabling technology for SOA. As a subset of on demand computing, Web services on demand is simply business services exposed using Web services standards.
On demand computing can cover a wide spectrum. One end of this spectrum focuses on the application environment; the other end focuses on the operating environment, which includes items like infrastructure and autonomic computing. Transforming your business means leveraging both the application and operating environments to create an on demand business. At the heart of your on demand business will be business services on demand where application-level services can be discovered, reconfigured, assembled and delivered on demand, with just-in-time integration capabilities.
The promise of Web services as an enabling technology is that it will enhance business value by providing capabilities such as services on demand, and over time, will transform the way IT organizations develop software. It could even transform the way business is conducted and the way you offer your products and services over the Web to your entire value chain. What if all of your applications shared the same transport protocol? What if they all under¬stood the same interface? What if they could participate in, and understood, the same transaction model? What if this were true of your partners? Then you would have applications and an infrastructure to support an ever-changing business landscape—and you would have become an on demand business. Web Services and SOA can make this possible for applications.
4 What are the major differences and similarity between these two approaches?
The increased speed and scale of IT-enabled processes has been met with a proportional increase in the demand to modify processes to meet changing conditions. IT has accelerated the speed at which citizens, businesses, and organizations both operate and change.
The major difference between Component-Based Engineering and Service-Oriented Engineering is different architecture, for different needs of customers, the fundamental shift that will allow these visions to be realized is a move to Service Component-Based Architecture (SCBA). Today, the IT industry has generally accepted Service Oriented Architecture (SOA) as the most promising architectural approach to-date. SCBA complements traditional SOA approaches and is designed to provide an optimal, long-term service-oriented approach aligned with the FEA that recognizes the value of component-based service delivery. SCBA builds upon SOA in three key ways:
• it is tightly integrated with the Federal Enterprise Architecture,
• it provides a description of what the architecture is (a collection of services designed and implemented to achieve an organization’s mission)
• It identifies the organizational, cultural, and process elements, as well as technological elements, that need to exist for these architectures to be successful.
SCBA also treats business processes and the IT systems in the same way, allowing both to be reused across organizations. In order for a business process or technical system to be a “Service Component,” and thus participate in the overall architecture, it must offer a well-defined interface with well-defined functionality. These two characteristics represent the minimum criteria needed for a business process or technical system to be reused. Service Components are intended be a subset of the “components” defined in the FEA SRM. The SRM does not require rigorous interface or functionality descriptions, only systems and processes with these descriptions are both SRM Components and SCBA Service Components. SCBA attempts to realize the potential of the SRM by requiring that business processes and IT systems be designed or modified to make them easy to reuse. Later sections of this document will describe SCBA in further detail.
In the mid-90s, an additional development emerged: component based development (CBD). CBD takes the concept of abstraction in a new direction. Rather than reducing lines of code, CBD separates various aspects of the functionality into isolated units that can be produced and managed independently of the other aspects. This again allows a developer or consumer of the functionality to deal with one aspect at a time – ignoring the other aspects. In a component-based architecture the various aspects are organized into layers, most commonly: presentation, orchestration, business logic, data management, security, and infrastructure.
Service-oriented architecture represents a generalization of the component model by dealing directly with what is offered, rather than how it is packaged. The tiered architecture enables components to be easily incorporated in solution architectures. The evolution of services standards (e.g., WSDL, UDDI, and SOAP) and the maturity of distributed computing architectures (e.g., Java Enterprise Edition and .Net) have enabled "single-copy reuse" via shared services. Thus, SOA is a tiered framework that empowers solution developers to employ abstraction techniques, at all architectural tiers, without having to struggle with many of the interoperability and multiple implementation challenges faced by previous generations of reuse proponents. The future of software development will likely consist of complete assembly of applications from services and components – often referred to as “true software manufacturing.”
Figure 4 Evolution of Reuse in Software Development
Software components are units of software that provide business or technical functionality. These units are independently deployable; that is, they are self-contained and can be deployed virtually anywhere on the network. Business components execute business logic, enforce business rules, and manage corporate data. Technical components provide the platform or infrastructure capabilities that the business components rely on such as messaging, error handling, security, etc.
Components
Software components are the reusable building blocks for application development. A software component typically consists of: (1) a specification (process and data model representing the user or consumer’s view) that defines what the component does, (2) an implementation which is the internal design for the component, (3) an executable (run-time) module that gets deployed, (4) one or more interfaces that provide access to the component’s functionality. The key concept behind components is that the implementation is hidden behind the interface – the consumer of the component does not need to know the details of the implementation to exploit the capabilities offered. Thus, in general components are an approach to provisioning capabilities that are highly flexible. Component-based reuse is illustrated in Figure 5.
Figure 5 Illustration of Component-Based Reuse
Services
Services are focused on satisfying business or technical requirements based on a provider/consumer model. Services represent a broader concept than components. They are the activities executed in response to a request (or an event) in order to deliver some result. Both concepts employ the notion of an interface that defines the set of activities (or services) offered. However, whereas all components offer functionality as services, not all services are implemented as components. Figure illustrates the distinction between services and components – services are driven from business requirements, whereas components are a method of providing services. For example, one way to implement a service is to put an interface on some legacy functionality. The legacy system may be very unstructured (and not divided into independent components), yet the interface may offer the services required by other and new applications. As discussed in the roadmap section below, creating interfaces to access services from legacy systems is one common way to begin to implement an SOA.
Figure 6 Differences between Services and Components
Services and components enable reuse, although with slightly different twists. Components are typically designed to be redeployed or integrated into multiple different applications. In fact, commercial-off-the-shelf (COTS) components are typically licensed to be embedded in applications. Reuse is achieved by producing multiple instances of the component and building them into applications. Services can be exploited in this way, but also offer the possibility of shared-services – running a single instance of a service that can be called by other applications across the network, as shown in figure 6.
An important additional concept is service discovery, or the ability to find (either manually at design-time or automatically at run-time) and access existing services. Many technologies exist today that enable this, and a coordinated strategy for identifying and categorizing services across the enterprise is critical. In the Federal government, the FEA provides the first step in implementing this strategy. Since services may be thought of as an abstraction of components, it is not too difficult to consider them both when describing reusable government-wide assets.
Figure 7 Illustration of Service-Based Reuse
A summary of the key concepts in CBSE and SOSE is listed in Table 1.
Table 1 Comparison of key concepts in CBSE and SOSE Concepts CBSE SOSE
Concepts CBSE SOSE
Module Component Service
Specification Component Contract Service description
Interface Component interface Service interface
Assembly Component
composition Service
composition
Module.
In CBSE, components are the building blocks that can be deployed independently and are subject to composition by third party [10]. Based on the formulation by Clemens Szyperski [7], a software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. It can be both fine-grained providing specific functionality and coarse-grained encompassing complicated logics.
In SOSE, services are the building blocks that can be reused and offer particular functionalities. They are generally implemented as coarse-grained discoverable software entities [6], operating on larger data sets, encapsulating business functionality and exposing the functionality to any source that requests the functionality through well-defined interfaces. Thus, the services can be reused and accessed at various levels of the enterprise application and even across enterprises boundaries.
Specification.
In CBSE, the component specification provides for the clients the definition of the component’s interface, i.e. the operations and context dependencies. Furthermore, an abstract definition of the component’s internal structure is specified for the component providers [10].
In SOSE, the service description is a service contract that advertises the following information: (i)service capabilities - stating the conceptual purpose and expected results of the service; (ii) interface - describing the service signatures of a set of operations that are available to the service requester for invocation; (iii) behavior - describing the expected behavior of a service during its execution; and (iv) quality - describing important functional and nonfunctional service quality attributes [9].
Interface.
Although both CBSE and SOSE are interface-based in the sense that interfaces are the specifications of access points, the separation between service descriptions and service implementation is more explicit than the separation between component specification and implementation.
Assembly.
In CBSE, component composition is the process of assembling components using connectors or glue code to form an assembly, a larger component or an application. The components are assembled through the component interfaces and the composition is made out of several component instances that are connected and interact together.
In SOSE, the composite services are built by composing service descriptions. The realization of the service composition is during run time when the service providers are discovered and bound.
Table 1 Summary of similarities and differences of CBSE and SOSE
CBSE SOSE
Process Building system from preexisting components.
Separate development process
of components and system.
More activities involved in design time Building systems from pre-existing services.
Separate development process of services and system. More activities involved in run time
Technology Constrained by component models. Ranging from white box, gray box to black box. Static and dynamic binding between components. Dynamic discoverability is not a major concern Platform independency. Black box. Only dynamic binding between services. Dynamic discoverability
Quality Interoperability concern between heterogeneous components. Achieve component substitutability through explicit specifications. Better predictability Interoperability through universally accepted standards. Achieve service substitutability through service descriptions.
Predictability issue
Composition Homogenous composition. Design time and run time composition and design time composition allows for optimization. Pipe and filter; event mechanism etc. Composition is made out of several component instances Heterogeneous composition. Services are composed at run time.
Pipe and filter; orchestration etc.
Composite services are built by composing service descriptions
5 What are the differences between service components and modern components?
5.1 What is service?
The OASIS SOA Reference Model states [14]:
The noun "service" is defined in dictionaries as "The performance of work (a function) by one for another."
This can mean everything or nothing. As with the term SOA, it is hard to find an exact, useful definition of the term "service" because so many definitions exist. Again, I have collected some of these definitions. You'll find some common phrases and attributes as you read them, but you will also find a lot of differences in the context, level of abstraction, and wording.
SOA is focused on business processes. These processes are performed in different steps (also called activities or tasks) on different systems. The primary goal of a service is to represent a "natural" step of business functionality. That is, according to the domain for which it's provided, a service should represent a self-contained functionality that corresponds to a real-world business activity. In other words, business people should be able to understand what a service does [6].
Services exist as physically independent software programs with distinct design characteristics that support the attainment of the strategic goals associated with service-oriented computing. Each service is assigned its own distinct functional context and is comprised of a set of capabilities related to this context [10].
5.2 What is modern component?
Let us review some of the important definitions of software components given by the experts. One of the earliest definitions is given by Gready Booch [15]:
A reusable software component is a logically cohesive, loosely coupled module that denotes a single abstraction.
This definition captures the idea that a reusable component is an encapsulated software module consisting of closely related component elements. Later, Clement Szyperski presented his well-known definition of a software component at the 1996 European Conference on Object-Oriented Programming [16]:
A software component is a unit of composition with contractually specified interfaces and context dependencies only. A software component can be deployed independently and is subject to composition by third parties.
This definition is well accepted in the component-based software engineering community because it highlights the major properties of software components that are not addressed in traditional software modules, such as context independence, composition, deployment, and contracted interfaces. In 2000, a broader, more general notion of software components was defined by Alan W. Brown [17]:
An independently deliverable piece of functionality providing access to its services through interfaces.
A similar idea is also expressed in the unified modeling language (UML) definition [18]:
A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.
Recently, Bill Councill and George T. Heineman gave a new definition to emphasize the importance of a consistent component model and its composition standard in building components and component-based software [19]:
A software component is a software element that confirms to a component model and can be independently deployed and composed without modification according to a composition standard.
To simplify the concept of software components, we classify the notion of software components into three types: (1) reusable modules, (2) reusable components, and (3) composite building blocks [20].
A reusable module is an independent and deliverable software part that encapsulates a functional specification and implementation for reuse by a third party.
A reusable component is an independent, deployable, and replaceable software unit that is reusable by a third party based on the unit’s specification, implementation, and well-defined contracted interfaces.
A composite building block is a reusable component that is developed as a building part to conform a well-defined component model and the accompanying composition standards.
The differences between service components in SOA and modern components in CBSE.
Comparison in properties[16], [6], [20].
Table 2 Comparison in properties
Properties Software Components in CBSE Services in SOA
Encapsulation: Each component encapsulates a set of closely related data elements and implements coherent functional logic to perform a specific task. Services are abstractions that hide implementation details from the consumers.
Stateless Sometimes, the components are stateful, sometimes are stateless. Sometimes, services are defined as being (ideally) stateless.
Reusable Reusability of software components is the key to the success of component-based software engineering. SOA leads to better reusability because all systems that need a certain functionality just call the same one.
Composable Components are composite if they are developed based on a standard composition method to support component composition. Kinds of business functionality can be broken into smaller steps, which are themselves services.
Vendor-Diverse Hard to reach Vendor- Diversification. Because there maybe some different frameworks or languages among components which are hard to be cohesive systems are usually very heterogeneous. Being able to use different platforms and different products for implementing services.
Interoperable Components are interoperable if they are developed based on standard communication channels and data exchange mechanisms defined in a component model. High interoperability is a core requirement of SOA. In the sense that services can be called from any other systems, they are inherently interoperable.
Independency Software components must be delivered as independent parts that can be replaced under certain conditions. The goal is to minimize dependencies so that a SOA is appropriate for distributed systems with different owners.
Contract-based interfaces An interface between software components defines a contract between the client of an interface and a provider of an implementation for the interface. Communication among services components is based on service contract which is implemented by Web service at the most time.
Deployable Software components are known as deployable if a well defined
deployment approach has been built inside a component to support its deployment Service components are deployable if service contracts among them are well developed to support them for working together.
From the comparison in properties we could infer that:
i. There are some excellent properties the two shard, they are: Encapsulation Composable, Reusable, Interoperable, Independency, Contract-based interfaces and Deployable.
ii. Obviously there are some differences between them including: Status, Vendor-Diverse.
Comparison in different perspectives
Table 3 Comparison in different perspectives
Perspectives Software Components in CBSE Services in SOA
Base units of system Component-based system consists of composite components. System based on SOA is comprised of composite services.
Component design Component selection, creating, evaluation and testing. Service connection, creation, evaluation and testing.
Contract design Function implementation à Interface connection. Interface design à Function implementation.
Implemented by Various programming languages, frameworks and technologies or something like that is permitted. Mainly Web Service and related technologies.
Development process A dedicated component engineering process is in place to control and manage the construction of components. A service-oriented development process is used to control and manage module development.
Reuse scopes Large reuse scopes encompassing different projects, product lines, organizations or even the programming endeavors of the general public. Reuse of almost every service in the system and the scope of services could be extended by plug-in other services following the same standards.
From the comparison in different perspectives we could infer that:
i. These two design paradigms are all based on reusable, independent, interoperable component. One is software component, the other the service.
ii. Connections among the components are contracts. However the design processes is different, or we could say they are inverse.
iii. They have large scale of reuse and reach a high level of flexibility and interoperability.
iv. Different components are implemented by various technologies.
6 Building SOA-based software system is same as building a component-based system using service components?
I think there are no large differences of the lifecycles between them. We can assume that the service is definitely a unit in the system, like a component, too. Therefore, actually, we are able to adopt the lifecycle processing of component based system which will work effectively in service-oriented system too. There are some effective lifecycle models of component-based system, such as, V development process, Y development process and component-based waterfall development process. Obviously they are suitable for SOA-based software system design. The only potential variations between them are the unit – one is the component, the other the service, and in detail, is the phase of integration of units.
The main emphasis is put on component selection and its integration into the system. This process can require additional efforts. First the selection process should ensure that appropriate components have been selected with respect to their functional and extra-functional properties. This requires verification of the component specification, or testing of some of the component’s properties that are important but not documented. Second, it is a well known fact [8] that even if isolated components function correct, an assembly of them may fail, due to invisible dependencies and relationships between them, such as shared data shared resources. This requires that components integrated in assemblies are tested before they are integrated into the system. At last, the combination of these assemblies must be testes again, since all combined assemblies of correct ones maybe incorrect although the assembly oneself are correct [7].
One of the main reasons is that Particular component model requires a particular architectural framework, and the application is supposed to use this framework. This directly has impact on architectural decisions. For example if the component model requires a client-server architecture style, it is obvious that the application will use that style and not another (for example pipe-filter) [12]. This will put limitations on the system design.
Things seem better in SOA based architecture. Because avoiding normal data transmission among components, we only need to transfer an XML info, which is carried by SOAP and Http, for them to communicate. The pattern of XML info complies a standardized principle. Therefore we are easier to control transmission among different services. In this way, consideration about frameworks like we should consider in the component-based system is not necessary in that no matter what inner framework it is, the output and input is always the standardized XML (Figure 8). Services could send and receive them easily.
However, all these are based on well developed service contracts. Before the information sent out by service, it has to be translated via specific service contract. Then all the information are definitely in a same, concrete and standardized pattern, which will certainly improve the overall effectiveness of the system, because of the time of transformation has been saved.
Figure 8 Role of Web service and service contracts and their relationship.
7 Tools and technologies for building service components
7.1 Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft
In computer programming, a Visual Basic Extension (commonly abbreviated VBX) or custom control was the component model used in Microsoft Visual Basic versions 1.0 to 3.0. It is still supported in the 16-bit version of version 4.0, but was made obsolete by OCXs. VBX has also been supported in some versions of Borland Delphi.
The VBX specification was created so that developers could extend Visual Basic. According to rumor, Bill Gates reviewed the first version of Visual Basic before release and told the development team that it must have an extensibility mechanism. Since at the time Visual Basic was an interpreted language with limited power compared to C, VBXs which were most often written in C or C++ provided the ability to create very powerful and efficient software which could easily be hooked up to form based user interfaces.
Visual Basic 4.0 added support for the newer OLE Controls or OCXs (which became ActiveX controls), implicitly deprecating VBX controls. OCXs are based on the Component Object Model.
Each version of Visual Basic has come with many controls. By incorporating VBX controls into Visual Basic, Microsoft spawned the first commercially viable market for reusable software components. Third parties have created a large market of custom controls for resale.
VBX components were called "custom controls" because the Microsoft development team envisioned them as visual "control" components like a toggle switch or button. Enterprising third party software component developers saw opportunities to use the VBX specification for non-visual components, such as components for creating ZIP files, manipulating low-level system settings and communicating with TCP/IP.
7.2 IBM Service Component Architecture Explorer Tool
A metadata explorer that presents information about the service component architecture (SCA) services available in a given WebSphere Enterprise Service Bus server or WebSphere Process Server.
SCA Explorer presents information about the SCA services available in a given WebSphere® Enterprise Service Bus (ESB) server or a WebSphere Process Server (WPS). This information includes details such as how to locate and invoke such services (for example, when developing a new application that intends to re-use existing services in the enterprise).
SCA Explorer presents a Web page with tree widgets that allow the user to select an SCA module and "drill down" to see the components inside, their available interfaces, the operations available on such interfaces, the structure of the input and output Service Data Objects (SDOs), and any exceptions that can be raised by such operations. SCA Explorer also displays information about the imports, exports, and references used by such services; binding information, such as EJB JNDI names (Enterprise Java Beans, Java Naming and Directory Interface), Web service ports and endpoints, resource adapters, Java Message Service (JMS) destinations, etc.; and information about the implementation of such services.
With SCA, metadata is expressed via the Service Component Definition Language (SCDL), and an SPI exists that allows one to query this SCDL information. SCA Explorer is a JSP (Java Server Pages)-based application that demonstrates the use of this SPI to obtain information about the available SCA services and display it via HTML. Also included is a command line J2SE version that prints the same information to System.out and a command line tool that uses Eclipse Modeling Framework (EMF) to generate an XML file containing such information. [5]
8 Discussions and justification comments
8.1 What is SOA? Can we buy it?
SOA is not a concrete architecture: it is something that leads to a concrete architecture. You might call it a style, paradigm, concept, perspective, philosophy, or representation. SOA establishes an architectural model that aims to enhance the efficiency, agility, and productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realization of strategic goals associated with service-oriented computing [5]. Therefore, SOA is not a concrete tool or framework you can purchase. It is an approach, a way of thinking, a value system that leads to certain concrete decisions when designing concrete software architecture.
This aspect of SOA has a very important consequence: you can't buy SOA. There is no tool or recipe you can use to make everything work. While applying this paradigm to your concrete situation, you must make specific decisions that are appropriate for your circumstances [11].
8.2 What’s the base system of SOA?
Of course, flexibility is dealt with very differently on different layers and in different components. So, one important question is which kinds of software systems this paradigm is appropriate for. As it turns out, SOA copes well with many difficult-to-handle characteristics of large systems [1].
Distributed Systems
As businesses grow, they become more and more complex, and more and more systems and companies become involved. There is constant integration and constant change. SOA is well suited to dealing with complex distributed systems. According to the OASIS SOA Reference Model (see [OasisSoaRM06]), it is a paradigm for "organizing and utilizing distributed capabilities."
SOA allows entities that need certain distributed capabilities to locate and make use of those capabilities. In other words, it facilitates interactions between service providers and service consumers, enabling the realization of business functionalities.
Different Owners
The OASIS SOA Reference Model's definition of SOA continues by stating that those distributed capabilities "may be under the control of different ownership domains." This is a very important point that is often suppressed in SOA definitions. You won't find it in any of the other definitions quoted in this chapter, but it is the key for certain properties of SOA, and a major reason why SOA is not only a technical concept.
SOA includes practices and processes that are based on the fact that networks of distributed systems are not controlled by single owners. Different teams, different departments, or even different companies may manage different systems. Thus, different platforms, schedules, priorities, budgets, and so on must be taken into account. This concept is the key to understanding SOA and large distributed systems in general.
Heterogeneity
Another very important difference between small and large systems is the lack of harmony. We all know this from experience (although we might not agree about whether it's a natural phenomenon or the result of bad design). Large systems use different platforms, different programming languages (and programming paradigms), and even different middleware. They are a mess of mainframes, SAP hosts, databases, J2EE applications, small rule engines, and so on. In other words, they are heterogeneous.
In the past, a lot of approaches have been proposed to solve the problem of integrating distributed systems by eliminating heterogeneity: "Let's harmonize, and all our problems will be gone," "Let's replace all systems with J2EE applications," "Let's use CORBA everywhere," Let's use MQ series," and so on. But we all know that these approaches don't work. Large distributed systems with different owners are heterogeneous. This is a fact, and therefore something we must accept when designing large distributed solutions.
8.3 How to design service contract?
It is worth singling out Decoupled Contract at this stage because a Web service contract is essentially an implementation of this pattern. When building services as Web service. Service contracts are positioned as physically separate parts of the service architecture (Figure 9). This allows us to fully leverage the technologies to design and develop these contracts independently from the logic and implementations they will eventually represent.
Figure 9 The Web service contract is a physically separated part of a Web service implementation.
To design and develop service contracts is a huge project. So let’s introduce it briefly.
A service contract needs to have the following components [13]:
• Header
o Name - Name of the service. Should indicate in general terms what it does, but not be the only definition
o Version - The version of this service contract
o Owner - The person/team in charge of the service
o RACI
Responsible - The role/person/team responsible for the deliverables of this contract/service. All versions of the contract
Accountable - Ultimate Decision Maker in terms of this contract/service
Consulted - Who must be consulted before action is taken on this contract/service. This is 2-way communication. These people have an impact on the decision and/or the execution of that decision.
Informed - Who must be informed that a decision or action is being taken. This is a 1-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action.
o Type - This is the type of the service to help distinguish the layer in which it resides. Different implementations will have different service types. Examples of service types include:
Presentation
Process
Business
Data
Integration
• Functional
o Functional Requirement (from Requirements Document) - Indicates the functionality in specific bulleted items what exactly this service accomplishes. The language should be such that it allows test cases to prove the functionality is accomplished.
o Service Operations - Methods, actions etc. Must be defined in terms of what part of the Functionality it provides.
o Invocation - Indicates the invocation means of the service. This includes the URL, interface, etc. There may be multiple Invocation paths for the same service. We may have the same functionality for internal and external clients each with a different invocation means and interface. Examples:
SOAP
REST
Events Triggers
• Non-Functional
o Security Constraints - Defines who can execute this service in terms of roles or individual partners, etc. and which invocation mechanism they can invoke.
o Quality of Service - Determines the allowable failure rate
o Transactional - Is this capable of acting as part of a larger transaction and if so, how do we control that?
o Service Level Agreement - Determines the amount of latency the service is allowed to have to perform its actions
o Semantics - Dictates or defines the meaning of terms used in the description and interfaces of the service
o Process - Describes the process, if any, of the contracted service
One of the most challenging questions for component based software engineering is that, has CBSE really been out-fashioned? This could be separated into several sections :
Could SOA solve all the disadvantages of CBSE?
If so, is the cost acceptable?
Are those disadvantages really defective enough to have the users changing the system into new one with SOA?
9 A summary, conclusions, and future directions
For components to be independently deployable, their granularity and mutual dependencies have to be carefully controlled from the outset. For large systems, it becomes clear that components are a major step forward from objects (classes). This is not to say that objects are to be avoided. On the contrary, object technology, if harnessed carefully, is probably one of the best ways to realize component technology. In particular, the modeling advantages of object technology are certainly of value when constructing a component. On the flip side, modeling of component-based systems is still a largely unsolved problem, although there have been some recent inroads (for example, D’Souza and Wills, 1999, and Cheeseman and Daniels, 2000). UML, for instance, is still ill equipped to model component-based designs, though improvements in this area are one of the major goals for the UML 2.0 definition (still in its early phases in early 2002). Under the constant pressure of Moore’s law, the world of software has been expanding to take advantage of exponentially more powerful hardware resources. The resulting solutions reach into ever more areas of business and society, leading to new requirements, new markets, and new overall dynamics at a rapid pace. Software technology responded with a very dynamic evolution. However, components are hard to establish in a world of extreme dynamics. While much in the world of software needs to continue to progress rapidly, certain aspects need to evolve more gradually at a more controlled pace. These include the foundations of software components, including component models and basic technologies. The significant market advantage that can be gained from having third-party component backing for any platform creates the necessary feedback loop. To grow and sustain any such third-party communities, the major drivers of software technology, such as Sun and Microsoft, need to maneuver carefully. Players focusing on supplying components can only be viable if investments can be amortized (and profits drawn) before the rules change again.
Reference
[1] http://www.itworld.com/soa/60169/soa-gets-obituary
[2] C. Szyperski, Component Software. Addison-Wesley Professional, November 2002.
[3] Wikipedia, Service-oriented architecture, http://en.wikipedia.org/wiki/Main_Page.
[4] Ivica Crnkovic1, Stig Larsson2, Michel Chaudron, Component-based Development Process and Component Lifecycle, Information Technology Interfaces, 2005. 27th International Conference on June 20-23, 2005.
[5] CBSE: a Quantitative Approach Miguel Goulão Departamento de Informática – FCT/UNL 2825-114 Monte de Caparica, Portugal
[6]. Nicolai Josuttis, SOA in practise, 1st edition, O’Reilly media, Inc. Aug, 2007, ISBN: 978-0-596-52955-0
[7]. Newcomer, Eric; Lomow, Greg (2005). Understanding SOA with Web Services. Addison Wesley. ISBN 0-321-18086-0.
[8]. Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. pp. 3. ISBN 978-0-470-14111-3.
[9]. Erl, Thomas (2005). Service-oriented Architecture: Concepts, Technology, and Design. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-185858-0.
[10]. Erl, Thomas, SOA: Principles of Service Design, Prentice Hall, 2007, ISBN: 978-0-13-234482-1
[11]. Kishore Channabasavaiah, Kerrie Holley, Edward M. Tuggle, Jr., Migrating to a service-oriented architecture, IBM CorporationSoftware Group, 2007
[12]. Ivica Crnkovic, Michel Chaudron, Stig Larsson, Component-based Development Process and Component Lifecycle, Software Engineering Advances, International Conference on Oct. 2006
[13] Kurt Wallnau, “Dispelling the Myth of Component Evaluation” in Ivica Crnkovic and Magnus Larsson (editors), “Building Reliable Component - Based Software Systems”, Artech House Publisher, 2002.
[14]. http://www.eu-orchestra.org/TUs/SOA/en/html/Unit4_learningObject1.html, OASIS Definition of SOA, 2007, Orchestar.
[15]. Booch, G., Software Components with Ada: Structures, Tools, and Subsystems, 3rd ed.,
Reading, MA: Addison-Wesley, 1993.
[16]. Szyperski, C., Component Software—Beyond Object-Oriented Programming, Reading,
MA: Addison-Wesley, 1999.
[17]. Brown, A. W., Large-Scale, Component-Based Development, Englewood Cliffs, NJ:
Prentice Hall, 2000.
[18]. OMG Unified Modeling Language Specification, Version 1.4, Object
Management Group, 2000.
[19]. Heineman, G. T., and W. T. Councill, (eds.), Component-Based Software
Engineering: Putting the Pieces Together, Reading, MA: Addison-Wesley, 2001.
[20]. Jerry Zeyu Gao, H.-S. Jacob Tsao, Ye Wu, Testing and Quality Assurance for
Component-Based Software, ARTECH HOUSE, INC., 2003, ISBN 1-58053-480-5
1 Project introduction 3
2 Component based software engineering 3
2.1 Definitions(Component based software engineering) 3
2.2 Concepts (Component, Module, Interface, Object) 3
2.3 Objectives 6
2.4 Benefits and disadvantages 6
2.5 Needs and Motivation 7
3 What is SOA-based software engineering? 7
3.1 Definitions 7
3.2 Concepts 8
3.3 Objectives 9
3.4 Benefits: 12
3.5 The future of SOA 13
4 What are the major differences and similarity between these two approaches? 15
5 What are the differences between service components and modern components? 20
5.1 What is service? 20
5.2 What is modern component? 21
6 Building SOA-based software system is same as building a component-based system using service components? 24
7 Tools and technologies for building service components 26
7.1 Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft 26
7.2 IBM Service Component Architecture Explorer Tool 26
8 Discussions and justification comments 27
8.1 What is SOA? Can we buy it? 27
8.2 What’s the base system of SOA? 27
8.3 How to design service contract? 28
9 A summary, conclusions, and future directions 31
Reference 32
1 Project introduction
There are people who start to accept the “new idea” and try to change their software product structure into component based, and there are also people who start to research on new concepts on software structure to replace the “nearly old fashioned and full of overestimate” – Service oriented architecture. Things might be worse under the current economic crisis as adopting new business architecture are lacking of funds, even some specialists pointed out “SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession” [1]. That’s the IT industry, which seems they never have the latest and the best technique in all kinds of areas.
Neutrally speaking, component based architecture is still enough for most of current requirements, despite of its “old” age of more than 20 years. And after the depression, SOA will still be the most prospective architecture within a few years, but there are already articles that doubt if SOA will be easily applied by most enterprises and easily get the expected positive results after applying SOA.
This paper will briefly compare component based software engineering and service oriented software engineering. The concepts, comparison, tools and methods will show how these two major software architectures play their roles in current enterprise software.
2 Component based software engineering
2.1 Definitions (Component based software engineering)
Component based software engineering (Abbreviation: CBSE), Component based development, Component based programming, are exactly the same thing in software industry. In Wikipedia, CBSE is defined as “a branch of the software engineering discipline, with emphasis on decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components”
This definition introduces the basic unit forming the CBSE – Component (Software component). The architecture is built by the relations between the components “decomposed” from the whole system. The interfaces enable these components communicate with each other and connected to form the whole system.
2.2 Concepts (Component, Module, Interface, Object)
To explain the concepts in component based software engineering and their functions, relationships, we would like to introduce a kind of toys which was very popular in our childhood – Electronic bricks, as the example. Each brick has outer plugs to be connected with other bricks, and have different functions: line, battery, bulb, diode… Under the instructions, players could build up a radio with easy functions or a speaker, etc.
Component
A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.[2] Clement Szyperski lists three major properties of software component: a unit of independent deployment ; a unit of third-party composition ; no observable state (Encapsulated).
Let’s consider the CBSE as a set of Electronic Bricks. Here is what a single brick is designed in this toy: An opaque plastic shell, with sockets in the bottom, and outlets in the top, and a kind of electronic component or a set of circuit inside. The sockets and outlets are used to connect with other bricks or the main board to install these bricks. Players could only see the corresponding electronic symbol instead of the inside structure of the brick.
Let’s conclude the properties of this brick and compare them with the properties of CBSE to get the ones of CBSE much clearer and organized:
Figure 1 “Electronic bricks” – Components
Unit of independent deployment: a brick is the basic unit of setup any kind of “product”, so do the software component.
Third-party composition: The players are not the producers of these electronic bricks.
Encapsulated: The players could not see the inside structure of the bricks. They can only judge the function of the brick by its electronic sign on the top.
Communicating with other components: A brick could connect to others with its sockets and outlets.
Multiple use (Reusable): These bricks could be used by many times to setup many kinds of products.
Component Interface
Return to the electronic bricks, the board which has specified placed outlets to install the bricks, is exactly playing the role of component interface.
Figure 2 “Bricks and board” - Components and interface
In CBSE, connecting and enable communication between components is not so easy as plug the bricks on the outlets. First of all, a good designed interface is required. An interface of software component could be defined as a specification of its access point.
The interface doesn’t offer any implementation of its operations, only provides the descriptions and protocols. Thus, it enables itself to replace implementation with interface changes, or add new interfaces and implementation without any change on implementation.
Other concepts
Patterns : a pattern defines a recurring solution to a recurring problem. It could be employed in the design and documentation of a software component. It could be used to describe the low-level implementation details of the behavior and structure of the components, or the relationships between components in the context of a particular programming language.
Component model: A component model defines a set of standards and conventions used by the computer developer, whereas a component framework is a support infrastructure for the component model.
2.3 Objectives
There comes out the question, what should CBSE do after they are applied? Why the definitions of CBSE are clinched to those principles? Let’s list out those obvious things which will benefit the whole software production.
First of all, under CBSE the components could be reused many times, the designers don’t need to mess with the inside code of the component, just get it, setup on the interface, and then connect them together. CBSE has very specified detail document to provide support for these operations so that the designers would not confuse on the component functions.
Thus, applying component based software engineering should have these objectives :
To reduce system production cost and time by reusing existing reusable and high quality components
To provide support for the development of systems as assemblies of components
To support the development of components as reusable entities
To facilitate the maintenance and upgrading of systems by customizing and replacing their components
2.4 Benefits and disadvantages
By achieving these goals, CBSE has several advantages towards the old software architectures:
a) Lead time reduced : by building applications from reusable components
b) Cost reduced : Multiple reusing components could save the cost of developing new components
c) Higher quality: more times a component has been used, more times it has been tested. Retesting is one of the most powerful methods to enhance coding quality.
d) Easy Maintenance: easy updating with simply replace the old version components by new version, which could also save the maintenance cost.
Of course, CBSE is not the answer to every problems in software designing, that’s why SOA is grabbing more and more users. Before we talk about SOA, let’s see what the things CBSE lacks of are.
e) Difficult specification: it’s not easy to specify component standards during first time design.
f) Lacks of ideal component models: there are still many existing component models which are incomplete, inconsistent, and have problems during deployment. In one word, they are not standardized.
g) Life cycle problems: As components are not observable, there will be more problems during independent component development process.
Production from scratch is a very expensive undertaking. Suboptimal solutions in all but the local areas of expertise are likely. Maintenance and “chasing” of the state-of-the-art, such as incorporating web access, can become a major burden. Interoperability requirements further the burden, with other in-house systems and, more critically, also with business partners and customers. As a result, most large projects fail partially or completely, leading to a substantial risk. [3]
2.5 Needs and Motivation
CBD claims include reductions both in development costs and time and the increase of the developed software system’s overall quality [4]. These improvements result from reuse: building software from existing well tested building blocks is more effective than developing similar functionalities from scratch. It is important to analyze the reuse related improvement achieved through CBD. The bulk of component related research has been mainly focused on the functionality and composability of components, as well as their specification. The research niche of component quality assessment, with an emphasis on quantitative approaches , is fairly unexplored. The few existing evaluations are performed at a qualitative level, which makes the assessment of the true impact of the above-mentioned claims harder. In our research, we are particularly interested in the quantitative evaluation of software components and their impact on the systems they are integrated in.
3 What is SOA-based software engineering?
3.1 Definitions
It is hard to find an exact definition of the term SOA. The problem is not that there aren't any definitions; the problem is that there are many different definitions. To give you an idea of how they are similar and dissimilar, a selection of published definitions are sidebars in this chapter. You'll find some common phrases and attributes as you read them, but you will also find a lot of differences in the context, level of abstraction, and wording [5].
However, at least all definitions agree that SOA is a paradigm for improved flexibility. Here are some definitions
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
- OASIS (the Organization for the Advancement of Structured Information Standards)
In computing, service-oriented architecture (SOA) provides methods for systems development and integration where systems group functionality around business processes and package these as interoperable services. An SOA infrastructure allows different applications to exchange data with one another as they participate in business processes. Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. [6] SOA separates functions into distinct units, or service [7]. which developers make accessible over a network in order that users can combine and reuse them in the production of business application [8]. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.
- Wikipedia
SOA is not a concrete architecture: it is something that leads to a concrete architecture. You might call it a style, paradigm, concept, perspective, philosophy, or representation. That is, SOA is not a concrete tool or framework you can purchase. It is an approach, a way of thinking, a value system that leads to certain concrete decisions when designing a concrete software architecture.[9]
3.2 Concepts
Here are the key technical concepts of SOA that allow it to cope with the system characteristics just described [10]:
Services
Software development is the art of abstraction. We have to abstract reality in such a way that only the relevant aspects of a problem are handled. However, we all know that we can abstract from different perspectives. SOA aims to abstract by concentrating on the business aspects of a problem. The fundamental term introduced here is service. In essence, a service is an IT representation of some business functionality. The goal of SOA is to structure large distributed systems based on the abstractions of business rules and functions.
This gives a clear structure to the IT systems we design and develop. Although internally they are, of course, technical systems, the external interfaces should be designed in such a way that business people can understand them. Externally, you should not see the technical details. The smart consequence of this approach is that at this level of abstraction, platform-specific details don't matter. Thus, platforms can be heterogeneous.
Besides this broad definition, it is not clear what exactly a service is or can be. There are very different opinions about the exact attributes a service must, can, or should have. I will discuss services in detail in the next chapter (presenting several different existing definitions for services as well). As a rule of thumb, however, you can consider a service to be the IT representation of self-contained business functionality, such as "create a customer," "get a customer's contracts," "transfer money," "turn on the radio," "calculate the best route for my car," and so on.
Interoperability
With heterogeneous systems, the first goal is to be able to connect those systems easily. This is usually called "high interoperability." High interoperability is not a new idea. Before SOA, we had the concept of enterprise application integration (EAI), and regarding interoperability, SOA is nothing new.
However, for SOA, high interoperability is the beginning, not the end. It is the base from which we start to implement business functionality (services) that is spread over multiple distributed systems.
Loose coupling
As I've already mentioned, we live in a world ruled by marketing guys. We don't always have time to analyze, design, and implement carefully. We need fast times to market, so flexibility is often valued over quality. This leads to several problems.
Consider that at the same time we are integrating more and more systems, and implementing business processes by distributing them over different systems. In principle, data flows in such a way that processes run successfully in all the affected systems: we create a customer in all our systems, transfer money from one system to the other, or process a customer's order by shipping a product and sending a bill.
3.3 Objectives
The upcoming set of sections describes each of these strategic goals:
Overall goals [11]:
Increased Intrinsic Interoperability
Interoperability refers to the sharing of data. The more interoperable software programs are, the easier it is for them to exchange information. Software programs that are not interoperable need to be integrated. Therefore, integration can be seen as a process that enables interoperability. A goal of service-orientation is to establish native interoperability within services in order to reduce the need for integration.
Increased Federation
A federated IT environment is one where resources and applications are united while maintaining their individual autonomy and self-governance. SOA aims to increase a federated perspective of an enterprise to whatever extend it is applied. It accomplishes this through the widespread deployment of standardized and composable services each of which encapsulates a segment of the enterprise and expresses it in a consistent manner.
Increased Vendor Diversification Options
Vendor diversification refers to the ability an organization has to pick and choose “best-of-breed” vendor products and technology innovations and use them together within one enterprise. It is not necessarily beneficial for an organization to have a vendor-diverse environment; however, it is beneficial to have the option to diversify when required. To have and retain this option requires that its technology architecture not be tied or locked into any one specific vendor platform (Figure 3).
Figure 3 A service composition consisting of three services.
Increased Business and Technology Domain Alignment
The extent to which IT business requirements are fulfilled is often associated with the accuracy with which business logic is expressed and automated by solution logic. Although initial application have traditionally been challenging to keep applications in alignment with business needs when the nature and direction of the business changes.
Service-oriented computing introduces a design paradigm that promotes abstraction on many levels. One of the most effective means by which functional abstraction is applied is the establishment of service layers that accurately encapsulate and represent business models. By doing so, common, pre-existing representations of business logic can exist in implemented form as physical services
System goals [12]:
Flexibility
Scalability
Fault tolerance
The key to fulfilling these goals is loose coupling. Loose coupling is the concept of minimizing dependencies. When dependencies are minimized, modifications have minimized effects, and the systems still runs when parts of it are broken or down. Minimizing dependencies contributes to fault tolerance and flexibility, which is exactly what we need.
In addition, loose coupling leads to scalability. Large systems tend to challenge limits. Therefore, it is important to avoid bottlenecks; otherwise, growing might become very expensive. Avoiding bottlenecks is important from both a technical and an organizational point of view. All large systems only work if the usual business can be done in as decentralized a manner as possible. One way to introduce loose coupling is to avoid introducing any more centralization than is necessary (unfortunately, you need some centralization to establish SOA because you need some common base).
Needs:
Having read that the key technical concepts for SOA are services, interoperability, and loose coupling, you might conclude that all you have to do to enable SOA is to introduce services, interoperability, and loose coupling [13]:.
But as I stated earlier, you can't buy SOA. What's important is that you introduce these concepts in the appropriate fashion. That is, you have to find the right degree of centralization, you have to set up the corresponding processes, and you have to do your homework. A lack of these "ingredients" is what I most often find as the problem in real SOA projects. To establish SOA successfully, you have to care for your infrastructure, architecture, and processes (including the metaprocess, governance).
Infrastructure
Infrastructure is the technical part of SOA that enables high interoperability. The infrastructure of a SOA landscape is called an enterprise service bus (ESB). This term is taken from enterprise application integration, where it was called the EAI bus or just enterprise bus.
The key feature of the ESB is that it enables you to call services between heterogeneous systems. Its responsibilities include data transformation, (intelligent) routing, dealing with security and reliability, service management, monitoring, and logging.
Architecture
Architecture is necessary to restrict all the possibilities of SOA in such a way that it leads to a working, maintainable system. SOA concepts, SOA tools, and SOA standards leave room for specific decisions that you must make in order to avoid a mess. You have to classify different types of services, you have to decide on the amount of loose coupling, you have to restrict the data model of service interfaces, you have to define policies, rules, and patterns, you have to clarify roles and responsibilities, you have to decide on the infrastructure technology, you have to decide which (version of) standards to use, and so on.
Processes
One thing that makes large systems complicated is that many different people and teams are involved in them. As a consequence, it is a long path from an initial business idea or requirement to a solution running in production mode.
Governance
The metaprocess of all processes and a SOA strategy as a whole is governance. You have to set up the right process to establish SOA in your organization. This includes finding the right people who are able to combine all the different SOA ingredients to create a result that works and is appropriate. There is usually a central team (sometimes called the SOA competence center) that deals with infrastructure, architecture, and processes. This team is also responsible for establishing a common understanding, and doing the homework right. This requires management support, because in addition to time and resources, courage is required to deal with the organizational impacts of SOA Understanding, governance, management support, and homework are key factors for the success of SOA.
3.4 Benefits:
[14] An SOA can be evolved based on existing system investments rather than requiring a full-scale system rewrite. Organizations that focus their develop¬ment efforts around the creation of services, using existing technologies, combined with the component-based approach to software development will realize several benefits.
Leveraging existing assets. This benefit is the first, and most important, of the requirements discussed earlier in this paper. You can construct a business service as an aggregation of existing components, using a suitable SOA framework and made available to your enterprise. Using this new service requires knowing only its interface and name. The service’s implementation specifics (such as its component architecture) or discrete functional components—as well as the complexities of the data flow through the components that make up the service—are transparent to callers. This component anonymity lets organizations leverage current investments, building services from a conglomeration of components built on different machines, running different operating systems, developed in different programming languages. Legacy systems can be encapsulated and accessed using Web services interfaces. More important, legacy systems can be transformed, adding value as their functionality is transformed into services.
Infrastructure as a commodity. Infrastructure development and deployment will become more consistent across all your different enterprise applications. Existing components, newly developed components and components purchased from a range of vendors can be consolidated within a well-defined SOA framework. Such an aggregation of components will be deployed as services on the existing infrastructure. As a result, the underlying infrastructure becomes more of a commodity. Over time, as services become more loosely coupled from the supporting hardware, you can optimize the hardware because the service assembler is no longer dependent upon the hardware environment on which the service operates at run time.
Faster time-to-market. Organizational Web services libraries will become your organization’s core assets as part of your SOA framework. Building and deploying services with these Web services libraries will reduce your time to market dramatically, as new initiatives reuse existing services and components, reducing design, development, testing and deployment time in the process. As services reach critical mass in your organization or trusted network, the larger ecosystem emerges — enabling you to assemble composite applications using services, rather than developing custom applications.
Reduced cost. As business demands evolve and new requirements are introduced, the cost to enhance and create new services by adapting the SOA framework and the services library, for both existing and new applications, is greatly reduced. The learning curve for the development team is reduced as well, as they may already be familiar with the existing components.
Risk mitigation. Reusing existing components reduces the risk of introducing new failures into the process of enhancing or creating new business services. You will also reduce the risk in the maintenance and management of the infrastructure supporting the services.
Continuous business-process improvement. An SOA allows a clear representation of process flows identified by the order of the components used in a particular business service—and provides business users with an ideal environment for monitoring business operations. Process modeling is reflected in the business service. Process manipulation is achieved by reorganizing the pieces in a pattern (components that constitute a business service). This function allows you to change the process flows while monitoring the effects to facilitate continuous improvement.
3.5 The future of SOA
So far, this white paper discussion centers around the need to increase speed of business changes, and to improve business performance and efficiency. These requirements mandate a set of IT imperatives for flexibility where SOA becomes a key enabler. But what if a completely new model for application development emerges? Will the notion of an SOA still be meaningful or required? The answer is a resounding, yes. Two new, emerging concepts are beginning to be implemented: grid computing and on demand computing. While these models are distinct and have developed separately, they are closely related; and each makes the evolution to SOA even more imperative. Representing every application, resource or business capability as a service with a standardized interface allows you to quickly combine new and existing applications to address changing business needs and improve operational effectiveness — the essence of SOA. As a result, SOA becomes the DNA of grid computing and on demand computing.
Grid computing
An in-depth discussion of grid computing is beyond the scope of this paper, but a couple of points are worth mentioning. First, grid computing is much more than just the application of large numbers of millions of instructions per second (MIPS) to effect a computing solution to a complex problem. It enables you to divide resources into multiple execution environments by applying one or more concepts, such as hardware or software partitioning, or time-sharing, machine simulation, emulation and quality of service. This virtualization, or on demand deployment, of all your distributed computing resources lets you use them wherever and however they are needed within the grid. Virtualization is simply a form of resource management for devices, storage, applications, services or data objects. Hence, applying SOA allows you to maximize resource utilization in a grid environment. You can deploy and migrate a services ecosystem onto appropriate nodes in a grid environment to respond efficiently to changes in your internal and external business environment.
On demand computing
An in-depth discussion of on demand computing is also beyond the scope of this paper. But, again, SOA can be an essential prerequisite for on demand computing. SOA is an enabling architecture for on demand applications. Thus, applications must operate in an SOA to realize the benefits of on demand. Web service is an enabling technology for SOA. As a subset of on demand computing, Web services on demand is simply business services exposed using Web services standards.
On demand computing can cover a wide spectrum. One end of this spectrum focuses on the application environment; the other end focuses on the operating environment, which includes items like infrastructure and autonomic computing. Transforming your business means leveraging both the application and operating environments to create an on demand business. At the heart of your on demand business will be business services on demand where application-level services can be discovered, reconfigured, assembled and delivered on demand, with just-in-time integration capabilities.
The promise of Web services as an enabling technology is that it will enhance business value by providing capabilities such as services on demand, and over time, will transform the way IT organizations develop software. It could even transform the way business is conducted and the way you offer your products and services over the Web to your entire value chain. What if all of your applications shared the same transport protocol? What if they all under¬stood the same interface? What if they could participate in, and understood, the same transaction model? What if this were true of your partners? Then you would have applications and an infrastructure to support an ever-changing business landscape—and you would have become an on demand business. Web Services and SOA can make this possible for applications.
4 What are the major differences and similarity between these two approaches?
The increased speed and scale of IT-enabled processes has been met with a proportional increase in the demand to modify processes to meet changing conditions. IT has accelerated the speed at which citizens, businesses, and organizations both operate and change.
The major difference between Component-Based Engineering and Service-Oriented Engineering is different architecture, for different needs of customers, the fundamental shift that will allow these visions to be realized is a move to Service Component-Based Architecture (SCBA). Today, the IT industry has generally accepted Service Oriented Architecture (SOA) as the most promising architectural approach to-date. SCBA complements traditional SOA approaches and is designed to provide an optimal, long-term service-oriented approach aligned with the FEA that recognizes the value of component-based service delivery. SCBA builds upon SOA in three key ways:
• it is tightly integrated with the Federal Enterprise Architecture,
• it provides a description of what the architecture is (a collection of services designed and implemented to achieve an organization’s mission)
• It identifies the organizational, cultural, and process elements, as well as technological elements, that need to exist for these architectures to be successful.
SCBA also treats business processes and the IT systems in the same way, allowing both to be reused across organizations. In order for a business process or technical system to be a “Service Component,” and thus participate in the overall architecture, it must offer a well-defined interface with well-defined functionality. These two characteristics represent the minimum criteria needed for a business process or technical system to be reused. Service Components are intended be a subset of the “components” defined in the FEA SRM. The SRM does not require rigorous interface or functionality descriptions, only systems and processes with these descriptions are both SRM Components and SCBA Service Components. SCBA attempts to realize the potential of the SRM by requiring that business processes and IT systems be designed or modified to make them easy to reuse. Later sections of this document will describe SCBA in further detail.
In the mid-90s, an additional development emerged: component based development (CBD). CBD takes the concept of abstraction in a new direction. Rather than reducing lines of code, CBD separates various aspects of the functionality into isolated units that can be produced and managed independently of the other aspects. This again allows a developer or consumer of the functionality to deal with one aspect at a time – ignoring the other aspects. In a component-based architecture the various aspects are organized into layers, most commonly: presentation, orchestration, business logic, data management, security, and infrastructure.
Service-oriented architecture represents a generalization of the component model by dealing directly with what is offered, rather than how it is packaged. The tiered architecture enables components to be easily incorporated in solution architectures. The evolution of services standards (e.g., WSDL, UDDI, and SOAP) and the maturity of distributed computing architectures (e.g., Java Enterprise Edition and .Net) have enabled "single-copy reuse" via shared services. Thus, SOA is a tiered framework that empowers solution developers to employ abstraction techniques, at all architectural tiers, without having to struggle with many of the interoperability and multiple implementation challenges faced by previous generations of reuse proponents. The future of software development will likely consist of complete assembly of applications from services and components – often referred to as “true software manufacturing.”
Figure 4 Evolution of Reuse in Software Development
Software components are units of software that provide business or technical functionality. These units are independently deployable; that is, they are self-contained and can be deployed virtually anywhere on the network. Business components execute business logic, enforce business rules, and manage corporate data. Technical components provide the platform or infrastructure capabilities that the business components rely on such as messaging, error handling, security, etc.
Components
Software components are the reusable building blocks for application development. A software component typically consists of: (1) a specification (process and data model representing the user or consumer’s view) that defines what the component does, (2) an implementation which is the internal design for the component, (3) an executable (run-time) module that gets deployed, (4) one or more interfaces that provide access to the component’s functionality. The key concept behind components is that the implementation is hidden behind the interface – the consumer of the component does not need to know the details of the implementation to exploit the capabilities offered. Thus, in general components are an approach to provisioning capabilities that are highly flexible. Component-based reuse is illustrated in Figure 5.
Figure 5 Illustration of Component-Based Reuse
Services
Services are focused on satisfying business or technical requirements based on a provider/consumer model. Services represent a broader concept than components. They are the activities executed in response to a request (or an event) in order to deliver some result. Both concepts employ the notion of an interface that defines the set of activities (or services) offered. However, whereas all components offer functionality as services, not all services are implemented as components. Figure illustrates the distinction between services and components – services are driven from business requirements, whereas components are a method of providing services. For example, one way to implement a service is to put an interface on some legacy functionality. The legacy system may be very unstructured (and not divided into independent components), yet the interface may offer the services required by other and new applications. As discussed in the roadmap section below, creating interfaces to access services from legacy systems is one common way to begin to implement an SOA.
Figure 6 Differences between Services and Components
Services and components enable reuse, although with slightly different twists. Components are typically designed to be redeployed or integrated into multiple different applications. In fact, commercial-off-the-shelf (COTS) components are typically licensed to be embedded in applications. Reuse is achieved by producing multiple instances of the component and building them into applications. Services can be exploited in this way, but also offer the possibility of shared-services – running a single instance of a service that can be called by other applications across the network, as shown in figure 6.
An important additional concept is service discovery, or the ability to find (either manually at design-time or automatically at run-time) and access existing services. Many technologies exist today that enable this, and a coordinated strategy for identifying and categorizing services across the enterprise is critical. In the Federal government, the FEA provides the first step in implementing this strategy. Since services may be thought of as an abstraction of components, it is not too difficult to consider them both when describing reusable government-wide assets.
Figure 7 Illustration of Service-Based Reuse
A summary of the key concepts in CBSE and SOSE is listed in Table 1.
Table 1 Comparison of key concepts in CBSE and SOSE Concepts CBSE SOSE
Concepts CBSE SOSE
Module Component Service
Specification Component Contract Service description
Interface Component interface Service interface
Assembly Component
composition Service
composition
Module.
In CBSE, components are the building blocks that can be deployed independently and are subject to composition by third party [10]. Based on the formulation by Clemens Szyperski [7], a software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. It can be both fine-grained providing specific functionality and coarse-grained encompassing complicated logics.
In SOSE, services are the building blocks that can be reused and offer particular functionalities. They are generally implemented as coarse-grained discoverable software entities [6], operating on larger data sets, encapsulating business functionality and exposing the functionality to any source that requests the functionality through well-defined interfaces. Thus, the services can be reused and accessed at various levels of the enterprise application and even across enterprises boundaries.
Specification.
In CBSE, the component specification provides for the clients the definition of the component’s interface, i.e. the operations and context dependencies. Furthermore, an abstract definition of the component’s internal structure is specified for the component providers [10].
In SOSE, the service description is a service contract that advertises the following information: (i)service capabilities - stating the conceptual purpose and expected results of the service; (ii) interface - describing the service signatures of a set of operations that are available to the service requester for invocation; (iii) behavior - describing the expected behavior of a service during its execution; and (iv) quality - describing important functional and nonfunctional service quality attributes [9].
Interface.
Although both CBSE and SOSE are interface-based in the sense that interfaces are the specifications of access points, the separation between service descriptions and service implementation is more explicit than the separation between component specification and implementation.
Assembly.
In CBSE, component composition is the process of assembling components using connectors or glue code to form an assembly, a larger component or an application. The components are assembled through the component interfaces and the composition is made out of several component instances that are connected and interact together.
In SOSE, the composite services are built by composing service descriptions. The realization of the service composition is during run time when the service providers are discovered and bound.
Table 1 Summary of similarities and differences of CBSE and SOSE
CBSE SOSE
Process Building system from preexisting components.
Separate development process
of components and system.
More activities involved in design time Building systems from pre-existing services.
Separate development process of services and system. More activities involved in run time
Technology Constrained by component models. Ranging from white box, gray box to black box. Static and dynamic binding between components. Dynamic discoverability is not a major concern Platform independency. Black box. Only dynamic binding between services. Dynamic discoverability
Quality Interoperability concern between heterogeneous components. Achieve component substitutability through explicit specifications. Better predictability Interoperability through universally accepted standards. Achieve service substitutability through service descriptions.
Predictability issue
Composition Homogenous composition. Design time and run time composition and design time composition allows for optimization. Pipe and filter; event mechanism etc. Composition is made out of several component instances Heterogeneous composition. Services are composed at run time.
Pipe and filter; orchestration etc.
Composite services are built by composing service descriptions
5 What are the differences between service components and modern components?
5.1 What is service?
The OASIS SOA Reference Model states [14]:
The noun "service" is defined in dictionaries as "The performance of work (a function) by one for another."
This can mean everything or nothing. As with the term SOA, it is hard to find an exact, useful definition of the term "service" because so many definitions exist. Again, I have collected some of these definitions. You'll find some common phrases and attributes as you read them, but you will also find a lot of differences in the context, level of abstraction, and wording.
SOA is focused on business processes. These processes are performed in different steps (also called activities or tasks) on different systems. The primary goal of a service is to represent a "natural" step of business functionality. That is, according to the domain for which it's provided, a service should represent a self-contained functionality that corresponds to a real-world business activity. In other words, business people should be able to understand what a service does [6].
Services exist as physically independent software programs with distinct design characteristics that support the attainment of the strategic goals associated with service-oriented computing. Each service is assigned its own distinct functional context and is comprised of a set of capabilities related to this context [10].
5.2 What is modern component?
Let us review some of the important definitions of software components given by the experts. One of the earliest definitions is given by Gready Booch [15]:
A reusable software component is a logically cohesive, loosely coupled module that denotes a single abstraction.
This definition captures the idea that a reusable component is an encapsulated software module consisting of closely related component elements. Later, Clement Szyperski presented his well-known definition of a software component at the 1996 European Conference on Object-Oriented Programming [16]:
A software component is a unit of composition with contractually specified interfaces and context dependencies only. A software component can be deployed independently and is subject to composition by third parties.
This definition is well accepted in the component-based software engineering community because it highlights the major properties of software components that are not addressed in traditional software modules, such as context independence, composition, deployment, and contracted interfaces. In 2000, a broader, more general notion of software components was defined by Alan W. Brown [17]:
An independently deliverable piece of functionality providing access to its services through interfaces.
A similar idea is also expressed in the unified modeling language (UML) definition [18]:
A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.
Recently, Bill Councill and George T. Heineman gave a new definition to emphasize the importance of a consistent component model and its composition standard in building components and component-based software [19]:
A software component is a software element that confirms to a component model and can be independently deployed and composed without modification according to a composition standard.
To simplify the concept of software components, we classify the notion of software components into three types: (1) reusable modules, (2) reusable components, and (3) composite building blocks [20].
A reusable module is an independent and deliverable software part that encapsulates a functional specification and implementation for reuse by a third party.
A reusable component is an independent, deployable, and replaceable software unit that is reusable by a third party based on the unit’s specification, implementation, and well-defined contracted interfaces.
A composite building block is a reusable component that is developed as a building part to conform a well-defined component model and the accompanying composition standards.
The differences between service components in SOA and modern components in CBSE.
Comparison in properties[16], [6], [20].
Table 2 Comparison in properties
Properties Software Components in CBSE Services in SOA
Encapsulation: Each component encapsulates a set of closely related data elements and implements coherent functional logic to perform a specific task. Services are abstractions that hide implementation details from the consumers.
Stateless Sometimes, the components are stateful, sometimes are stateless. Sometimes, services are defined as being (ideally) stateless.
Reusable Reusability of software components is the key to the success of component-based software engineering. SOA leads to better reusability because all systems that need a certain functionality just call the same one.
Composable Components are composite if they are developed based on a standard composition method to support component composition. Kinds of business functionality can be broken into smaller steps, which are themselves services.
Vendor-Diverse Hard to reach Vendor- Diversification. Because there maybe some different frameworks or languages among components which are hard to be cohesive systems are usually very heterogeneous. Being able to use different platforms and different products for implementing services.
Interoperable Components are interoperable if they are developed based on standard communication channels and data exchange mechanisms defined in a component model. High interoperability is a core requirement of SOA. In the sense that services can be called from any other systems, they are inherently interoperable.
Independency Software components must be delivered as independent parts that can be replaced under certain conditions. The goal is to minimize dependencies so that a SOA is appropriate for distributed systems with different owners.
Contract-based interfaces An interface between software components defines a contract between the client of an interface and a provider of an implementation for the interface. Communication among services components is based on service contract which is implemented by Web service at the most time.
Deployable Software components are known as deployable if a well defined
deployment approach has been built inside a component to support its deployment Service components are deployable if service contracts among them are well developed to support them for working together.
From the comparison in properties we could infer that:
i. There are some excellent properties the two shard, they are: Encapsulation Composable, Reusable, Interoperable, Independency, Contract-based interfaces and Deployable.
ii. Obviously there are some differences between them including: Status, Vendor-Diverse.
Comparison in different perspectives
Table 3 Comparison in different perspectives
Perspectives Software Components in CBSE Services in SOA
Base units of system Component-based system consists of composite components. System based on SOA is comprised of composite services.
Component design Component selection, creating, evaluation and testing. Service connection, creation, evaluation and testing.
Contract design Function implementation à Interface connection. Interface design à Function implementation.
Implemented by Various programming languages, frameworks and technologies or something like that is permitted. Mainly Web Service and related technologies.
Development process A dedicated component engineering process is in place to control and manage the construction of components. A service-oriented development process is used to control and manage module development.
Reuse scopes Large reuse scopes encompassing different projects, product lines, organizations or even the programming endeavors of the general public. Reuse of almost every service in the system and the scope of services could be extended by plug-in other services following the same standards.
From the comparison in different perspectives we could infer that:
i. These two design paradigms are all based on reusable, independent, interoperable component. One is software component, the other the service.
ii. Connections among the components are contracts. However the design processes is different, or we could say they are inverse.
iii. They have large scale of reuse and reach a high level of flexibility and interoperability.
iv. Different components are implemented by various technologies.
6 Building SOA-based software system is same as building a component-based system using service components?
I think there are no large differences of the lifecycles between them. We can assume that the service is definitely a unit in the system, like a component, too. Therefore, actually, we are able to adopt the lifecycle processing of component based system which will work effectively in service-oriented system too. There are some effective lifecycle models of component-based system, such as, V development process, Y development process and component-based waterfall development process. Obviously they are suitable for SOA-based software system design. The only potential variations between them are the unit – one is the component, the other the service, and in detail, is the phase of integration of units.
The main emphasis is put on component selection and its integration into the system. This process can require additional efforts. First the selection process should ensure that appropriate components have been selected with respect to their functional and extra-functional properties. This requires verification of the component specification, or testing of some of the component’s properties that are important but not documented. Second, it is a well known fact [8] that even if isolated components function correct, an assembly of them may fail, due to invisible dependencies and relationships between them, such as shared data shared resources. This requires that components integrated in assemblies are tested before they are integrated into the system. At last, the combination of these assemblies must be testes again, since all combined assemblies of correct ones maybe incorrect although the assembly oneself are correct [7].
One of the main reasons is that Particular component model requires a particular architectural framework, and the application is supposed to use this framework. This directly has impact on architectural decisions. For example if the component model requires a client-server architecture style, it is obvious that the application will use that style and not another (for example pipe-filter) [12]. This will put limitations on the system design.
Things seem better in SOA based architecture. Because avoiding normal data transmission among components, we only need to transfer an XML info, which is carried by SOAP and Http, for them to communicate. The pattern of XML info complies a standardized principle. Therefore we are easier to control transmission among different services. In this way, consideration about frameworks like we should consider in the component-based system is not necessary in that no matter what inner framework it is, the output and input is always the standardized XML (Figure 8). Services could send and receive them easily.
However, all these are based on well developed service contracts. Before the information sent out by service, it has to be translated via specific service contract. Then all the information are definitely in a same, concrete and standardized pattern, which will certainly improve the overall effectiveness of the system, because of the time of transformation has been saved.
Figure 8 Role of Web service and service contracts and their relationship.
7 Tools and technologies for building service components
7.1 Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft
In computer programming, a Visual Basic Extension (commonly abbreviated VBX) or custom control was the component model used in Microsoft Visual Basic versions 1.0 to 3.0. It is still supported in the 16-bit version of version 4.0, but was made obsolete by OCXs. VBX has also been supported in some versions of Borland Delphi.
The VBX specification was created so that developers could extend Visual Basic. According to rumor, Bill Gates reviewed the first version of Visual Basic before release and told the development team that it must have an extensibility mechanism. Since at the time Visual Basic was an interpreted language with limited power compared to C, VBXs which were most often written in C or C++ provided the ability to create very powerful and efficient software which could easily be hooked up to form based user interfaces.
Visual Basic 4.0 added support for the newer OLE Controls or OCXs (which became ActiveX controls), implicitly deprecating VBX controls. OCXs are based on the Component Object Model.
Each version of Visual Basic has come with many controls. By incorporating VBX controls into Visual Basic, Microsoft spawned the first commercially viable market for reusable software components. Third parties have created a large market of custom controls for resale.
VBX components were called "custom controls" because the Microsoft development team envisioned them as visual "control" components like a toggle switch or button. Enterprising third party software component developers saw opportunities to use the VBX specification for non-visual components, such as components for creating ZIP files, manipulating low-level system settings and communicating with TCP/IP.
7.2 IBM Service Component Architecture Explorer Tool
A metadata explorer that presents information about the service component architecture (SCA) services available in a given WebSphere Enterprise Service Bus server or WebSphere Process Server.
SCA Explorer presents information about the SCA services available in a given WebSphere® Enterprise Service Bus (ESB) server or a WebSphere Process Server (WPS). This information includes details such as how to locate and invoke such services (for example, when developing a new application that intends to re-use existing services in the enterprise).
SCA Explorer presents a Web page with tree widgets that allow the user to select an SCA module and "drill down" to see the components inside, their available interfaces, the operations available on such interfaces, the structure of the input and output Service Data Objects (SDOs), and any exceptions that can be raised by such operations. SCA Explorer also displays information about the imports, exports, and references used by such services; binding information, such as EJB JNDI names (Enterprise Java Beans, Java Naming and Directory Interface), Web service ports and endpoints, resource adapters, Java Message Service (JMS) destinations, etc.; and information about the implementation of such services.
With SCA, metadata is expressed via the Service Component Definition Language (SCDL), and an SPI exists that allows one to query this SCDL information. SCA Explorer is a JSP (Java Server Pages)-based application that demonstrates the use of this SPI to obtain information about the available SCA services and display it via HTML. Also included is a command line J2SE version that prints the same information to System.out and a command line tool that uses Eclipse Modeling Framework (EMF) to generate an XML file containing such information. [5]
8 Discussions and justification comments
8.1 What is SOA? Can we buy it?
SOA is not a concrete architecture: it is something that leads to a concrete architecture. You might call it a style, paradigm, concept, perspective, philosophy, or representation. SOA establishes an architectural model that aims to enhance the efficiency, agility, and productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realization of strategic goals associated with service-oriented computing [5]. Therefore, SOA is not a concrete tool or framework you can purchase. It is an approach, a way of thinking, a value system that leads to certain concrete decisions when designing concrete software architecture.
This aspect of SOA has a very important consequence: you can't buy SOA. There is no tool or recipe you can use to make everything work. While applying this paradigm to your concrete situation, you must make specific decisions that are appropriate for your circumstances [11].
8.2 What’s the base system of SOA?
Of course, flexibility is dealt with very differently on different layers and in different components. So, one important question is which kinds of software systems this paradigm is appropriate for. As it turns out, SOA copes well with many difficult-to-handle characteristics of large systems [1].
Distributed Systems
As businesses grow, they become more and more complex, and more and more systems and companies become involved. There is constant integration and constant change. SOA is well suited to dealing with complex distributed systems. According to the OASIS SOA Reference Model (see [OasisSoaRM06]), it is a paradigm for "organizing and utilizing distributed capabilities."
SOA allows entities that need certain distributed capabilities to locate and make use of those capabilities. In other words, it facilitates interactions between service providers and service consumers, enabling the realization of business functionalities.
Different Owners
The OASIS SOA Reference Model's definition of SOA continues by stating that those distributed capabilities "may be under the control of different ownership domains." This is a very important point that is often suppressed in SOA definitions. You won't find it in any of the other definitions quoted in this chapter, but it is the key for certain properties of SOA, and a major reason why SOA is not only a technical concept.
SOA includes practices and processes that are based on the fact that networks of distributed systems are not controlled by single owners. Different teams, different departments, or even different companies may manage different systems. Thus, different platforms, schedules, priorities, budgets, and so on must be taken into account. This concept is the key to understanding SOA and large distributed systems in general.
Heterogeneity
Another very important difference between small and large systems is the lack of harmony. We all know this from experience (although we might not agree about whether it's a natural phenomenon or the result of bad design). Large systems use different platforms, different programming languages (and programming paradigms), and even different middleware. They are a mess of mainframes, SAP hosts, databases, J2EE applications, small rule engines, and so on. In other words, they are heterogeneous.
In the past, a lot of approaches have been proposed to solve the problem of integrating distributed systems by eliminating heterogeneity: "Let's harmonize, and all our problems will be gone," "Let's replace all systems with J2EE applications," "Let's use CORBA everywhere," Let's use MQ series," and so on. But we all know that these approaches don't work. Large distributed systems with different owners are heterogeneous. This is a fact, and therefore something we must accept when designing large distributed solutions.
8.3 How to design service contract?
It is worth singling out Decoupled Contract at this stage because a Web service contract is essentially an implementation of this pattern. When building services as Web service. Service contracts are positioned as physically separate parts of the service architecture (Figure 9). This allows us to fully leverage the technologies to design and develop these contracts independently from the logic and implementations they will eventually represent.
Figure 9 The Web service contract is a physically separated part of a Web service implementation.
To design and develop service contracts is a huge project. So let’s introduce it briefly.
A service contract needs to have the following components [13]:
• Header
o Name - Name of the service. Should indicate in general terms what it does, but not be the only definition
o Version - The version of this service contract
o Owner - The person/team in charge of the service
o RACI
Responsible - The role/person/team responsible for the deliverables of this contract/service. All versions of the contract
Accountable - Ultimate Decision Maker in terms of this contract/service
Consulted - Who must be consulted before action is taken on this contract/service. This is 2-way communication. These people have an impact on the decision and/or the execution of that decision.
Informed - Who must be informed that a decision or action is being taken. This is a 1-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action.
o Type - This is the type of the service to help distinguish the layer in which it resides. Different implementations will have different service types. Examples of service types include:
Presentation
Process
Business
Data
Integration
• Functional
o Functional Requirement (from Requirements Document) - Indicates the functionality in specific bulleted items what exactly this service accomplishes. The language should be such that it allows test cases to prove the functionality is accomplished.
o Service Operations - Methods, actions etc. Must be defined in terms of what part of the Functionality it provides.
o Invocation - Indicates the invocation means of the service. This includes the URL, interface, etc. There may be multiple Invocation paths for the same service. We may have the same functionality for internal and external clients each with a different invocation means and interface. Examples:
SOAP
REST
Events Triggers
• Non-Functional
o Security Constraints - Defines who can execute this service in terms of roles or individual partners, etc. and which invocation mechanism they can invoke.
o Quality of Service - Determines the allowable failure rate
o Transactional - Is this capable of acting as part of a larger transaction and if so, how do we control that?
o Service Level Agreement - Determines the amount of latency the service is allowed to have to perform its actions
o Semantics - Dictates or defines the meaning of terms used in the description and interfaces of the service
o Process - Describes the process, if any, of the contracted service
One of the most challenging questions for component based software engineering is that, has CBSE really been out-fashioned? This could be separated into several sections :
Could SOA solve all the disadvantages of CBSE?
If so, is the cost acceptable?
Are those disadvantages really defective enough to have the users changing the system into new one with SOA?
9 A summary, conclusions, and future directions
For components to be independently deployable, their granularity and mutual dependencies have to be carefully controlled from the outset. For large systems, it becomes clear that components are a major step forward from objects (classes). This is not to say that objects are to be avoided. On the contrary, object technology, if harnessed carefully, is probably one of the best ways to realize component technology. In particular, the modeling advantages of object technology are certainly of value when constructing a component. On the flip side, modeling of component-based systems is still a largely unsolved problem, although there have been some recent inroads (for example, D’Souza and Wills, 1999, and Cheeseman and Daniels, 2000). UML, for instance, is still ill equipped to model component-based designs, though improvements in this area are one of the major goals for the UML 2.0 definition (still in its early phases in early 2002). Under the constant pressure of Moore’s law, the world of software has been expanding to take advantage of exponentially more powerful hardware resources. The resulting solutions reach into ever more areas of business and society, leading to new requirements, new markets, and new overall dynamics at a rapid pace. Software technology responded with a very dynamic evolution. However, components are hard to establish in a world of extreme dynamics. While much in the world of software needs to continue to progress rapidly, certain aspects need to evolve more gradually at a more controlled pace. These include the foundations of software components, including component models and basic technologies. The significant market advantage that can be gained from having third-party component backing for any platform creates the necessary feedback loop. To grow and sustain any such third-party communities, the major drivers of software technology, such as Sun and Microsoft, need to maneuver carefully. Players focusing on supplying components can only be viable if investments can be amortized (and profits drawn) before the rules change again.
Reference
[1] http://www.itworld.com/soa/60169/soa-gets-obituary
[2] C. Szyperski, Component Software. Addison-Wesley Professional, November 2002.
[3] Wikipedia, Service-oriented architecture, http://en.wikipedia.org/wiki/Main_Page.
[4] Ivica Crnkovic1, Stig Larsson2, Michel Chaudron, Component-based Development Process and Component Lifecycle, Information Technology Interfaces, 2005. 27th International Conference on June 20-23, 2005.
[5] CBSE: a Quantitative Approach Miguel Goulão Departamento de Informática – FCT/UNL 2825-114 Monte de Caparica, Portugal
[6]. Nicolai Josuttis, SOA in practise, 1st edition, O’Reilly media, Inc. Aug, 2007, ISBN: 978-0-596-52955-0
[7]. Newcomer, Eric; Lomow, Greg (2005). Understanding SOA with Web Services. Addison Wesley. ISBN 0-321-18086-0.
[8]. Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. pp. 3. ISBN 978-0-470-14111-3.
[9]. Erl, Thomas (2005). Service-oriented Architecture: Concepts, Technology, and Design. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-185858-0.
[10]. Erl, Thomas, SOA: Principles of Service Design, Prentice Hall, 2007, ISBN: 978-0-13-234482-1
[11]. Kishore Channabasavaiah, Kerrie Holley, Edward M. Tuggle, Jr., Migrating to a service-oriented architecture, IBM CorporationSoftware Group, 2007
[12]. Ivica Crnkovic, Michel Chaudron, Stig Larsson, Component-based Development Process and Component Lifecycle, Software Engineering Advances, International Conference on Oct. 2006
[13] Kurt Wallnau, “Dispelling the Myth of Component Evaluation” in Ivica Crnkovic and Magnus Larsson (editors), “Building Reliable Component - Based Software Systems”, Artech House Publisher, 2002.
[14]. http://www.eu-orchestra.org/TUs/SOA/en/html/Unit4_learningObject1.html, OASIS Definition of SOA, 2007, Orchestar.
[15]. Booch, G., Software Components with Ada: Structures, Tools, and Subsystems, 3rd ed.,
Reading, MA: Addison-Wesley, 1993.
[16]. Szyperski, C., Component Software—Beyond Object-Oriented Programming, Reading,
MA: Addison-Wesley, 1999.
[17]. Brown, A. W., Large-Scale, Component-Based Development, Englewood Cliffs, NJ:
Prentice Hall, 2000.
[18]. OMG Unified Modeling Language Specification, Version 1.4, Object
Management Group, 2000.
[19]. Heineman, G. T., and W. T. Councill, (eds.), Component-Based Software
Engineering: Putting the Pieces Together, Reading, MA: Addison-Wesley, 2001.
[20]. Jerry Zeyu Gao, H.-S. Jacob Tsao, Ye Wu, Testing and Quality Assurance for
Component-Based Software, ARTECH HOUSE, INC., 2003, ISBN 1-58053-480-5
2009年2月17日星期二
Social-networking sites share breaking newsStory Highlights
Social-networking sites share breaking newsStory Highlights
More people are turning to social networking sites for breaking news
Sites like Twitter, Facebook and Flickr provide firsthand accounts of disasters
Users enjoy the speed and immediate access of those posting
Professor: Citizen journalism sometimes happens accidentally
By Lisa Respers France
CNN
(CNN) -- Janis Krums was heading to New Jersey on a ferry when he clicked a snapshot with his iPhone of US Airways Flight 1549 partially submerged in the Hudson River. He uploaded the picture to his Twitter account and then forgot about it as he assisted in the rescue of the plane's passengers.
iReporter Julie Pukelis used a camera and a telescope to get this view of the scene in Hudson River.
The deluge of image views crashed the servers of TwitPic, the application that allows Twitter users to send photos with their Twitter updates or "tweets."
"I posted it because I thought 'That's pretty newsworthy' and I wanted to share it with the people who follow me on Twitter," Krums said. "I was letting some of the survivors use my phone and it wasn't until later that I looked and saw that I had quite a few messages."
More people are turning to social networking sites like Twitter, Facebook and Flickr when news breaks to share stories and pictures.
In an era when even the president of the United States has a Facebook page and spectators texted and tweeted about Inauguration Day, the power of online and digital social networking is clear.
Barack Obama tapped into the stream for his grass-roots presidential campaign and the Israeli Consulate in New York used its Twitter account to disseminate information during the recent Israeli-Palestinian conflict in Gaza.
Twitter doesn't release figures on the total number of registered users, but according to Compete, which offers analytics on Web sites, the site had more than 4.4 million unique visitors as of December 2008. Facebook has more than 150 million active users and Flickr has more than 34 million registered users worldwide.
Accounts of the deadly attacks last fall in Mumbai, India, the May 2008 earthquake in China and last week's plane crash show what used to be just a virtual gathering place to communicate pet peeves or plans for the weekend has evolved into a go-to spot for eyewitness news -- sometimes even before mainstream media has had time to crack the story.
Twitter co-founder Biz Stone said Twitter users were the first to alert others last summer after an earthquake hit Southern California. "The earthquake struck at 11:42 [a.m.] PST and at 11:42 PST people started twittering," he said.
Twitter allows its users to post messages, or tweets, to their accounts that are then distributed to those who are "following" that user online. Stone noted that there was an Associated Press story on the quake that he saw posted nine minutes later on their site and said that during those nine minutes there were more than 3,600 tweets.
"That's when it sort of struck home for me," he said. "With Twitter, we have this real-time feed of what people around the world are seeing, thinking and feeling."
Such citizen journalism is in some cases happening almost accidentally, said Susan Jacobson, an assistant professor at Temple University in Philadelphia, Pennsylvania, who researches the impact of technology on journalism.
"Most people are just sending this information off to their friends," Jacobson said. "The main thing to take from sites like Twitter and Facebook is that they are informal modes of news dissemination."
Part of that informality includes brevity -- tweets have a maximum capacity of 140 characters, and Facebook statuses can only be a few lines -- and the possibility of inaccurate information. Jacobson said users, especially those who have grown up in the digital age, are very much aware of that.
"Young people, I think, have an innate radar about what is legitimate and what is not," she said. "They realize that not everything they read and see on the Web is true."
Stephen Hultquist, a Boulder, Colorado, consultant who gets a great deal of his breaking news from Twitter, said traditional media sources also make mistakes or give skewed reports.
"If anything, Twitter reminds me that everyone is human and they all have their own views and a paradigm through which they see the world," said Hultquist who had a unique appreciation of the quick, firsthand tweets that came after the earthquake in China last year.
"I was five miles from the epicenter of the earthquake in 1989 that happened right before a World Series game and I noticed that the media that was reporting on it wasn't getting it all right," he said.
Immediacy, said iReporter Jim Davidson, is one reason he posted his images of the downed plane in the Hudson on Flickr in addition to CNN.com. "When something like this happens, it's an easy way to syndicate it," said Davidson, who lives two blocks from the Hudson in Hoboken, New Jersey.
Social networking sites also enable spry reactions to news. Rob Reale of New York City started a Facebook group soon after the crash for the "Fans of Sully Sullenberger -- and the crew of Flight 1549" to celebrate the pilot who is being hailed as a hero for deftly landing the plane. The group quickly swelled to more than 27,000 members, some of whom posted video and photos and provided information that Reale used to update the page.
"I felt like the Facebook group was an opportunity to spread the good news," Reale said of the crash, which all survived. "Part of it was getting the word out and part of it was keeping that good feeling going."
Chris Krewson, executive online editor for the Philadelphia Inquirer, has a personal Twitter account in addition to posting tweets for his paper. Mainstream media is learning to better utilize online social networking to connect with its audience, he said.
"People are already talking about the news," Krewson added. "This is just a way for us to involve ourselves in the conversation
More people are turning to social networking sites for breaking news
Sites like Twitter, Facebook and Flickr provide firsthand accounts of disasters
Users enjoy the speed and immediate access of those posting
Professor: Citizen journalism sometimes happens accidentally
By Lisa Respers France
CNN
(CNN) -- Janis Krums was heading to New Jersey on a ferry when he clicked a snapshot with his iPhone of US Airways Flight 1549 partially submerged in the Hudson River. He uploaded the picture to his Twitter account and then forgot about it as he assisted in the rescue of the plane's passengers.
iReporter Julie Pukelis used a camera and a telescope to get this view of the scene in Hudson River.
The deluge of image views crashed the servers of TwitPic, the application that allows Twitter users to send photos with their Twitter updates or "tweets."
"I posted it because I thought 'That's pretty newsworthy' and I wanted to share it with the people who follow me on Twitter," Krums said. "I was letting some of the survivors use my phone and it wasn't until later that I looked and saw that I had quite a few messages."
More people are turning to social networking sites like Twitter, Facebook and Flickr when news breaks to share stories and pictures.
In an era when even the president of the United States has a Facebook page and spectators texted and tweeted about Inauguration Day, the power of online and digital social networking is clear.
Barack Obama tapped into the stream for his grass-roots presidential campaign and the Israeli Consulate in New York used its Twitter account to disseminate information during the recent Israeli-Palestinian conflict in Gaza.
Twitter doesn't release figures on the total number of registered users, but according to Compete, which offers analytics on Web sites, the site had more than 4.4 million unique visitors as of December 2008. Facebook has more than 150 million active users and Flickr has more than 34 million registered users worldwide.
Accounts of the deadly attacks last fall in Mumbai, India, the May 2008 earthquake in China and last week's plane crash show what used to be just a virtual gathering place to communicate pet peeves or plans for the weekend has evolved into a go-to spot for eyewitness news -- sometimes even before mainstream media has had time to crack the story.
Twitter co-founder Biz Stone said Twitter users were the first to alert others last summer after an earthquake hit Southern California. "The earthquake struck at 11:42 [a.m.] PST and at 11:42 PST people started twittering," he said.
Twitter allows its users to post messages, or tweets, to their accounts that are then distributed to those who are "following" that user online. Stone noted that there was an Associated Press story on the quake that he saw posted nine minutes later on their site and said that during those nine minutes there were more than 3,600 tweets.
"That's when it sort of struck home for me," he said. "With Twitter, we have this real-time feed of what people around the world are seeing, thinking and feeling."
Such citizen journalism is in some cases happening almost accidentally, said Susan Jacobson, an assistant professor at Temple University in Philadelphia, Pennsylvania, who researches the impact of technology on journalism.
"Most people are just sending this information off to their friends," Jacobson said. "The main thing to take from sites like Twitter and Facebook is that they are informal modes of news dissemination."
Part of that informality includes brevity -- tweets have a maximum capacity of 140 characters, and Facebook statuses can only be a few lines -- and the possibility of inaccurate information. Jacobson said users, especially those who have grown up in the digital age, are very much aware of that.
"Young people, I think, have an innate radar about what is legitimate and what is not," she said. "They realize that not everything they read and see on the Web is true."
Stephen Hultquist, a Boulder, Colorado, consultant who gets a great deal of his breaking news from Twitter, said traditional media sources also make mistakes or give skewed reports.
"If anything, Twitter reminds me that everyone is human and they all have their own views and a paradigm through which they see the world," said Hultquist who had a unique appreciation of the quick, firsthand tweets that came after the earthquake in China last year.
"I was five miles from the epicenter of the earthquake in 1989 that happened right before a World Series game and I noticed that the media that was reporting on it wasn't getting it all right," he said.
Immediacy, said iReporter Jim Davidson, is one reason he posted his images of the downed plane in the Hudson on Flickr in addition to CNN.com. "When something like this happens, it's an easy way to syndicate it," said Davidson, who lives two blocks from the Hudson in Hoboken, New Jersey.
Social networking sites also enable spry reactions to news. Rob Reale of New York City started a Facebook group soon after the crash for the "Fans of Sully Sullenberger -- and the crew of Flight 1549" to celebrate the pilot who is being hailed as a hero for deftly landing the plane. The group quickly swelled to more than 27,000 members, some of whom posted video and photos and provided information that Reale used to update the page.
"I felt like the Facebook group was an opportunity to spread the good news," Reale said of the crash, which all survived. "Part of it was getting the word out and part of it was keeping that good feeling going."
Chris Krewson, executive online editor for the Philadelphia Inquirer, has a personal Twitter account in addition to posting tweets for his paper. Mainstream media is learning to better utilize online social networking to connect with its audience, he said.
"People are already talking about the news," Krewson added. "This is just a way for us to involve ourselves in the conversation
2009年2月10日星期二
以色列最新大选结束
http://www.jpost.com/servlet/Satellite?cid=1233304741384&pagename=JPost%2FJPArticle%2FShowFull
Both parties claim victory and race to form rival coalitions
By GIL HOFFMAN AND JPOST.COM STAFF
Both Foreign Minister Tzipi Livni's Kadima party and Binyamin Netanyahu's opposition Likud styled themselves the winners of Tuesday's elections, after it became apparent that Kadima had won the most seats in the new Knesset, but the Likud-led right-wing would constitute the larger bloc.
Kadima's Nachman Shai cautious on exit polls
With 99.7 percent of the votes counted by 7:00 a.m., Kadima was narrowly leading Likud with a predicted 28 mandates, while the latter had garnered a predicted 27 seats. Israel Beiteinu was expected to earn 15 mandates, Labor 13, Shas 11, United Arab List five, United Torah Judaism four, National Union four, Hadash four, Meretz three, Bayit Hayehudi three, and Balad two.
The final results, including votes from soldiers and emissaries abroad, will only be published on February 18.
Overall voter turnout, which observers had feared would be low, was 65.2%, over two percentage points higher than in the 2006 national elections.
Livni had argued earlier in the day that whoever headed the biggest party should be deemed to have "won the public's trust" and should thus be charged with forming the next coalition.
But Likud leaders were already working on Tuesday to construct a "blocking" majority that would deny her any such prospect.
Israel Beiteinu, whose support could be critical to the nature of the next coalition, was to meet on Wednesday to discuss the options produced by the election outcome. But party leader Avigdor Lieberman, in a victory speech after midnight, indicated it was his intention to go with the Likud.
"We've turned into a significant party, the third largest in Israel," Lieberman told cheering supporters. "It's true that Tzipi Livni won a surprise victory. But what is more important is that the right-wing camp won a clear majority... We want a right-wing government. That's our wish and we don't hide it."
Both Netanyahu and Livni had called Lieberman on Tuesday night and asked for his support.
Kadima leaders expressed confidence that Livni would be able to form a government together with at least Labor, Meretz and Israel Beiteinu.
In an effort to reach out to Lieberman, Livni's associates said her first step as prime minister would be to change the political system, an issue at the top of his platform.
Livni challenged Netanyahu in statements throughout the day Tuesday to fulfill the public's desire for a national-unity government by joining a coalition led by her.
"As soon as Kadima gets more mandates, Bibi will have to stop with his manipulations and join a national-unity government," Livni said.
"Whoever gets more mandates won the public's trust and no one can argue with that. We are the only party that can form a national-unity government."
A Kadima official told The Jerusalem Post late Tuesday night that Israel Beitenu was more
of a natural partner in a future coalition than the Likud, and that Avigdor Lieberman's party was "not really in the right wing bloc."
"They are not on the right on the issue of a two-state solution. They support that solution but they want a land swap in it. They are not on the right on state-religion issues and they are not on the right on the issue of changing the system of government. Lieberman is pragmatic and he can definitely be in the coalition," the top Kadima official said. The official added that Kadima would like to form as broad a coalition as possible, but would settle for a Kadima-Labor-Israel Beitenu-UTJ coalition, which would give it about 63 Knesset seats.
Lior Chorev, another top Kadima strategist, said, "The President has to allow Livni the chance to form a coalition. It's going to be difficult, but if she gets a chance she will succeed. The last time she had the opportunity to do it she decided not to burden the Israeli taxpayer with billions of shekels paid to the ultra-Orthodox. Livni has a backbone that Netanyahu never had. This time she can get the moderate left and the moderate right. We will ask Netanyahu to join us. We know he is hurting now, but he'll take the next 48 hours to recover and then we'll talk to him. Lieberman can also join without too many problems. Lieberman's campaign is far from what he is when he's in the government, he's much more practical."
Likud MKs said that due to the six- to eight-seat victory of the Right bloc over the Left bloc, they expected President Shimon Peres to entrust Netanyahu with forming the government, even if Kadima ended up with more seats than the Likud.
They said they had no doubt that Livni would fail to form a government, because she was not able to build a coalition in October when the Left bloc had more seats.
"Netanyahu will be Israel's next prime minister," the Likud said in a statement after the exit polls were released. "The election proved that the path of the Likud and the national camp won. A clear majority of the nation rejected the path of Kadima and its partners and accepted the path of Likud and the nationalist camp."
The Likud leader called for the entire nationalist camp to unite under his leadership and said he would immediately begin efforts to form as wide a government as possible.
Peres intends to meet with the factions quickly to expedite the process of appointing a candidate to form a coalition.
In his concession speech, Labor Party chairman Ehud Barak said he would not join a government that "does not fit with what we believe" and that he was not afraid to join the opposition.
He cautioned against eulogizing Labor and vowed to rehabilitate the party and return it to power.
If the results predicted by the exit polls turn out to be accurate, the Likud would have fallen massively from as many as 36 seats predicted by polls taken in December to as few as 27.
But Likud MKs put a positive spin on the results by saying that the party had more than doubled its mandates since the 2006 election while Kadima had remained with around the same number of seats.
In Likud and Labor, opponents of the party chairmen already began talking after the exit polls about their leaders' failure. Both Netanyahu and Barak could face challenges to their leadership from inside their parties.
Netanyahu's nemesis in the Likud, Moshe Feiglin, released a statement saying that Netanyahu's battle against him took right-wing votes away from Likud and gave them to Israel Beiteinu.
A number of Likud politicians privately admitted that the party had assumed that the victory was theirs and had not campaigned hard enough in the last weeks before the election, a move that made them vulnerable to rival parties.
Tovah Lazaroff, Amir Mizroch, and Rebecca Anna Stoil contributed to this report.
Both parties claim victory and race to form rival coalitions
By GIL HOFFMAN AND JPOST.COM STAFF
Both Foreign Minister Tzipi Livni's Kadima party and Binyamin Netanyahu's opposition Likud styled themselves the winners of Tuesday's elections, after it became apparent that Kadima had won the most seats in the new Knesset, but the Likud-led right-wing would constitute the larger bloc.
Kadima's Nachman Shai cautious on exit polls
With 99.7 percent of the votes counted by 7:00 a.m., Kadima was narrowly leading Likud with a predicted 28 mandates, while the latter had garnered a predicted 27 seats. Israel Beiteinu was expected to earn 15 mandates, Labor 13, Shas 11, United Arab List five, United Torah Judaism four, National Union four, Hadash four, Meretz three, Bayit Hayehudi three, and Balad two.
The final results, including votes from soldiers and emissaries abroad, will only be published on February 18.
Overall voter turnout, which observers had feared would be low, was 65.2%, over two percentage points higher than in the 2006 national elections.
Livni had argued earlier in the day that whoever headed the biggest party should be deemed to have "won the public's trust" and should thus be charged with forming the next coalition.
But Likud leaders were already working on Tuesday to construct a "blocking" majority that would deny her any such prospect.
Israel Beiteinu, whose support could be critical to the nature of the next coalition, was to meet on Wednesday to discuss the options produced by the election outcome. But party leader Avigdor Lieberman, in a victory speech after midnight, indicated it was his intention to go with the Likud.
"We've turned into a significant party, the third largest in Israel," Lieberman told cheering supporters. "It's true that Tzipi Livni won a surprise victory. But what is more important is that the right-wing camp won a clear majority... We want a right-wing government. That's our wish and we don't hide it."
Both Netanyahu and Livni had called Lieberman on Tuesday night and asked for his support.
Kadima leaders expressed confidence that Livni would be able to form a government together with at least Labor, Meretz and Israel Beiteinu.
In an effort to reach out to Lieberman, Livni's associates said her first step as prime minister would be to change the political system, an issue at the top of his platform.
Livni challenged Netanyahu in statements throughout the day Tuesday to fulfill the public's desire for a national-unity government by joining a coalition led by her.
"As soon as Kadima gets more mandates, Bibi will have to stop with his manipulations and join a national-unity government," Livni said.
"Whoever gets more mandates won the public's trust and no one can argue with that. We are the only party that can form a national-unity government."
A Kadima official told The Jerusalem Post late Tuesday night that Israel Beitenu was more
of a natural partner in a future coalition than the Likud, and that Avigdor Lieberman's party was "not really in the right wing bloc."
"They are not on the right on the issue of a two-state solution. They support that solution but they want a land swap in it. They are not on the right on state-religion issues and they are not on the right on the issue of changing the system of government. Lieberman is pragmatic and he can definitely be in the coalition," the top Kadima official said. The official added that Kadima would like to form as broad a coalition as possible, but would settle for a Kadima-Labor-Israel Beitenu-UTJ coalition, which would give it about 63 Knesset seats.
Lior Chorev, another top Kadima strategist, said, "The President has to allow Livni the chance to form a coalition. It's going to be difficult, but if she gets a chance she will succeed. The last time she had the opportunity to do it she decided not to burden the Israeli taxpayer with billions of shekels paid to the ultra-Orthodox. Livni has a backbone that Netanyahu never had. This time she can get the moderate left and the moderate right. We will ask Netanyahu to join us. We know he is hurting now, but he'll take the next 48 hours to recover and then we'll talk to him. Lieberman can also join without too many problems. Lieberman's campaign is far from what he is when he's in the government, he's much more practical."
Likud MKs said that due to the six- to eight-seat victory of the Right bloc over the Left bloc, they expected President Shimon Peres to entrust Netanyahu with forming the government, even if Kadima ended up with more seats than the Likud.
They said they had no doubt that Livni would fail to form a government, because she was not able to build a coalition in October when the Left bloc had more seats.
"Netanyahu will be Israel's next prime minister," the Likud said in a statement after the exit polls were released. "The election proved that the path of the Likud and the national camp won. A clear majority of the nation rejected the path of Kadima and its partners and accepted the path of Likud and the nationalist camp."
The Likud leader called for the entire nationalist camp to unite under his leadership and said he would immediately begin efforts to form as wide a government as possible.
Peres intends to meet with the factions quickly to expedite the process of appointing a candidate to form a coalition.
In his concession speech, Labor Party chairman Ehud Barak said he would not join a government that "does not fit with what we believe" and that he was not afraid to join the opposition.
He cautioned against eulogizing Labor and vowed to rehabilitate the party and return it to power.
If the results predicted by the exit polls turn out to be accurate, the Likud would have fallen massively from as many as 36 seats predicted by polls taken in December to as few as 27.
But Likud MKs put a positive spin on the results by saying that the party had more than doubled its mandates since the 2006 election while Kadima had remained with around the same number of seats.
In Likud and Labor, opponents of the party chairmen already began talking after the exit polls about their leaders' failure. Both Netanyahu and Barak could face challenges to their leadership from inside their parties.
Netanyahu's nemesis in the Likud, Moshe Feiglin, released a statement saying that Netanyahu's battle against him took right-wing votes away from Likud and gave them to Israel Beiteinu.
A number of Likud politicians privately admitted that the party had assumed that the victory was theirs and had not campaigned hard enough in the last weeks before the election, a move that made them vulnerable to rival parties.
Tovah Lazaroff, Amir Mizroch, and Rebecca Anna Stoil contributed to this report.
订阅：
博文 (Atom)