gmane.comp.web.services.soa.yahoo-1

SOA Governance Maturity Model

babakh — 2008-12-02T15:16:48

Successful SOA rollout is dependent on SOA Governance. Despite the relative maturity of SOA, SOA Governance remains one of the most challenging barriers and key causes of SOA failure... You can read more on this subject at http://soa-biz.blogspot.com/2008/12/soa-governance-maturity-model.html Thanks! Babak Hosseinzadeh babak-VNEmlb9KZWdpEWg/Jp0smOqUGfbH9hYC< at >public.gmane.org ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Steven presents on REST of SOA

Gervas Douglas — 2008-12-02T12:02:24

<> You can read this blog and see Steve's presentation at: http://service-architecture.blogspot.com/ Gervas ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Roch Clarifies Some Key Terms

Gervas Douglas — 2008-12-02T11:46:56

<about CEP and BPM and so on point to misconceptions about how the technologies work together. Here are a set of observations about EDA, SOA, CEP, BPM and BRMS that I have learned from applying all of these technologies to real-world business problems. They are related to an order processing example that should help explain how the technologies are used together as follows: . State is the status of a business process (where we are in an order process) . An event is a change in state meaningful to the business (a quote becoming an order) . Event driven architecture (EDA) is the design of systems to respond to events where a state change is published as a message and can be consumed by many message subscribers (a product order can independently trigger the warehouse management system to pick an item, a purchase order to a supplier and an email to the customer with the estimated delivery date - these systems can be completely decoupled) . Changes in business state are recorded (for an automated process the system has to record the state change to function properly - to record the change of a quote to an order) . Business services can be event driven - publish or consume messages and trigger or result from business process execution (the purchase order process can "listen" for a event that the inventory level for a product has reached the reorder threshold and consume a service to place the purchase order) . Changes in business state are highly correlated to business services (an order service is needed to create an order from a quote) . Business Process Management (BPM) automates business processes using workflows that consume services (sales creates an order quote within a workflow and the worflow can automate the creation of an order using the order service) . Individual tasks in a BPM workflow automating a business process are not highly correlated to events or services (the steps to collect data for an order, up-sell products, suggest substitutes might be a workflow without state changes, events or services) . Business rules can be implemented as operational decision services within a Business Rule Engine (BRE) and consumed within a workflow (an order of greater than $100,000 requires approval - the business can change the max value) . A decision service makes a stateless decision (the decision service is not responsible for recording state changes and does not store process state) within a workflow (does the customer have sufficient credit to place the order) . Complex Event Processing (CEP) examines the relationships of multiple business events with the goal of identifying and correlating meaningful events (multiple orders for the same product can trigger shifts in product logistics, orders to suppliers, promised ship dates and service level agreements - multiple related events) . CEP records the state of events whereas decision services (or rules) does not (CEP has to know what products are in the supply chain, logistics routes and on order to know what impact a supplier delay would have to orders) . CEP and decision services are real-time, operational decisions whereas business intelligence decisions are based on an analysis of historical data aimed at knowledge workers (BI can answer what products sell at what stores during what season) SOA helps integrate these technologies into a coherent architecture with each technology performing the tasks they are designed for creating efficient architectural layers for business solutions. CEP, by the way, is not new as some have suggested. Like SOA, CEP has been around for a long time and is now enjoying increased adoption due in a large part to software vendors including the technology as part of their SOA "suites" and increased interoperability between the tools using web services and XML. The History of Complex Event Processing - Modern event processing grew its roots in the mid 1990's, when academic research began at Cal Tech (Mani Chandy), Cambridge University (John Bates), and Stanford University (David Luckham)... Commercial software companies were created based on this research. Chandy's work spawned the iSpheres (acquired by Avaya last year), and Bates co-founded Apama with Giles Nelson in 1999. In 2002, Luckham published a book called: "The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems" that helped popularize the term "complex event processing," or CEP. In 2003, two more vendors were founded - Coral8 (Stanford) and StreamBase (MIT / Brown / Brandeis; Michael Stonebraker / Stan Zdonick / Mitch Cherniack). TIBCO BusinessEvents entered the market in 2004 as well. Other CEP firms include Kaskad, Aptsoft, and Aleri Labs.>> *You can read this blog at: http://it.toolbox.com/blogs/the-soa-blog/eda-cep-bpm-brms-and-soa-28565 Gervas*

[ZapFlash] 2009 New Year's Resolution: Rethink your Training Strategy

Gervas Douglas — 2008-12-02T11:32:26

ZapThink 2009 New Year?s Resolution: Rethink your Training Strategy Document ID: ZAPFLASH-2008121 | Document Type: ZapFlash /By: Ronald Schmelzer/ Posted: Dec. 01, 2008 As we wrap up Thanksgiving Day (in the United States) and head into the greater part of the winter holiday season, our thoughts inevitably turn to an evaluation of the year gone by and goals for improvement in the year ahead. Some of us may even promise to exercise more, eat more healthfully, and take care of our personal lives better, and we may indeed keep those promises. But at ZapThink we would like you to commit to a New Year?s resolution we know you can keep: improve your Service-Oriented Architecture (SOA) skills by rethinking your SOA training strategy. ZapThink is fond of saying that ?SOA is something you /do/, not something you /buy/ .? Yet many so-called architects short-cut the step of actually doing architecture by hoping to buy their way to SOA. By now, we don?t have to tell you that you won?t get SOA by simply accumulating a set of SOA infrastructure products, development tools, or Services from enterprise application products . You know that architecture is a discipline and set of activities that affect not just the technology, but also the organization, governance, and processes of the business. Yet, while you might know all that implicitly, your actions belie your beliefs. Even after buying those tools, many resort to learning SOA by simply learning how to use the tools they?ve purchased. This approach to learning how to do SOA simply won?t work. Doing SOA right means learning how to do SOA ? not just how to implement a vendor?s SOA infrastructure products. In order to make progress on SOA in 2009, you should look at how you?re gaining SOA expertise. Have you thought about how you are learning to do SOA? And how to do it right? Have you thought about who you are getting that education from and what are their motivations? Is it possible you?re paying for SOA training but just getting product-specific implementation and developer-level training? After all that training are you still scratching your head wondering how (or if) you?ve done it right? If so, you need to rethink how you acquire the critical skills necessary to make SOA a critical success. *The Problem with Vendor-Specific Architecture Education* Architecture is not development . Assembling a bunch of Services does not yield an SOA. Perhaps you already know that. But what about your training and skills development efforts reinforce those beliefs? In order to separate the activities of architecture from development, you need to learn the methods, practices, disciplines, and approaches of architecture. Architectural training focuses on acquiring expertise on how to actually /do/ the various activities of architecture. This means that at the end of a given training activity, you should be able to use /any tool or SOA infrastructure product/ to design a Service, implement a Service model, run effective governance, quality, and management (GQM) , manage a Service domain, implement a SOA test plan, among other activities. Yes, it is true that to actually build and run those Services you will need more training to learn how those tools work, but if you don?t have expertise in the abovementioned fundamentals, how do you ever stand a chance? To further reinforce the ?learn methods before learning tools? best practice, it should be said that learning SOA is not simply a matter of learning how to use tools. To use an analogy, don?t confuse knowing how to use a cake mixer with knowing how to bake a cake. Anybody with a few minutes can learn how a cake mixer works and what its various settings are, but learning how to bake a cake takes time and experience to master. So where does the ?tools before methods? sub-optimal style of training come from? Many SOA infrastructure and development tool vendors offer SOA training as part of their offerings, and many end-users opt for the path of least resistance (or cost) and get their training from these vendors. While a handful of these vendors put some effort into incorporating vendor-neutral, industry-wide best practices and methodologies into their training curricula, most of these vendors simply see SOA training as a means to selfish ends. Some notable SOA vendors have admitted to us that they see SOA training as ?loss leaders? to sell other things such as software or services. From this perspective, they offer training at greatly reduced prices or even free as a way of qualifying the customer to buy more stuff. It?s sort of like those ?exclusive passes? you get to distributor showrooms to demonstrate something when all you?ve done is volunteered yourself for a multi-day sales pitch on their offerings. Are you doing yourself any service by skim-coating your SOA activities with a smattering of SOA methodologies know-how while diving deep into implementation details of SOA Vendor Product version 3.2? We at ZapThink think not. Other SOA vendors have admitted to us that they see training as part of their customer support efforts. These vendors see training as a way of helping customers use their products. In these cases, the training is not meant to actually enable organizations to fill in the missing gaps in their SOA skills, but rather to maximize customer satisfaction with products already purchased. End users that see training as an aspect of support should prepare themselves for the need to always play catch-up. No thought-leading organization would relegate training in such a manner. Lest you think that software vendors are alone with such training practices, we can assure you that we?ve seen SOA consulting firms of all sizes likewise approach training as a pre-sales consulting add-on or as a checklist item in an RFP delivery. ZapThink recently provided training for an organization that had previously brought in a well-known SOA consultancy to provide SOA training. The customer's complaint was that the consultant knew the material in the course, but any time someone had a question that wasn't specifically about the material, the answer was "I'll have to get back to you on that." This is simply unacceptable. SOA trainers need to be architects and SOA experts. Any /schmoe/ can read slides and fuddle their way through SOA exercises, but actually gaining expertise in how to do SOA right requires learning from someone who has both experience in the space as well as knowledge on SOA skills development. This requires a breadth of experience that goes beyond the material itself. If the self-serving sales and support focus wasn?t enough, what makes this consultant/vendor-driven SOA training particularly problematic is that many such training courses masquerade proprietary vendor or consultant methods as industry best practices. Vendors and consultants often develop courses around a methodology they developed for a customer. This content then makes its way into training curricula without any third-party vetting of those practices or even an understanding of other practices in the space with which to compare. Smart architects should press these trainers to explain how their approaches compare to others in the space and explain what about their practices are indeed ?best?. Furthermore, IT managers should demand that SOA training curriculum be vetted by credible third-parties to ensure that they are not simply getting indoctrinated into proprietary approaches that promote single-vendor or single-consultant lock-in. You deserve /pragmatic/ SOA training, not /dogmatic/ SOA training. *The ZapThink Take* If you haven?t already noticed, ZapThink has a bone to pick with much of the so-called SOA training currently offered in the market. Certainly there is a role for vendor-specific training, and the best source for such product-specific or consultant-proprietary offerings is the firms themselves that developed those tools and approaches. However, those that are serious about developing SOA skills need to beware the training version of Vendor-Driven Architecture (VDA) . Just as you should only buy tools once you have determined your architecture and not vice-versa, you should buy vendor-specific training only once you have already mastered the fundamentals of architecture that are necessary to implement any vendor or consultant?s offerings well. Architects should also understand that the Return on Investment (ROI) for training and skills enhancement far outweighs that of tools purchases or consulting engagements. While a good SOA tool can return up to 200% of value over the investment, good training returns tens of thousands of percentage points of value. A single four-day course of the type we recommend above can cost as little as $2,000 , but yield hundreds of thousands of dollars of returned value in accelerated SOA initiatives, higher overall project quality, reduced waste in development and tool purchasing, and better overall alignment of the SOA activities with business requirements. Investing in tools is a capital expense that is amortized across multiple SOA projects. Investing in skills development is an operational expense that yields persistent returns throughout the lifetime of the human resource. Furthermore, while the ROI of tools investments are perishable, the ROI of training and skills enhancements are permanent. Vendor training is highly perishable since as soon as the tools change, your product-specific training becomes obsolete. Whereas methodology training is highly durable ? even as methodologies evolve, they simply improve on what?s been done before or just add more capabilities. At the end of the day, who is in charge of your architecture? You! You control the evolution of your architecture, so you should be in control of your education. ZapThink has a vested interested in the growth of SOA as a credible and valuable discipline. And this requires that we rethink our approach to training. Put this in your resolution list for 2009.

policy-driven security

henryk mozman — 2008-12-02T06:01:34

Hello all, I am looking into SOA policy-driven security (as in Governance) What is the current of this technology ? Henryk

New poll for service-orientated-architecture

2008-12-01T16:36:00

Enter your vote today! A new poll has been created for the service-orientated-architecture group: Do you think Governance is a central factor in the success of a strategic SOA project? o Up to a point/not always o No o Yes To vote, please visit the following web page: http://groups.yahoo.com/group/service-orientated-architecture/surveys?id=2458183 Note: Please do not reply to this message. Poll votes are not collected via email. To vote, you must go to the Yahoo! Groups web site listed above. Thanks! ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Poll results for service-orientated-architecture

2008-12-01T16:34:35

The following service-orientated-architecture poll is now closed. Here are the final results: POLL QUESTION: How do you pronounce "SOA"? Do you spell out the letters S-O-A or do you pronounce it to rhyme with "slower"? CHOICES AND RESULTS - Spell out S-O-A, 20 votes, 50.00% - To rhyme with "slower", 15 votes, 37.50% - Either, 5 votes, 12.50% INDIVIDUAL VOTES - Spell out S-O-A - michaelc.champion-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org - jim-KbPxBdIIuGhWk0Htik3J/w< at >public.gmane.org - rezaloo-PkbjNfxxIARBDgjK7y7TUQ< at >public.gmane.org - kevin.m.johnston-r3q2otnueiw< at >public.gmane.org - anantharams-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org - luc-lZcY9+MTeivk1uMJSBkQmQ< at >public.gmane.org - drunkinyonkers-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org - pras_patel-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org - c_dantonio-HInyCGIudOg< at >public.gmane.org - david.moskowitz-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org - distobj-HInyCGIudOg< at >public.gmane.org - patrick.d.logan-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org - denis.krizanovic-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org - Bill.Wilder.FIIS-WAQBmITiDcc< at >public.gmane.org - todd-l89NLvRP/40AvxtiuMwx3w< at >public.gmane.org - e.masoudifar-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org - sridharsa-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org - bkmikesell-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org - sagui_herrera-mRCrAkd8dF0< at >public.gmane.org - reamon-9jPBLdyrytDk1uMJSBkQmQ< at >public.gmane.org - To rhyme with "slower" - atmanes-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org - ragr-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org - jomuench-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org - gervas.douglas-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org - aniltj-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org - stefan.tilkov-VN3JQt9ukasAvxtiuMwx3w< at >public.gmane.org - alexrosen-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org - scottgregory-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org - bryondonahue-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org - objectiveous-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org - peter.madziak-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org - oengel-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org - javier.camara.melgosa-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org - papen82-IWqWACnzNjyonA0d6jMUrA< at >public.gmane.org - nmcl2001-/E1597aS9LT10XsdtD+oqA< at >public.gmane.org - Either - rlitai-/E1597aS9LRfJ/NunPodnw< at >public.gmane.org - teresa.jones-9OQkdRNQWwmZox4op4iWzw< at >public.gmane.org - scott.freeman-AIYf9rW3OuxIeQp9dFSZELVCufUGDwFn< at >public.gmane.org - rlara-JHs2hfERKxQ< at >public.gmane.org - jim.murphy-e+AXbWqSrlAAvxtiuMwx3w< at >public.gmane.org For more information about this group, please visit http://groups.yahoo.com/group/service-orientated-architecture For help with Yahoo! Groups, please visit http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.html ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

New poll for service-orientated-architecture

2008-12-01T16:34:16

Enter your vote today! A new poll has been created for the service-orientated-architecture group: Is BPM a key ingredient of your SOA? o No - most of our services are built to support application integration. o Yes - most of our services are built from and to support business processes. o We use SOA to support business processes directly and to aid application integration. To vote, please visit the following web page: http://groups.yahoo.com/group/service-orientated-architecture/surveys?id=2458160 Note: Please do not reply to this message. Poll votes are not collected via email. To vote, you must go to the Yahoo! Groups web site listed above. Thanks! ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Fw: Is SOA dead?

Sasan — 2008-12-01T15:07:29

----- Forwarded Message ---- From: Global WebSphere Community public.gmane.org> To: sasanplus-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org Sent: Monday, December 1, 2008 2:33:16 PM Subject: Is SOA dead? Is SOA dead? Dear GWC member, Event title: Is SOA dead? Event date and time: December 3, 2008 - 3:00pm EST Registration URL: https://groupintelligence.webex.com/groupintelligence/k2/j.php?ED=111463922&UID=1038643512&FM=1 Description: Many organizations have started down the path of SOA, only to find that reality is more challenging than the hype. Businesses need to see ROI, and IT professionals have a hard time staying on the theoretical course. So, how are we going forward? In this web-event, we will focus on the current problems around SOA, suggest successful strategies towards attaining SOA benefits and discuss how you can be the catalyst for improving IT and Business-IT alignment: essentially, making SOA work in the here and now. Our main topic will be SOA governance: coordination, ownership, right-to-decide and versioning of services are all critical factors in SOA. Other topics will include: service lifecycles, portfolio management and an SOA maturity model. The content of this event is based in part on the book "SOA for Profit, a Manager's Guide to Success with Service Oriented Architecture". After the event, we will send attendees an electronic copy of this book. Speaker Profiles: Erik Van Ommeren is the Director of Innovation for Sogeti USA and is responsible for VINT, the international research institute of Sogeti. The VINT Research institute has published and organized events around topics such as Open Innovation, new media developments, the business value of IT and IT governance. The continuing theme of VINT research is how new technology is actually used to achieve business goals. Erik is an analyst with a broad background in IT with experience ranging from software development using many different technologies to Enterprise Architecture and executive management. Part of his time is spent advising organizations on transformation projects, architectural processes and innovation. Erik is also a trainer, speaker at seminars and author of several books and articles. He is an author of both 'SOA for Profit - A Manager's Guide to Success with Service Oriented Architecture' and 'Open for Business -Open Source Inspired Innovation'. His latest book is 'Collaboration in the Cloud', which is written in cooperation with Microsoft. Contact: Erik.vanOmmeren-mLPphF0ISTjQT0dZR+AlfA< at >public.gmane.org Ram Seetepalli (PMP) is a Practice Director at Sogeti USA's Houston office. He has extensive real-world experience in SOA, Enterprise Architecture, Governance, Organization Optimization and Strategic Planning from providing consulting services to high-profile clients in several industries around the country. He has developed, provided formal training and mentored large teams at Fortune 500 clients on SOA and Business Process Management. Contact: Ram.Seetepalli-mLPphF0ISTjQT0dZR+AlfA< at >public.gmane.org Registration URL: https://groupintelligence.webex.com/groupintelligence/k2/j.php?ED=111463922&UID=1038643512&FM=1 Global WebSphere Community ________________________________ email: info-McxU9Gq8IxrNLxjTenLetw< at >public.gmane.org web: http://www.websphere.org Forward email This email was sent to sasanplus-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org by info-McxU9Gq8IxrsgmR90Yw4Tw< at >public.gmane.org Update Profile/Email Address | Instant removal with SafeUnsubscribe™ | Privacy Policy. Email Marketing by Global WebSphere Community | 2500 Harborside Financial Plaz | 25th Floor | Jersey City | NJ | 07311

Proprietary SOA versus Open Source SOA

Gervas Douglas — 2008-12-01T15:03:33

There has been much commentary in various blogs about the respective advantages of Open Source and Proprietary SOA software tools. Most of the commentary seems to be in favour of Open Source with such points being made as: (1) It is cheaper in TCO terms, as well as obvious licence expenses; (2) It tends to perform certain well defined functions while avoiding bloatware overheads; (3) It tends not to be a jumble of software stacks shoved together in an unwieldy mass as a result of post-acquisition consolidation. However, the major vendors are still in business and often have a loyal following among major customers. It would be interesting to hear the arguments on both sides, particularly from the proprietary camp, which could be judged as needing to articulate its case more clearly. Gervas PS I am neutral about the aforementioned points. ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

SOA in Danger of Over Hype, Over Spending, and Bad Practices

Gervas Douglas — 2008-12-01T13:29:13

The following article was sent to me as an e-mail from David Linthicum. Gervas SOA in Danger of Over Hype, Over Spending, and Bad Practices David S. Linthicum In a recent Burton Group event, the analysts stressed what I've been beating to death for years now, that too many companies are over spending in the SOA space, too early, and are not thinking through the core issues. Thus, many initial SOA project are in danger of hitting a wall before the core value of SOA is understood. The Burton analysts stressed that you don't need to chase after some Enterprise Service Bus (ESB) with every possible option, or try to support the latest chic Web services standards to achieve service orientation. Indeed, they are describing what SOA really is--an architecture style--and thus something you do, not something you buy. However, don't tell the vendors that. The hype in the SOA space is raging right now, largely due to the amount of marketing money that's being spent in order to both create and capture the demand. You just don't feel like you're a true enterprise unless you have an ESB and governance tool, no matter that you've not figured out how to use them yet. Indeed the big "SOA stack" players are in the market early with enterprise license agreements that lock in their customer into an all-you-can eat SOA technology buffet that will supposedly provide them with solutions to all of their SOA needs. The truth is much more complex and less exciting. In actuality, each enterprise is like a snowflake, and the problem patterns present vary greatly from problem domain to problem domain, enterprise to enterprise, as I'm finding both in my consulting practice and data points with a number of SOA practitioners out there. Thus, selecting technology before you understand your unique issues, puts your first SOA project at risk and will cost you dearly, considering that this is the mother of all mistakes that you can make here. There is much homework to be done before you can begin shelling out the big dollars for the big SOA technology, and more often than not you'll find the technology that's a fit is not the technology you had first thought. Case in point are the number of projects I'm finding where ESBs are not the correct solution, but their early purchase means it's a "force fit" which means the project is at risk, and at the very least, the solution is not optimal. Not that ESBs are bad; they are not. However, like any technology, ESBs do not fit within all SOAs. Same can be said about SOA governance tools, SOA security solutions, service development tools, etc.. You can define your architecture around technology, and the reverse is also true. The fact of the matter is that you need to go through some iterative steps before you can even begin to define your technology requirements, and look for products that fit them. First, you need to understand your data at the semantic, metadata, and abstraction levels. This means a clear definition of what's there, what's needed, and how it should be modeled and implemented as a part of your SOA. Data is the foundation, services are the externalization, and processes are the solution. Keep that in mind. Second, you need to identify all candidate services, or potential services in your domain. This means going on a service mining expedition, looking at mainframes, and other enterprise applications for core business processes that need to be externalized as services for the architecture. This means working back from screens, APIs, and transactions, and the creation of a solution for recasting them as services. Third, you need to figure out the meta-processes that are a part of the domain. This will become the foundation for your orchestration and/or choreography layers, in essence, defining how the services interact and providing a platform for driving them together into solutions. Beyond all that you need to figure out performance, security, service tracking, service level agreements, policy management, design time, run time, and any special needs that your project/domain may have, and there is always something that's unique. Then, and only then, do you figure out your technology requirement. Those who jump right into the SOA hype pool full of SOA technology are finding a few things out. They are not solving their problem, they are not using best practices, and worst of all, they are putting their projects at risk and spending too much money in doing so. I'm not sure if this is one of those "let the kid touch the hot stove" issues, where a few painful failures will teach the masses that this is the wrong approach, or if I need to keep jumping on my soapbox and preaching the very unpopular notion that SOA is complex, hard, and if you're going to make it work, it's going to take some work. Sorry to be the buzz-kill, but somebody has to speak up. Happy to listen to other options here.

Wallis on SOA and WOA

Gervas Douglas — 2008-12-01T12:07:48

<> You can read this at: http://www.sys-con.com/node/666938 Gervas ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Paul corrects Steve Vinoski

Gervas Douglas — 2008-12-01T11:49:53

Synodinos on the Web's Popularity as a Platform

Gervas Douglas — 2008-12-01T11:19:40

You fans and otherwise of REST might find the the following article of interest: http://tech.groups.yahoo.com/group/n-gaa/message/1065 Gervas ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Anne explains why SOA does not have to be expensive

Gervas Douglas — 2008-12-01T11:00:52

<< Blogger: Anne Thomas Manes 643 It's a common misconception that SOA is expensive. Many organizations believe that they need to acquire a boat-load of new products and technologies to get started with SOA. First on the list of product acquisitions is an ESB, followed by registries, repositories, and security appliances. In these belt-tightening times, many SOA initiatives will be challenged to raise the funding required to acquire these products. So what's a team to do? Pack up and wait for better times? Or make do with what you have? In truth (and much to the vendors' dismay), you don't need a bunch of new products to do SOA. SOA is about the way you design your solutions

Kavis explains why you should go for Open Source

Gervas Douglas — 2008-11-28T13:27:17

<. In his post Dave stated: When it comes to SOA, I think open source provides two major advantages: * First, it's typically much less expensive than the tools and the technology that are proprietary. * Second, they are typically much more simplistic and easier to understand and use. To the second point, simplicity. The open source SOA vendors seem to take a much more rudimentary approach to SOA, and their tools seem to be much easier to understand and, in some cases, use. While some people want complex, powerful tools, the reality is that most SOAs don't need them. If you're honest with the requirements of the project, you'll see that good enough is, well, good enough. Great point Dave. I would also add another clear advantage which I learned the hard way. On a previous enterprise wide SOA initiative, I drank the cool-aid that the vendor stack was an integrated stack and was simpler to deploy and manage over a stack of a mix of vendors. What I found out is that the mega vendors (IBM, Oracle, etc.) have bought so many pure play tools (rules engines, BPMs tools, data services and MDM tools, governance tools, etc.) that the smooth integration ends when the Power Point decks are closed. In reality, the mega vendor stacks are a hodge podge of rushed acquisition and integration efforts. The underlying architecture of each tool within the stack are completely different and there are very few people (if any) within the organization who understands the complete stack. In fact, we were dealing with two very different organizations when dealing with support and they were not in sync. Eventually the entire company was consumed by another mega vendor (you can probably guess which acquisition this was) and the whole product roadmap was turned upside down. Now let's look at some of the well established open source stack vendors like WSO2, MuleSource, and RedHat. These vendors do not suffer from acquisition madness and chaos. If fact, they are all built on a consistent architecture and do offer smooth integration between the various layers of the stack. Do they have all of the features of the commercial products? No. Do they have enough features for most SOA initiatives. Definitely. I wrote a post on CIO.com called Tight Budgets? Try open source SOA . Here is a quick summary of the advantages I discussed (read the article for the details): 1. *Try before you buy* 2. *Lower cost of entry* 3. *Cost effective support* 4. *Core competency* 5. *For the people by the people* So what open source options do I have, you might ask? The following picture shows the open source tools that I prefer for my new SOA initiative. We are using a combination of WSO2 , Intalio , Drools , Liferay , and PushToTest . This is just one example of many. You can mix and match tools from different open source communities or you could standardize on one community. Here is an example of Red Hat's jBoss SOA stack. And MuleSource has a well known suite of tools as well. Many organizations are still not very comfortable with open source for mission critical initiatives. I have debunked many of the open source myths in the past (here , here , and here ). If there ever was a time to embrace open source, the time is now in this harsh economy. As commercial SOA vendors continue to get gobbled up by the mega vendors, it is time to seriously consider alternatives.>> *You can read this blog at: http://it.toolbox.com/blogs/madgreek/why-an-open-source-soa-stack-makes-sense-28490 Gervas*

Pereira on selling SOA in a recession

Gervas Douglas — 2008-11-28T12:23:19

<> You can read this at: http://www.channelinsider.com/c/a/News/SOA-Could-Rebound-as-RecessionBusting-Strategy/ Gervas ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

SOA conferrence

thakur_vikram19 — 2008-11-28T07:57:47

We are hosting a one-day seminar in chennai on Dec-13,2008 called "ESOA2008" on Enterprise Service Oriented Architecture. We have world champions as Key Note Speakers. We are going to have very fine gentlemen like Dr. Pallab Saha, Graham Mcleod as key note speakers in the conference who are going bring their rich, world class experience in SOA and Enterprise Architecture to you and your employees. In this seminar we will reveal the "Hidden Secrets" of SOA and guide you through the process of "Philosophy-->Practicality". We also?Theory issue certificate of completion of "SOA" course for our attendees. The seminar is full of case studies and business cases and will be highly interactive and informative. We have couple of panel discussions where we are going to have heated discussion regarding tools and services around EA-SOA space which will be an excellent benefit for attendees. Please visit www.esoaconference.com for further details. Please contact us at esoa2008< at > digiblitz.com or registration< at > esoaconference.com for registration and further details. We can be reached over phone on 0172-4668670/0172- 4668579/9600066602/9600066102/9840700639. We also have wonderful package for sponsorship if your organization is interested in. Please call Suresh < at > 9840700639 ( sureshkb< at > digiblitz.com ) or Gaurav < at >9815818056 ( gaurav.sogi-Qiy7afQMRGjCXR85Y8Hu3Q< at >public.gmane.org ) or Vivek < at > 9444352306 ( vivek.bhasin-Qiy7afQMRGjCXR85Y8Hu3Q< at >public.gmane.org ). Suresh Balabisegan President & Chief Architect, digiBlitz Technologies Inc 751 Miller Dr SE Suite D-3, Leesburg, VA 20175. Ph: 571-722-6279 Fax: 703-852-4367 ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Loraine, Nick, Pixie Dust and SOA

Gervas Douglas — 2008-11-28T00:37:41

<> You can read this at: Gervas ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Prasad on JSON Schema

Gervas Douglas — 2008-11-27T14:46:08

<> You can read this blog at: http://wisdomofganesh.blogspot.com/ Gervas ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Michael on resolving the RIA-SOA conflict

Gervas Douglas — 2008-11-27T14:38:33
*You can read this article at: http://soa.sys-con.com/node/730632 Gervas* < illustrates a scenario in which RIA screen widget events originate RIA requests. Depending on the application, they may be more or less fine-grained. If such requests directly contact the points of invocation of SOA business services (service clients), then two inefficiencies happen: * Business service interfaces and returned data get unutilized, reducing the power and defeating the purpose of the SOA business services * Business services have to be called much more frequently than they could be with adequate interface usage; this also overwhelms communication channels/network A friend of mine said, when we discussed the RIA-SOA topic, that he was fully entitled to have a service that provided a merchant's price to his RIA. The price was assumed to be taken from a back-end data store. I agreed with him but thought that the interface should not be concerned with where the price value had come from until it was correct. Besides, would it make sense talking about the merchant's price in isolation from the presentation context? It was very likely that the merchant had to be represented on the RIA screen by its other characteristics provided by a sort of business service running behind the scenes. All these gave me the idea for the RIA-SOA collaboration pattern that I am going to discuss. *RIA-SOA Collaboration Design Pattern* */Problem Summary:/* * RIA requests mismatch the granularity of the SOA business service interfaces * RIA and SOA requirements have no common points suitable for integration */Problem Explanation:/* See the discussion in the previous section */Solution:/* * Use a conciliator module between RIA requests and SOA business service interfaces * Conciliator module responsibilities: -Bridge business functionally provided by SOA business services and business user interface functionality -Convert data structures from the business service interface format into a user interface format for a particular RIA widget, and vice versa -Provide a way to optimize usage of the SOA business service as well as prompt and correct responses to the RIA requests The most trivial optimization of business service usage is using it as designed - with a coarse-grained interface and related business data model. In addition, since some RIA/UI functionality may be dependent on the changes in the business environment, the SOA business service may be used in a "subscription" mode. That is, RIA can send a subscription request via the conciliator, and the business service starts monitoring for particular business events or business data changes and delivers the appropriate information to the conciliator. The latter can share this information between interested RIA requests. Figure 2 illustrates the RIA-SOA collaboration design pattern. The RIA-SOA collaboration pattern has some similarities with the known J2EE front controller pattern: the conciliator, as a controller, deals with remote client (browser) requests and responses. However, this is where the similarity ends. A front controller pattern operates as a dispatcher, performing view/templating selections while the conciliator's major task is to make granularities, data formats, and invocation models conform. The conciliator can include a front controller pattern similar to how a proxy pattern can include a delegate pattern when needed. *Implementation Examples* */Example 1 - Direct Cache Conciliator/* An implementation of a conciliator is a web cache. If the conciliator does not find the information to respond to an RIA request in the cache, it invokes a related business service "on demand." The returned service results are accumulated in the cache. Analogous requests never go further than the cache. Each service result has a timeout and is subject to a refresh. The conciliator takes care of the refresh schedule while the service delivers results. For RIA requests representing three types of UI requirements - information exchange, information representation/reports, and user operations against the systems - the conciliator acts accordingly, i.e., it only caches responses that might be reused. Among others, the conciliator provides a mechanism for data format transformation where necessary. That is, the conciliator caches service results after the transformation. It would be an insufficient solution if we required SOA business services to return data in the format of an external UI because the service may have associations with many interfaces. In the service-oriented approach, the interface serves the business service, not vice versa; the business service is the driver, i.e., the "A" part of RIA drives its "R" part. The service defines which business functionality to expose via this or that interface, rich or not; the interface adds only the user experience capabilities. This is why we need a bridge between presentational (RIA) and processing (business service) data formats. Moreover, the interface or client part of RIA isn't supposed to be aware of the data models and formats that the application operates on and that persist. So a statement like "my RIA (client) needs the merchant price stored in a particular field of a particular database" violates the principle of separation of concerns. Of course, the interface must have the price value but where it comes from is the service's "business" in service-oriented applications. /*Example 2 - Presentation Services Conciliator*/ The conciliator may have a more complex implementation than just a Web cache. It may include fine-grained presentation services serving the remote actions and events of the RIA widgets while working against the Web cache. Presentation services run in the presentation tier and serve UI exclusively. They also add flexibility to the Web cache and can support the federation of distributed Web cache affinities. That is, the power of the distributed Web cache can be dynamically increased or decreased in accordance with the richness of RIA. Presentation services can perform the data format transformation described in Example 1. They can also invoke infrastructure services like security, for example, for end-user authentication, simple business services like currency conversion that is fine-grained by definition as well as operation statistics services. However, what the presentation services must avoid are the same bad habits found in regular Web applications - for instance, the direct engagement of resource drivers, like database drivers, straight from the presentation tier. Straightforward retrieving and storing data in the persistent storage has nothing to do with service orientation and, if applied, should not be called business service actions. If somebody wants to couple a UI, even a rich UI, with a database, we're not talking SOA. Since SOA is usually an enterprise, or a line of business, or business unit solution, it crosses several applications that might have shared data stores. SOA assumes the use of a Data Access Layer (DAL) in between the business services and data stores. Data access services working in DAL don't replace store drivers but provide RWE via accumulating, aggregating, and composing business data from the sources, according to the preliminary defined business rules. Still, data access services are considered infrastructural services because they might depend on specific data stores or legacy applications. The reason for using presentation services versus direct access to the cache is that they can be reused for similar types of interfaces or widgets. That is, they can be reused in different RIAs or parts of RIAs. If presentation services are owned by the RIA, coupling presentation services with business service programmatic interfaces is not recommended. For example, RIA might have independent widgets that refer directly to the business process (the user journey) implemented by the RIA; such business process can obtain needed business functionality from different business services that might have been unknown when the RIA was designed. At the same time, there's the case of a UI being bundled with a SOA business service; we will discuss that in the next section. *SOA Meets RIA* In one of his very interesting publications, John Crupi said: /"What I really want is a user-based composite application, not a middleware-based composite application....Direct connect SOA conveys the ability to punch through the traditional curtain of portals and heavyweight process engines and directly (at least conceptually...) access SOA services. I don't just mean Web services either. It could be BPEL orchestration services, coarse-grained POJO services, RSS feeds, or anything else that can be exposed as a 'service,' albeit at the right level of business granularity."/ This is quite the right approach to so-called social or community applications. However, it's difficult and dangerous to allow a user to compose applications in the financial, manufacturing, pharmaceutical, medical, and similar industries without strict control over the composition. I'm talking about composite applications, not about their interfaces. The danger comes from unknown and uncontrolled resulting RWE - we cannot assume that all end users know and understand all interdependencies between SOA services when they start working on compositions. Plus, the behavior of SOA business services depends on the execution context. A composition represents a new context and service provider must test the service before promising that its behavior hasn't changed in the context. For example, a service execution context contains a policy that may be dependent on the locale - the country where the service is used. Financial laws in the U.S. and U.K. are different and application of related policies can result in different RWEs for the same business service operation and data. We have to remember that a SOA business service is not the same thing as a Web Service's WSDL with a couple of operations named after the business functions. Saying this, I can only imagine one possible user-driven service composition - the one that is preliminarily tested and represented to the end user as a limited set of combination variants. That is, a meaningful business-driven approach (or RWE compatibility) constrains the presentation capabilities, especially in a rich user interface. This line of logic lets me look at the RIA-SOA relationship from the service-oriented perspective. As we know, OASIS has started a stream of standards that recognizes a SOA service as a business-oriented consumer-centric serving entity that has its own behavior, which provides certain business functionality and enables consumers to reach a concrete RWE. A SOA business service has programmatic interfaces such as Web services, CORBA, and DCOM. At the same time, some business services can have related user interfaces that include Web-based interfaces. The conciliator mentioned above is a means to attach a UI to the programmatic interfaces of the business service. In this case, the conciliator is owned by the business service. The richness of a Web-based UI for a business service depends on two factors: the complexity of the business functionality offered by the service and the specifics of the end-user audience. Combining business services in the form of an aggregate service or a business process leads to the composition of related user interfaces. Alternatively, an aggregate service or a business process can be represented as a new service with its own UI that may or may not include the UI from the engaged business services. Creation of a service's UI composition appears to be a very special task that sometimes gets disconnected from the composition reasons and becomes error-prone. If we want RIA to collaborate with SOA, we have to agree that a rich interface assumes the use of multiple SOA business services as the RIA "application" part. However, SOA business services, in turn, dictate their service-oriented vision of the world - even a rich interface is just the interface to the service. At the same time, the richer the user interface in its capabilities, the easier you can integrate multiple UI from different business services together. In other words, business-driven service compositions can benefit from the user-centric UI integration capabilities of RIA. Figure 3 illustrates this conclusion. What I said in this section is not really new. RIA is a client/server model but attention has been concentrated on the client side so far. An RIA application may be perfectly service-oriented but we shouldn't forget that the application defines its clients. Otherwise, we'd have to agree that people take flights because pilots exist not because airplanes exist. *Summary* This article discussed a discrepancy between RIA and SOA business services that looks like a mismatch in objective requirements, granularity, and data formats. An RIA-SOA collaboration design pattern was proposed to resolve the problem. The pattern's conciliator module was defined and illustrated in two examples of possible implementations. Finally, the article described SOA business services with bundled user interfaces and their aggregation in the RIA.>>