gmane.comp.web.services.soa.yahoo-1 http://blog.gmane.org/gmane.comp.web.services.soa.yahoo-1 hourly 1 1901-01-01T00:00+00:00 Gmane http://gmane.org/img/gmane-25t.png http://gmane.org (Reminder) Standards for Smart Applications workshop< at >ECAI 2012: deadline approaching http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12402 <pre>(Apologies for cross-posting) This short note to remind you that the paper submission deadline for the ECAI workshop on "Standards for Smart Applications" (S4SA) is May 28: that is, next Monday [1]. [1] http://sites.google.com/site/s4sa2012/ If you intend to submit a paper, but you are not sure if you can make the deadline, please contact me directly (see contact info on the workshop Web site). Also, the submission deadline is right after the notification of acceptance for RuleML (May 27), and one week after the notification of acceptance for ECAI (today 21 May): if your paper was rejected and you think that it is relevant to S4SA but you do not have the time to adapt it to the specific focus of the workshop, just add an explanation in front why it is relevant and how you will refocus it if accepted, and submit it. In most cases, we expect that it will be enough to help the PC decide about its value for S4SA. For the S4SA programme committee, Christian de Sainte Marie IBM 9 rue de Verdun 94253 - Gentilly cedex - FRANCE Tel./Fax: +33 1 49 08 29 81 Sauf indication contraire ci-dessus:/ Unless stated otherwise above: Compagnie IBM France Siège Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 639.291.962.10 ? SIREN/SIRET : 552 118 465 03644 - Code NAF 6202A </pre> Christian De Sainte Marie 2012-05-25T16:50:37 Call for Research Papers ISWC 2012 http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12401 <pre>------------------------------------------------------------------------ Call for Research Papers http://iswc2012.semanticweb.org/call-research-papers 11th International Semantic Web Conference http://iswc2012.semanticweb.org/ Boston - USA November 11-15, 2012 ------------------------------------------------------------------------ ISWC is the premier venue for presenting innovative systems and research results related to the Semantic Web and Linked Data. We solicit the submission of original research papers for ISWC 2012's research track, dealing with analytical, theoretical, empirical, and practical aspects of all areas of the Semantic Web. Submissions to the research track should describe original, significant research on the Semantic Web or on Semantic Web technologies, and are expected to provide some principled means of evaluation. To maintain the high level of quality and impact of the ISWC series, all papers will be reviewed by three program committee members and one vice chair of the program committee. To assess papers, reviewers will judge their originality and significance for further advances in the Semantic Web, as well as the technical soundness of the proposed approaches and the overall readability of the submitted papers. We will give specific attention to the evaluation of the approaches described in the papers. We strongly encourage evaluations that are repeatable: preference will be given to papers that provide links to the data sets and queries used to evaluate their approach, as well as systems papers providing links to their source code or to some live deployment. Topics Of Interest ---------------------------- Topics of interest include, but are not limited to: * Management of Semantic Web data and Linked Data * Languages, tools, and methodologies for representing and managing Semantic Web data * Database, IR, NLP and AI technologies for the Semantic Web * Search, query, integration, and analysis on the Semantic Web * Robust and scalable knowledge management and reasoning on the Web * Cleaning, assurance, and provenance of Semantic Web data, services, and processes * Semantic Web Services * Semantic Sensor Web * Evaluation of semantic web technologies * Ontology engineering and ontology patterns for the Semantic Web * Ontology modularity, mapping, merging, and alignment * Ontology Dynamics * Social and Emergent Semantics * Social networks and processes on the Semantic Web * Representing and reasoning about trust, privacy, and security * User Interfaces to the Semantic Web * Interacting with Semantic Web data and Linked Data * Information visualization of Semantic Web data and Linked Data * Personalized access to Semantic Web data and applications * Semantic Web technologies for eGovernment, eEnvironment, eMobility or eHealth * Semantic Web and Linked Data for Cloud environments Submission --------------------- Pre-submission of abstracts is a strict requirement. All papers and abstracts have to be submitted electronically via the Conference Submission System https://www.easychair.org/conferences/?conf=iswc2012. All research submissions must be in English, and no longer than 16 pages. Papers that exceed this limit will be rejected without review. Submissions must be in PDF formatted in the style of the Springer Publications format for Lecture Notes in Computer Science (LNCS). For details on the LNCS style, see Springer’s Author Instructions. ISWC-2012 submissions are not anonymous. Authors of accepted papers will be required to provide semantic annotations for the abstract of their submission, which will be made available on the conference web site. Details will be provided at the time of acceptance. Accepted papers will be distributed to conference attendees and also published by Springer in the printed conference proceedings, as part of the Lecture Notes in Computer Science series. At least one author of each accepted paper must register for the conference and present the paper there. Prior Publication And Multiple Submissions -------------------------------------------------------------------- ISWC 2012 will not accept research papers that, at the time of submission, are under review for or have already been published in or accepted for publication in a journal or another conference. The conference organizers may share information on submissions with other venues to ensure that this rule is not violated. Submission of a Poster or Demo together with your Accepted Research Paper ---------------------------------------------------------------------------------------------------------------------- Authors of accepted papers are invited to submit also a poster or a demo to the Posters and Demo track. The submission format is the same as for normal poster and demo submissions but the submission must cite the corresponding paper from the research track. Important Dates ---------------------------- Abstracts: June 1, 2012, 11:59pm Hawaii time Full Paper Submission: June 8, 2012, 11:59pm Hawaii time Author Rebuttals: July 9-11, 2012 Notifications: July 26, 2012 Camera-Ready Versions: September 4, 2012 Conference: November 11-15, 2012 No extensions of the submission deadline will be granted. Research Track Chairs -------------------------------------- Philippe Cudre-Mauroux, University of Fribourg, Switzerland Jeff Heflin, Lehigh University, USA Follow ISWC 2012 on Twitter https://twitter.com/#!/iswcboston ------------------------------------ Yahoo! Groups Links &lt;*&gt; To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ &lt;*&gt; Your email settings: Individual Email | Traditional &lt;*&gt; To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) &lt;*&gt; To change settings via email: service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ </pre> Oshani Seneviratne 2012-05-21T11:12:02 The Economics of Reuse: DDD vs SOA http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12397 <pre>While many remain unconvinced by the benefits of reusing software artifacts it's worth to start with requirements and reexamine the economics of the different options. http://caminao.wordpress.com/engineering/system-engineering-processes/reuse/ ------------------------------------ Yahoo! Groups Links &lt;*&gt; To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ &lt;*&gt; Your email settings: Individual Email | Traditional &lt;*&gt; To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) &lt;*&gt; To change settings via email: service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ </pre> remyfannader 2012-05-20T04:44:51 Jacobson on REST http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12396 <pre> &lt;&lt;Why REST Keeps Me Up At Night &lt;http://blog.programmableweb.com/2012/05/15/why-rest-keeps-me-up-at-night/&gt; *Guest Author &lt;http://www.programmableweb.com/profile/guest_blogger&gt;*, May 15th, 2012 Comments &lt;http://blog.programmableweb.com/2012/05/15/why-rest-keeps-me-up-at-night/#comments&gt;(0) /This guest post comes from Daniel Jacobson (&lt; at &gt;daniel_jacobson &lt;http://www.twitter.com/daniel_jacobson&gt;), director of engineering for the Netflix &lt;http://www.netflix.com/&gt; API &lt;http://developer.netflix.com/&gt;. Prior to Netflix, Daniel ran application development for NPR &lt;http://www.npr.org&gt; where he created the NPR API &lt;http://www.npr.org/api&gt;, among other things. He is also the co-author of APIs: A Strategy Guide &lt;http://shop.oreilly.com/product/0636920021223.do&gt; and a frequent contributor to ProgrammableWeb &lt;http://www.programmableweb.com&gt; and the Netflix Tech Blog &lt;http://techblog.netflix.com&gt;./ Netflix &lt;http://www.programmableweb.com/api/netflix&gt;With respect to Web APIs, the industry has clearly and emphatically landed on REST as the standard way to implement these services. And for good reason... REST, which is generally implemented as a one-size-fits-all solution, is an excellent choice for a most companies who wish to expose their content to third parties, mobile app developers, partners, internal teams, etc. There are many tomes about what REST is and how best to implement it, so I won't go into detail here. But if I were to sum up the value proposition to these companies of the traditional REST solution, I would describe it as: REST APIs are excellent at handling requests in a generic way, establishing a set of rules that allow a large number of known and unknown developers to easily consume the services that the API offers. In this model, everyone knows how to behave and it can be incredibly powerful. The API providers establish a set of rules and the API consumers must adhere to those rules to get what they want from the API. It is perfect, right? In many cases, the answer is obviously yes. But in other cases, as our world scales and the number of ways for people to consume digital content and services continues to expand, this one-size-fits-all model is likely to fall short. The potential shortcomings surface because this model assumes that a key goal of these APIs is to serve a large number of known and unknown developers. The more I talk to people about APIs, however, the clearer it is that public APIs are waning in popularity and business opportunity and that the internal use case is the wave of the future. There are books &lt;http://shop.oreilly.com/product/0636920021223.do&gt;, articles &lt;http://econsultancy.com/us/blog/9456-api-strategies-for-disruptive-digital-sellers&gt; and case studies &lt;http://blog.programmableweb.com/2011/04/18/what-we-did-wrong-npr-improves-its-api-architecture/&gt; cropping up almost daily supporting this view. And while my company, Netflix, may be an outlier because of the scale in which we operate, I believe that we are an interesting model of how things are evolving. Netflix is currently available on over 800 different device types, including game consoles, mobile phones, TVs, Blu-ray players, tablets, computers, and almost any other device that can stream video. Our API alone handles more than two billion incoming requests on peak days, which translates into almost ten billion real-time outgoing requests from the API to internal dependency services. These numbers are up by about 70x from just two years ago. Most companies do not have that kind of scale, but it is clear that with the continued growth of the device market more companies are resetting their strategies to be less about the public API and more about internal consumption of their own APIs to support device proliferation. When this transition occurs, the API is no longer targeting "a large number of known and unknown developers." Rather, the key audience is a small number of known developers. The potential conflict between the internal and public use cases is in the design of the API itself. Keep in mind that the design implications will not be problematic in many scenarios. It becomes a potential problem if the breadth of devices becomes so wide that the variability of features across them becomes substantially harder to manage. It is the breadth of devices that creates a problem for the one-size-fits-all API solutions. If your target is a small group of teams with whom you have close relationships, the dynamics around the API change. For Netflix, we persisted on the one-size-fits-all REST model for quite a while as more and more devices got added on top of the API. But given our scale, one thing has become increasingly obvious. *Our REST API, while very capable of handling the requests from our devices in a generic way, is optimized for none of them.* This is the case because our REST API focuses on resources that are meant to be granular representations of the data, from the perspective of the data. The granularity is exactly what allows the API to support a large number of known and unknown developers. Because it sets the rules for how to interface with the data, it also forces all of the developers to adhere to those rules. That means that each device potentially has to work a little harder (or sometimes a lot harder) to get the data needed to create great user experiences because devices are different from each other. The differences across these devices can be varied and sometimes significant. Here are some examples of variances across devices that may be challenging for one-size-fits-all models: * Different devices may have different memory capacity * Some devices may require a unique or proprietary format or delivery method * Some devices may perform better with a flatter or more hierarchical document model * Different devices have different screen real estate sizes which may impact which data elements are needed * Some devices may perform better having bits streamed across HTTP rather than delivered as a complete document * Different devices allow for different user interaction models, which could influence the metadata fields, delivery method, interaction model, etc. Just think about the differences between an iPhone and your TV and how they beg for different user experiences. Moreover, the XBox and the Wii, both of which project to the TV, are different in the way users interact with them as well as in the hardware constraints, both of which may require different APIs to support them. When considering more than 800 different device types, the variance across them becomes overwhelming. And as more manufacturers continue to innovate on these devices, the variance may only broaden. How do you know if your company is ready to consider alternatives to the one-size-fits-all API model? Here are the ingredients needed to help you make that decision: * Small number of targeted API consumers is the top priority * Very close relationships between these API consumers and the API team * An increasing divergence of needs across the top priority API consumers * Strong desire by the API consumers for more optimized interactions with the API * High value proposition for the company providing the API to make these API consumers as effective as possible If these ingredients are met, then you have the recipe for needing a new kind of API. Because of the differences in these devices, Netflix UI teams would often have to do a range of things to get around our REST API to better serve the users of the device. Sometimes, the API team would be required to extend the base service to handle special cases, often resulting in spaghetti code or undocumented features. And because different teams have different needs, in the REST API world, we would often need to delay feature development for some due to the challenges around prioritization. In addition to these kinds of issues, significant performance and/or architectural problems are bound to emerge. For example, these more granular APIs often result in chattier interactions between device and server or chunkier payloads, as I discussed in a previous post on the Netflix Tech Blog &lt;http://techblog.netflix.com/2011/02/redesigning-netflix-api.html&gt;. To solve this issue, it is becoming increasingly common for companies (including Netflix) to think about the interaction model in a different way. Rather than having the API create a set of rather rigid rules and forcing the various devices to follow them, companies are now thinking about ways to let the UI have more control in dictating what is needed from a service in support of their needs. Some are creating custom REST-based APIs to support a specific device or category of devices. Others are thinking about greater granularity in REST resources with more batching of calls &lt;http://developers.facebook.com/docs/reference/api/batch/&gt;. Some are creating orchestration layers, such as ql.io, in their API system to customize the interaction. These are all smart and practical ways around the problem. But with the growing number of devices, the increasing urge for companies to be on as many of them as possible, and the desire for continued innovation across these devices, these various solutions are still somewhat restricted. They are still forcing the developers to adhere to server-side rules and non-optimized payloads in an effort to have a one-size-fits-all solution. These approaches are closer to the flexibility needed in that they are not as rigid as the typical REST-based solution, but when supporting as many devices as Netflix does, we believe they fall short for us. For Netflix, *our goal is to take advantage of the differences of these devices rather than treating them generically*. As a result, we are handing over the creation of the rules to the developers who consume the API rather than forcing them to adhere to a generic set of rules applied by the API team. In other words, we have created a *platform for API development*. In my next post, I will discuss in more detail our implementation of this approach. In the meantime, if you are interested in helping us solve these and other problems, we are hiring &lt;http://jobs.netflix.com/jobsListing.html?function=Engineering&gt;!&gt;&gt; *You can find this at: http://blog.programmableweb.com/2012/05/15/why-rest-keeps-me-up-at-night/ * *Thanks to Anne for pointing this out. * *Gervas* </pre> Gervas Douglas 2012-05-16T12:36:16 [ZapFlash] You Say You Want a Revolution... http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12395 <pre> You Say You Want a Revolution... Document ID: | Document Type: ZapFlash By: /Jason Bloomberg/ | Posted: /May 14, 2012/ Remember the heady dot.com days circa 1999? We thought we were reinventing business, forming a New Economy, revolutionizing the essential nature of commerce. In our dreams! By late 2001 the bubble had burst, and what we thought was a new /paradigm/ for business---the World Wide Web---turned out to be little more than a new /marketing channel/. Don't get me wrong---I'm not trying to disparage the power and importance of the Web. After all, the Web, and the Internet in general, have deeply affected so many aspects of business today. It's hard to remember the time when you had to talk to a teller to use a bank or a stockbroker to trade stocks! But we were wrong that the Web was a revolution. It wasn't a paradigm shift. Fundamentally, the rise of the Internet was more /evolutionary/ than /revolutionary/. Not wanting to succumb to this delusion again, ZapThink has long held that the rise of SOA was also more evolutionary than revolutionary. We point to many SOA best practices, including abstracted interfaces, encapsulation, loose coupling, and iterative approaches to dealing with changing requirements, among others---all practices that were already well-known and favored before SOA came along. SOA moved the ball forward, to be sure, but didn't fundamentally change the way we tackled distributed computing. It wasn't a true paradigm shift, because we didn't have to throw out old ways of thinking and replace them with new ways. Instead, we leveraged the existing approaches while tweaking and improving them. Today, however, ZapThink is willing to go out on a limb and proclaim that we now have a true revolution on our hands. A true paradigm shift in the world of IT is afoot, one that is already forcing us to discard old ways of doing things, in favor of new approaches, new technologies, and new ways of thinking. Yes, we're talking about ZapThink's vision for Enterprise IT in 2020 &lt;http://t.ymlp278.net/uyhewanamywsanaesatambmuu/click.php&gt; with its five Supertrends &lt;http://t.ymlp278.net/uyheqaramywsaraesapambmuu/click.php&gt; and multiple Crisis Points &lt;http://t.ymlp278.net/uyheyazamywsapaesalambmuu/click.php&gt;. We've already laid out the context for the turbulence that is already underway and yet to come. But we haven't explained why we're calling this period in time a revolution. Why does this decade herald a true revolutionary change, when even the dot.com period (aka "Web 1.0") of 1994-2001 didn't qualify? *The Context for Revolutionary Change* The most familiar revolutions, of course, are political---the American Revolution, the French Revolution, etc. The author most responsible for extending this definition beyond the political sphere was Thomas Kuhn, whose 1962 book /The Structure of Scientific Revolutions/ &lt;http://t.ymlp278.net/uyhmsacamywsagaesakambmuu/click.php&gt; discussed the nature of revolutions such as the Copernican Revolution or the one leading to the Atomic Theory of Matter. Such revolutions in the process and theory of science represented periods of dramatic change, requiring intellectuals of the day to discard old ways of thinking and replace them with new ones---often over the course of a generation, as the old guard eventually died off. Kuhn also coined the term /paradigm shift/ to refer to such upheaval in ways of thinking. (Yes, if you ever wondered where the notion of paradigm shifts came from, it was Thomas Kuhn who came up with the whole idea). Kuhn's book was so influential that his notions of revolutions and paradigm shifts expanded well past the realm of the history of science into virtually any area of human endeavor. His insights, after all, applied to fundamental aspects of human thought and behavior: human endeavors don't progress evenly and gradually, but rather in fits and starts, and occasionally there's a large upheaval that resets the playing field. But not every change represents a paradigm shift, and not every trend is revolutionary. *Revolution vs. Evolution* How then do we know we're truly in a revolution, and not simply another period of evolution like the dot.com or SOA eras? Kuhn points out that, well, it's harder than it sounds. People often don't recognize that a revolution has taken place until well after the fact. It's not like one day somebody wakes up and realizes that the way they were doing things is suddenly obsolete. In fact, the pre-revolutionary patterns often persist well into the revolutionary period, even though in retrospect it becomes clear their days were numbered. Another reason why revolutions are hard to identify while in the midst of them is that the changes are numerous, often sporadic, and typically subtle. When Galileo turned his telescope toward the moons of Jupiter, it's not clear that he realized he was helping to change an entire civilization's world view. When the Catholic Church forced him to recant his discoveries, I'm sure the church authorities had no idea they were fighting a losing battle. Only in retrospect can we place these events into the proper context of the Copernican Revolution. A third impediment to identifying a revolution in progress is the clichéd nature of the terms /revolutionary/ and /paradigm shift/. It seems that every technology startup these days touts their new widgets as being revolutionary paradigm shifts. Hell, it seems that every minor improvement in laundry detergent or automobile oil is revolutionary. It's no wonder we've become jaded about the entire subject. If the marketeers tout every minor improvement as revolutionary then nothing is revolutionary. That is, until a /real/ revolution comes along. *Why ZapThink 2020 Signals a Revolution* If we only spotted one trend (like SOA) or one disruptive change (e.g., the Web replacing tellers and stockbrokers), then we might have a hint of a revolution, but more likely than not, we'd be wrong to apply the term. However, there are simply too many different forces of change impacting IT today, and in turn, impacting business in general to consider such changes to be an evolutionary trend. We have Cloud Computing, mobile computing, the threat of Cyberwarfare, the rise of social media, the app store model for purchasing software, outsourcing, insourcing, complex systems engineering...the list goes on and on. Any of these trends taken separately may be considered evolutionary, but put them together and there are strong hints of a paradigm shift in progress. The second aspect of ZapThink 2020 that indicates a revolution in progress is the potentially disruptive nature of the Crisis Points. While the Stuxnet &lt;http://t.ymlp278.net/uyhmuaaamywsaxaesaoambmuu/click.php&gt; worm may have only disrupted Iranian power plants, the next professionally designed cyberattack &lt;http://t.ymlp278.net/uyhmeafamywsaxaesagambmuu/click.php&gt; promises much greater disruption. And while buying enterprise-class apps via your phone is novel, it has yet to put one of the big enterprise app vendors out of business. So, we won't really know just how disruptive this paradigm shift will be until after the fact. Perhaps the greatest indicator of an ongoing revolution is the evolving perspective on /change, /and the role technology has in supporting it. People are simply getting fed up with inflexible technology. We're sick and tired of legacy that slows down our organizations and sucks up our budgets. The need for greater agility drove the move to SOA, but SOA alone doesn't solve our inflexibility problems, in large part because SOA is part of the old paradigm. What we need is a new paradigm for architecture-driven agility &lt;http://t.ymlp278.net/uyhmmapamywsaxaesaoambmuu/click.php&gt; that is inherently different than today's architectural approaches. It's the fact that we're already seeing the shift to this new paradigm that is the primary reason we're calling this point in time a revolution. *The ZapThink Take* The most challenging aspect of identifying a revolution is that it's extraordinarily difficult to do so while it's still in progress. We understand this challenge, and realize that we may be wrong about the whole affair. After all, there are still so many unanswered questions. For example, in 20 years when we look back on this time, what will we call the revolution? We can guess, but there's no way to know what the next big thing &lt;http://t.ymlp278.net/uyhmjaxamywsakaesavambmuu/click.php&gt; will be until it's finally here. Perhaps we can look back at the last revolution for inspiration---the postwar Information Revolution that heralded the Information Age. Starting with Colossus &lt;http://t.ymlp278.net/uyhmbacamywsaiaesadambmuu/click.php&gt; cracking the Nazi's Enigma codes at Bletchley Park, through the rise of digital, programmable computers to the networked world we have today, no one can disagree that the rise of computing disrupted the pre-computer ways of thinking and conducting business, leading to an entirely new context for human endeavor writ large. But no single innovation, no single disruption signaled the revolution. Only in retrospect can we take all the disruptions together and recognize a true paradigm shift. We're the first to admit, therefore, that we may be completely wrong about what we call the Agile Architecture Revolution &lt;http://t.ymlp278.net/uyhmhaaamywsapaesadambmuu/click.php&gt;. And we may not know how right we were for another twenty years. But we can say that rethinking how we approach agility will be a critical enabler for organizations over the next ten years and beyond. Whether agile architecture heralds a revolution may be too hard to say with any certainty, but agile architecture is undoubtedly here to stay. </pre> Gervas Douglas 2012-05-14T22:58:57 Bradshaw on EAI Adapters http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12394 <pre> &lt;&lt;Why Traditional EAI Adapters Fail By Jeff Bradshaw &lt;http://www.businesscomputingworld.co.uk/author/jeff-bradshaw/&gt; March 26, 2012Share3 EAI *Many years spent building integration solutions have taught me a great deal about what makes certain approaches successful. During this time, I've observed many projects where traditional EAI &lt;http://en.wikipedia.org/wiki/Enterprise_application_integration&gt; (Enterprise Application Integration) adapters were used to connect IT assets to the integration infrastructure.* The recurring feature in all of these projects is the staggering amount of legacy code that needs to be written to make, what should be a completely configurable adapter, actually work. This isn't necessarily a criticism of those specific vendors' adapters; instead it's a comment on the futility of attempting to build configurable pre-packaged adapters for every possible use case. It just isn't practical. The configuration threshold Common sense suggests that vendors should only produce a pre-built plugin when it could be reasonably deployed through configuration alone. If plugins require bespoke code on top of the configuration to achieve a certain design goal, then it implies that the configuration threshold has been crossed and that the better course of action would be to produce a more specific plugin to do the job. Adopting this approach has impacted our strategy in two main ways; the rationalisation of plugins and the encouragement of end users to create their own mediation plugins. Rationalise not compromise Only producing a pre-built plugin when it can simply be deployed through basic configuration, undoubtedly leads to a rationalisation of plugins produced. However, looking at the range of adapters that other vendors offer, tells me that their customers must be cutting a lot of code or making a lot of compromises. Contained code Secondly, and more importantly, this approach leads to organisations opening up their architecture and exposing design frameworks to allow end users to produce their own mediation plugins. For example, hooks and mechanisms are available to deploy custom code within the mediation plugins container. This "contained" code limits the need to write legacy code outside of the plugin. In my experience, such "uncontained" code is typically 8 to 12 times more costly to develop and maintain because it is usually developed within a non-productive, code-intensive, skill-shortage legacy environment. By following this rule, organisations can realise significant productivity improvements. Whilst some coding is required within the plugin, the result will be a perfect fit, built upon and reusing existing services, and in keeping with the design approach of the embedded mediation framework. A pragmatist stance I'd certainly not advocate writing bespoke code for every mediation plugin deployment -- far from it. In fact, the majority of our 1250+ customer deployments have been made using our configuration tools alone. The key here has to be pragmatism. Where there is a functionality delta between the mediation plugins and the IT asset being integrated, allow the code that will reduce the delta to be accommodated within the mediation plugin. Such pragmatism makes it possible to package new "adapters" within days rather than months or years, offering customers a greater level of flexibility in how they bring packaged applications into a Service Oriented Architecture. What about hosting the integration logic? One thing that often gets overlooked is the runtime aspect of the adapters. Generally adapters are hosted locally, close to the target application. Hosting locally is one option, however an increasing number of customers want to host integration logic elsewhere, or use adapters to integrate on premise applications with cloud applications. Such flexibility is undoubtedly key and ties in to my belief in integration anywhere -- and something that more and more customers are looking to harness.&gt;&gt; *You can find this at: http://www.businesscomputingworld.co.uk/why-traditional-eai-adapters-fail/?goback=.gde_87715_member_103753297 * *Gervas* </pre> Gervas Douglas 2012-05-13T22:39:33 Final CfP+deadline extension: WoMO 2012 - 6th Int'l Workshop on Modular Ontologies http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12393 <pre>======================================================== 6th Int'l Workshop on Modular Ontologies (WoMO) Graz, Austria, July 24, 2012 held in conjunction with FOIS 2012 --- Final Call for Papers --- ======================================================== +++ EXTENDED SUBMISSION DEADLINE: May 18, 2012 +++ ======================================================== +++ Following requests, we have extended the submission deadline to MAY 18, 2012. +++ INVITED SPEAKERS: * Thomas Eiter, Vienna University of Technology, Austria Title TBA * Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy Multi context logics: a formal support for structuring knowledge and beliefs (Tentative title) http://www.informatik.uni-bremen.de/~ts/womo2012 MODULARITY, studied for years in software engineering, allows mechanisms for easy and flexible reuse, generalization, structuring, maintenance, design patterns, and comprehension. In formal and applied ontology, modularity is central to reducing the complexity of designing and understanding ontologies, and to facilitating ontology verification, reasoning, development, maintenance and integration. Recent research on ontology modularity shows substantial progress in foundations of modularity, techniques of modularization and modular development, distributed reasoning and empirical evaluation. These results provide a solid foundation and exciting prospects for further research and development. The workshop continues a series of successful events that have been an excellent venue for practitioners and researchers to discuss latest and current work; the most recent WoMOs were held at FOIS 2010 and ESSLLI 2011. TOPICS include, but are not limited to: - What is modularity?: kinds of modules and their properties; modules vs. contexts; design patterns; granularity of representation; - Logical/foundational studies: conservativity; modular ontology languages; reconciling inconsistencies across modules; formal structuring of modules; heterogeneity; - Algorithmic approaches: distributed and incremental reasoning; modularization and module extraction; sharing, linking, reuse; privacy; evaluation of modularization approaches; complexity of reasoning; implemented systems; - Applications: semantic web; life sciences; bio-ontologies; natural language processing; space and time; ambient intelligence; social intelligence; collaborative ontology development and ontology versioning. IMPORTANT DATES Paper Submission: May 18, 2012 Notification: June 19, 2012 Camera ready: July 6, 2012 Workshop: July 24, 2012 SUBMISSION GUIDELINES: We welcome submissions on modularity in a broad sense. The workshop is open to papers of theoretical or practical nature. Submissions should be of up to 11 pages in length, formatted according to Springer LNCS style (see http://www.springer.com/comp/lncs/Authors.html), prepared in PDF format and submitted no later than May 18, 2012, through the EasyChair Submission System (see http://www.easychair.org/conferences/?conf=womo2012). Submitted papers will be peer-reviewed by members of the program committee. Accepted papers will be made available in the proceedings to be published electronically in the CEUR Workshop Proceedings series (see http://www.ceur-ws.org). (Find the WoMO 2010 and 2011 proceedings here http://www.booksonline.iospress.nl/Content/View.aspx?piid=16268 and http://www.booksonline.iospress.nl/Content/View.aspx?piid=20369) WORKSHOP CHAIRS: Thomas Schneider, University of Bremen, Germany Dirk Walther, Technical University of Madrid (UPM), Spain PROGRAM COMMITTEE: Kenneth Baclawski, Northeastern University, Boston, MA, USA Stefano Borgo, Italian National Research Council, Trento, Italy Oscar Corcho, Universidad Politecnica de Madrid, Spain Bernardo Cuenca Grau, University of Oxford, UK Mike Dean, Raytheon BBN Technologies, Ann Arbor, MI, USA Silvio Ghilardi, Universita degli Studi di Milano, Italy Michael Gruninger, University of Toronto, Canada Janna Hastings, EMBL-EBI, Cambridge, UK Robert Hoehndorf, University of Cambridge, UK Boris Konev, University of Liverpool, UK Roman Kontchakov, Birkbeck College, London, UK Thomas Meyer, Meraka Institute, CSIR, Pretoria, South Africa Till Mossakowski, University of Bremen, Germany Immanuel Normann, Birkbeck College, London, UK Leo Obrst, MITRE, McLean, VA, USA Adrian Paschke, Free University of Berlin, Germany David Perez del Rey, Universidad Politecnica de Madrid, Spain Uli Sattler, University of Manchester, UK Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy ------------------------------------ Yahoo! Groups Links &lt;*&gt; To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ &lt;*&gt; Your email settings: Individual Email | Traditional &lt;*&gt; To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) &lt;*&gt; To change settings via email: service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ </pre> WoMO 2012 2012-05-10T21:47:03 3rd CfP: WoMO 2012 - 6th Int'l Workshop on Modular Ontologies http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12392 <pre>======================================================== 6th Int'l Workshop on Modular Ontologies (WoMO) Graz, Austria, July 24, 2012 held in conjunction with FOIS 2012 --- Third Call for Papers --- ======================================================== Submission deadline: May 11, 2012 ======================================================== INVITED SPEAKERS: * Thomas Eiter, Vienna University of Technology, Austria Title TBA * Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy Multi context logics: a formal support for structuring knowledge and beliefs (Tentative title) http://www.informatik.uni-bremen.de/~ts/womo2012 MODULARITY, studied for years in software engineering, allows mechanisms for easy and flexible reuse, generalization, structuring, maintenance, design patterns, and comprehension. In formal and applied ontology, modularity is central to reducing the complexity of designing and understanding ontologies, and to facilitating ontology verification, reasoning, development, maintenance and integration. Recent research on ontology modularity shows substantial progress in foundations of modularity, techniques of modularization and modular development, distributed reasoning and empirical evaluation. These results provide a solid foundation and exciting prospects for further research and development. The workshop continues a series of successful events that have been an excellent venue for practitioners and researchers to discuss latest and current work; the most recent WoMOs were held at FOIS 2010 and ESSLLI 2011. TOPICS include, but are not limited to: - What is modularity?: kinds of modules and their properties; modules vs. contexts; design patterns; granularity of representation; - Logical/foundational studies: conservativity; modular ontology languages; reconciling inconsistencies across modules; formal structuring of modules; heterogeneity; - Algorithmic approaches: distributed and incremental reasoning; modularization and module extraction; sharing, linking, reuse; privacy; evaluation of modularization approaches; complexity of reasoning; implemented systems; - Applications: semantic web; life sciences; bio-ontologies; natural language processing; space and time; ambient intelligence; social intelligence; collaborative ontology development and ontology versioning. IMPORTANT DATES Paper Submission: May 11, 2012 Notification: June 12, 2012 Camera ready: July 1, 2012 Workshop: July 24, 2012 SUBMISSION GUIDELINES: We welcome submissions on modularity in a broad sense. The workshop is open to papers of theoretical or practical nature. Submissions should be of up to 11 pages in length, formatted according to Springer LNCS style (see http://www.springer.com/comp/lncs/Authors.html), prepared in PDF format and submitted no later than May 11, 2012, through the EasyChair Submission System (see http://www.easychair.org/conferences/?conf=womo2012). Submitted papers will be peer-reviewed by members of the program committee. Accepted papers will be made available in the proceedings to be published electronically in the CEUR Workshop Proceedings series (see http://www.ceur-ws.org). (Find the WoMO 2010 and 2011 proceedings here http://www.booksonline.iospress.nl/Content/View.aspx?piid=16268 and http://www.booksonline.iospress.nl/Content/View.aspx?piid=20369) WORKSHOP CHAIRS: Thomas Schneider, University of Bremen, Germany Dirk Walther, Technical University of Madrid (UPM), Spain PROGRAM COMMITTEE: Kenneth Baclawski, Northeastern University, Boston, MA, USA Stefano Borgo, Italian National Research Council, Trento, Italy Oscar Corcho, Universidad Politecnica de Madrid, Spain Bernardo Cuenca Grau, University of Oxford, UK Mike Dean, Raytheon BBN Technologies, Ann Arbor, MI, USA Silvio Ghilardi, Universita degli Studi di Milano, Italy Michael Gruninger, University of Toronto, Canada Janna Hastings, EMBL-EBI, Cambridge, UK Robert Hoehndorf, University of Cambridge, UK Boris Konev, University of Liverpool, UK Roman Kontchakov, Birkbeck College, London, UK Thomas Meyer, Meraka Institute, CSIR, Pretoria, South Africa Till Mossakowski, University of Bremen, Germany Immanuel Normann, Birkbeck College, London, UK Leo Obrst, MITRE, McLean, VA, USA Adrian Paschke, Free University of Berlin, Germany David Perez del Rey, Universidad Politecnica de Madrid, Spain Uli Sattler, University of Manchester, UK Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy ------------------------------------ Yahoo! Groups Links &lt;*&gt; To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ &lt;*&gt; Your email settings: Individual Email | Traditional &lt;*&gt; To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) &lt;*&gt; To change settings via email: service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ </pre> WoMO 2012 2012-05-07T14:58:39 [ZapFlash] Deconstructing Agile http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12390 <pre> Deconstructing Agile Document ID: | Document Type: ZapFlash By: /Jason Bloomberg/ | Posted: /May 4, 2012/ Every specialization has its own jargon, and IT is no different---but many times it seems that techies love to co-opt regular English words and give them new meanings. Not only does this practice lead to confusion in conversations with non-techies, but even the techies often lose sight of the difference between their geek-context definition and the real world definition that "normal" people use. In our Licensed ZapThink Architect &lt;http://t.ymlp349.net/uyjybadamqjhaiaubmarambmuu/click.php&gt; course, for example, we spend far too long defining /Service &lt;http://t.ymlp349.net/uyjyhafamqjhakaubmatambmuu/click.php&gt;/. This word has far too many meanings, even in the world of IT---and most of them have little to do with what the rest of the world means by the term. Even words like /business/ have gone through the techie redefinition process (in techie-speak, /business/ means /everything that's not IT/). It comes as no surprise, therefore, that techies have hijacked the word /Agile/. In common parlance, someone or something is agile if it's flexible and nimble, especially in the face of unexpected forces of change. But in the world of technology, /Agile/ (Agile-with-a-capital-A) refers to a specific category of software development methodology. This definition dates to 2001 and the establishment of the Agile Manifesto &lt;http://t.ymlp349.net/uyjywacamqjharaubmadambmuu/click.php&gt;, a set of general principles for building better software. In the intervening decade, however, /Agile/ has taken on a life of its own, as Scrum, Extreme Programming, and other Agile methodologies have found their way into the fabric of IT. Such methodologies indubitably have strengths, to be sure---but what we have lost in the fray is a sense of what is particularly agile about Agile. This point is more than simple semantics. What's missing is the fundamental connection to agility that drove the Manifesto in the first place. Reestablishing this connection, especially in the light of new thinking on business agility, is essential to rethinking how IT meets the ever-changing requirements of the business. *The Paradox of Business Requirements* How do techies know what to build? Simple: ask the stakeholders (the "business") what they want. Make sure to write down all their requirements in the proverbial requirements document. Now build something that does what that document says. After you're done, get your testers to verify that what you've built is what the business wanted. Or what they used to want. Or what they said they wanted. Or perhaps what they /thought/ they said they wanted. And therein lies the rub. The expectation that the business can completely, accurately, and definitively describe what they want in sufficient detail so that the techies can build it precisely to spec is ludicrously unrealistic, even though such a myth is inexplicably persistent in many enterprise IT shops to this day. In fact, the myth of complete, well-defined requirements is at the heart of what we call the "waterfall" methodology, illustrated in the figure below. &lt;http://t.ymlp349.net/uyjyqaoamqjhavaubmavambmuu/click.php&gt; In reality, it is far more common for requirements to be poorly communicated, poorly understood, or both. Or even if they're properly communicated, they change before the project is complete. Or most aggravating at all, the stakeholder looks at what the techies have built and says, "yes, that's exactly what I asked for, but now that I see it, I realize I want something different after all." Of course, such challenges are nothing new; they gave rise to the family of iterative methodologies a generation ago, including the Spiral methodology, IBM's Rational Unified Process, and all of the Agile methodologies. By taking an iterative approach that involves the business in a more proactive way, the reasoning goes, you lower the risk of poorly communicated, poorly understood, or changing business requirements. The figure below illustrates such a project. &lt;http://t.ymlp349.net/uyjyyaiamqjhataubmaoambmuu/click.php&gt; In the above diagram the looped arrows represent iterations, where each iteration reevaluates and reincorporates the original requirements with any further input the business wants to contribute. But even with the most agile of Agile development teams, the process of building software still falls short. It doesn't seem to matter how expert the coders, how precise the stakeholders, or how perfect the development methodology are, the gap between what the business /really/ needs and what the software /actually/ does is still far wider than it should be. And while many business stakeholders have become inured to poorly fitting software, far more are becoming fed up with the entire situation. Enough is enough. How do we get what we /really/ want and need from IT? *Changing the Way We Deal with Change* Even the most Agile development teams still struggle with the problem of changing requirements. If requirements evolve somewhat during the course of a project, then a well-oiled Agile team can generally go with the flow and adjust their deliverables accordingly, but one way or the other, all successful software projects come to an end. And once the techies have deployed the software, they're done. Have a new requirement? Fund a separate project. We'll start over and include your new requirements in the next version of the project we already finished, unless it makes more sense to build something completely new. Sometimes techies can tweak existing capabilities to meet new requirements quickly and simply, but more often than not, rolling out new versions of existing software is a laborious, time-consuming, and risky process. If the software is commercial off the shelf (COTS), the problem is even worse, since the vendor must base new updates on requirements from many existing customers, as well as their guesses about what new customers will want in the future. The figure below illustrates this problem, where the software project represented by the box can be as Agile as can be, and yet the business still doesn't get the agility it craves. It seems that Agile may not be so agile after all. &lt;http://t.ymlp349.net/uybssaramqjhalaubmazambmuu/click.php&gt; The solution to this problem is for the business to specify its requirements in a fundamentally different way. Instead of thinking about what it wants the software to do, the business should specify how agile it expects the software to be. In other words, don't ask for software that does A, B, C or whatever. Instead, tell your techies to /build you something agile/. We call this requirement the metarequirement of agility &lt;http://t.ymlp349.net/uybsuaramqjhataubmaiambmuu/click.php&gt;---a /metarequirement/ because agility applies to other requirements: "build me something that responds to changing requirements" instead of "build me something that does A, B, and C." If we can build software that satisfies this metarequirement, then our diagram looks quite different: &lt;http://t.ymlp349.net/uybseaaamqjhaxaubmadambmuu/click.php&gt; Because the software in the above diagram is truly agile, it is possible to meet new requirements without having to change the software. Whether the process inside the box is Agile is beside the point. Yes, perhaps taking an Agile approach is a good idea, but it doesn't guarantee the resulting software is agile. *The ZapThink Take* Sounds promising, to be sure, but the devil is in the details. After all, if it were easy to build software that responded to changing requirements, then everybody would be doing it. But there's a catch. Even if we built software that could /potentially/ meet changing requirements, that doesn't mean that it actually /would/---because meeting changing requirements is part of how you would /use/ the software, rather than part of how you /build/ it. In other words, the /users/ of the software must actually be part of the agile system. The box in the diagram above doesn't just represent software anymore. It represents a system consisting of software and people. Such software/people systems of systems are a long-standing fixture in ZapThink thinking. In fact, ZapThink frequently talks about agility in the context of SOA. With SOA, IT publishes business Services that represent IT capabilities and information, and the business drives the consumption and composition of those Services. In mature SOA deployments, policies drive the behavior of Services and their compositions. If you want to change the behavior, change the policy. In other words, SOA is governance-driven, and governance applies to the behavior of both people and technology. Agile architectural approaches like SOA, therefore, focus on implementing governance-driven technology/people systems that support changing requirements over time. The challenge, of course, is actually /building/ such systems that meet the business agility metarequirement. Where in this system do we put the agility? It's not in any part of the system. Instead, it's a property of the system as a whole---what we call an /emergent property/. If you've been following ZapThink, you've heard this story before: business agility is an emergent property &lt;http://t.ymlp349.net/uybsmaramqjhaxaubmanambmuu/click.php&gt; of the combination technology/human system we call the enterprise. In other words, we started by deconstructing the notion of Agile and ended up with Enterprise Architecture, because what is Enterprise Architecture but best practices for designing and building the enterprise to better meet changing requirements over time? This is not the static, framework-centric EA &lt;http://t.ymlp349.net/uybsjadamqjhagaubmazambmuu/click.php&gt; from years past that presuppose a final, ideal state for the enterprise &lt;http://t.ymlp349.net/uybsbavamqjhafaubmalambmuu/click.php&gt;. We're talking about a new way of thinking about what it means to architect technology-rich organizations to be inherently agile. </pre> Gervas Douglas 2012-05-04T17:20:15 The cases for reuse http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12389 <pre>How to manage reusable assets according architecture layers. http://caminao.wordpress.com/2012/04/09/cases4reuse/ ------------------------------------ Yahoo! Groups Links &lt;*&gt; To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ &lt;*&gt; Your email settings: Individual Email | Traditional &lt;*&gt; To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) &lt;*&gt; To change settings via email: service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ </pre> remyfannader 2012-04-30T11:31:17 ISWC 2012 Call for Tutorial Proposals -- Submission Deadline May 6 http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12388 <pre>------------------------------------------------------------------------ Call for Tutorial Proposals http://iswc2012.semanticweb.org/call-tutorial-proposals In conjunction with the 11th International Semantic Web Conference http://iswc2012.semanticweb.org/ Boston - USA November 11-15, 2012 ------------------------------------------------------------------------ The International Semantic Web Conference (ISWC) is the primary conference on the use of semantic technologies on the web and linked data, constantly attracting a high number of high quality submissions participants from academia and industry. It brings together researchers from different areas of computer science, like artificial intelligence, databases, natural language process, information retrieval and others that aim at the development and use of novel technologies for accessing, interpreting and using information on the web in a more effective way. Besides the main technical program, ISWC will host a number of tutorials on all major topics related to the Semantic Web / Linked Data research, enabling attendees to fully appreciate current issues, main schools of thought, and possible application areas. In order to meet these goals, tutorials should address topics that satisfy the following criteria: - the topic falls in the general scope of ISWC 2012, - there is a clear focus on a specific technology, problem or - application, and - there is a sufficiently large community interested in the topic. In particular, we encourage the submission of tutorial proposals on: - fundamental problems of the Semantic Web/Linked Data such as ontology mining, heterogeneity, scalability and distribution, - applications of Semantic Web technologies in specific domains and trends, - important enabling technologies and their adaptation to the needs of the Semantic Web, - aspects of semantic web research that have been neglected so far, and - techniques from other research fields that are of relevance for Semantic Web research (e.g., machine learning, NLP). Additionally, we expect tutorials to: - have practical parts in terms of examples or preferably exercises to be carried out by the participants Proposers of accepted tutorials have to prepare a tutorial webpage containing detailed information about the tutorial. Submission Guidelines ----------------------------------- Tutorial proposals should be submitted via EasyChair https://www.easychair.org/conferences/?conf=iswc2012tutorials as a single PDF file of no more than 5 pages and should contain the following information: - Title - Abstract (200 words) - Motivation on why the topic is of particular interest at this time - Overview of content, description of the aims, presentation style, potential/preferred prerequisite knowledge - Indication on whether the tutorial should be considered for a half-day or full-day - Intended audience and expected number of participants - Audio-visual or technical requirements and any special room requirements (for hands-on sessions, any software needed and download sites must be provided by the tutorial presenters) - Data of the presenters (name, affiliation, email address, homepage) and short description of their expertise, experiences in teaching and in tutorial presentation Important Dates -------------------------- - Event: November 11 &amp; 12, 2012 - Tutorial proposal due: May 6, 2012 - Tutorial Notifications: May 20, 2012 Chairs -------------- Claudia d’Amato, Unversity of Bari Thomas Scharrenbach, University of Zurich Follow ISWC 2012 on Twitter https://twitter.com/#!/iswcboston ------------------------------------ Yahoo! Groups Links &lt;*&gt; To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ &lt;*&gt; Your email settings: Individual Email | Traditional &lt;*&gt; To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) &lt;*&gt; To change settings via email: service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ </pre> Oshani Seneviratne 2012-04-30T10:46:04 Standards for Smart Applications (2nd Call for Papers) http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12387 <pre>(Apologies for cross-posting, if you receive multiple copies of this message) Standards for Smart Applications (S4SA) is an ECAI 2012 workshop on knowledge representation standards and integrating knowledge sources, with a focus on bridging across heterogeneous standards, as a way to avoid the creation of "knowledge representation silos". Web site: http://sites.google.com/site/s4sa2012/ ============= Call for Papers ============= Submission deadline: 28 May 2012 ---------------------------------------------------- The objective of this workshop is to promote research and education on the combination and integration of knowledge representation standards. Here, knowledge representation standards are meant in a broad sense, not limited to what is traditionally seen as knowledge representation in the Artificial Intelligence and semantic technology communities: this workshop will consider integration and bridges between OWL, RIF, RuleML and other ?traditional? knowledge representation standards, but also with and between BPMN, SBVR, XBRL, fact-based modelling standards such as ORM, XML-based and non-XML industry standards such as MISMO, HL7, X9, ACORD and many more. The workshop will gather researchers and practitioners interested in knowledge representation standards and in the standard-based integration of multiple knowledge representations for the development of smarter applications and for the broader adoption of knowledge-based technology. Papers and contributions are invited on all the theoretical, technical and practical aspects of combining multiple knowledge representation standards, such as, but not limited to: - Semantics for combinations of knowledge representation standards - Technology that combines multiple standard knowledge representations - Mapping and translation between standards - Extending VS combining standards - Requirements on new standards and extensions of existing standards to improve inter-operability of diverse knowledge representation paradigms - Experience with standard-based integration of multiple knowledge representations - New, emerging and proposed knowledge representation standards (and how they fit in the bigger picture) - Use cases and requirements with standard-based integration of multiple knowledge representations - Performance and scalability issues related to standard-based integration of multiple knowledge representations For complete information about the workshop and the call for papers, check the workshop Web site: http://sites.google.com/site/s4sa2012/ For the program committee, Christian de Sainte Marie IBM 9 rue de Verdun 94253 - Gentilly cedex - FRANCE Tel./Fax: +33 1 49 08 29 81 Sauf indication contraire ci-dessus:/ Unless stated otherwise above: Compagnie IBM France Siège Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 639.291.962.10 ? SIREN/SIRET : 552 118 465 03644 - Code NAF 6202A </pre> Christian De Sainte Marie 2012-04-23T17:41:09 Earls on Defining SOA Infrastructure http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12383 <pre> &lt;&lt;Is it possible to define SOA infrastructure? Alan Earls &lt;http://searchsecurity.techtarget.com/contributor/Alan-Earls&gt; * E-mail &lt;http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&amp;asrc=EM_USC_17087237&amp;Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&amp;#&gt; * Print &lt;http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?vgnextfmt=print&gt; * A &lt;http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&amp;asrc=EM_USC_17087237&amp;Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&amp;#&gt; * AA &lt;http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&amp;asrc=EM_USC_17087237&amp;Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&amp;#&gt; * AAA &lt;http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&amp;asrc=EM_USC_17087237&amp;Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&amp;#&gt; * LinkedIn &lt;http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&amp;asrc=EM_USC_17087237&amp;Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&amp;#&gt; * Facebook &lt;http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&amp;asrc=EM_USC_17087237&amp;Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&amp;#&gt; * Twitter &lt;http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&amp;asrc=EM_USC_17087237&amp;Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&amp;#&gt; * Share This &lt;http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&amp;asrc=EM_USC_17087237&amp;Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&amp;#&gt; * RSS &lt;http://searchsoa.techtarget.com/rss/ContentSyndication.xml&gt; * Reprints &lt;http://reprints.ygsgroup.com/m/techtarget&gt; What do people mean when they say SOA infrastructure? Service-oriented architecture may be a way of thinking, but it is also represented in a range of architectural practices such as message queuing middleware and enterprise service bus (ESB). Certain types of software may be used like Legos in a typical SOA project, but there is little consensus on what counts as SOA infrastructure. Indeed, SearchSOA.com recently conducted a 2011 Readership Survey that solicited views on which of the contenders mattered most. The range of responses was striking as was the lack of any clear "winner." For instance, none of the seven different technologies described earned more than a 50% score and the lowest scores were in the mid-20% range. (Survey choices were message queuing middleware; enterprise service bus (ESB); publish &amp; subscribe middleware; SOA and Web services governance; test or management software; services registry/repository; service orchestration tools; and SOA appliances/XML gateways.) In other words, there are a lot of choices and little agreement about what's best. However, of the choices out there, message queuing middleware seems to be leading the pack, followed closely by ESB (see*Figure 1*). &lt;http://cdn.ttgtmedia.com/rms/onlineImages/SSOA-AlanEarlsSurvey-MobileFigure3-SM2.png&gt; *Figure 1*: Message queuing leads technologies for SOA infrastructure; others are close behind. Mark Eisenberg, a former member of Microsoft's Azure team and now director of Fino Consulting says it is no wonder there is confusion -- SOA is simply too big of a concept. "I think that's why it has had limited success in the enterprise," he says. In his view, ESBs and similar kinds of technology are implementation details. "ESB is a way for services to communicate without having to know the specifics of how to contact the services," he says. In that sense, he says, ESBs are simply an infrastructure element. The long list of possible SOA infrastructure elements can make implementation difficult. Eisenberg says that the original "dream" for SOA was that you would build a service, you would register it, and then some other service that needed that functionality would simply "go there and say, I need that and simply connect to that service." However, in fact, that represents a complex undertaking. In Eisenberg's view, there is no simple "right" answer to the question of which technology is most relevant to the concept of SOA infrastructure. "Message queues are a very fundamental computer concept and services buses are also very fundamental to SOA," he says. The long list of possible SOA infrastructure elements can make implementation difficult. A similar take on the question comes from Mike Rosen, an industry expert in business architecture, SOA and enterprise architecture and a practice director for Business and Enterprise Architecture at the Cutter Consortium (an IT Research Firm). He says, in general, when people refer to SOA infrastructure, they mean the product platform that the SOA runs on, such as an ESB. "Occasionally, if taken from a high level business perspective, they mean the entire SOA stack, including the business services, but that would be an unusual interpretation of the term," says Rosen. Still, "interpretation" is what's at issue. "While ESB is probably the most relevant, it of course depends on the context of the usage and requirements," he adds. Further, Rosen points out that ESB and queuing are not architectural 'practices', but rather an implementation of the infrastructure. "Also, virtually all ESB products include queuing as an underlying capability," he adds. So, is there a way to parse the SOA and infrastructure concept a little further? Possibly. According to Nate Minshew, enterprise architect/principal consultant at Asynchrony Solutions, Inc., who relied on Department of Defense definitions related to SOA to provide a degree of clarity on a recent project. "In our project we built a service taxonomy so we could classify the different services to provide a mechanism to quickly identity a service based on what functional purpose it had. The taxonomy was primarily a high level category of process services. Minshew says decisions about infrastructure were based on the same standards taxonomy. "We wanted to identify specific taxonomy and DOD had certain standards mandated from the DOD Standards Repository. A lot of those were fairly incomplete, he says. but there was room to make recommendations based on them such as SOAP 1.2, PKI standards and so on," he explains. In turn, says Minshew, he hoped to get clearer definitions of infrastructure components, like "what is an ESB?" "We found that a lot of vendors market products as ESBs but what they call an ESB also has services and governance and management tools -- we wanted to look for more granular pockets of technology. Our definition of an ESB was the messaging infrastructure and the ability to do composition for web services and the routing and processing that goes on," he says. In short, Minshew notes, infrastructure can take many forms and no one term suffices to describe it.&gt;&gt; *You can find this at: http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&amp;asrc=EM_USC_17087237&amp;Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&amp; &lt;http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&amp;asrc=EM_USC_17087237&amp;Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&amp;&gt; * *Gervas* </pre> Gervas Douglas 2012-04-20T10:55:51 Shah on MDM http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12382 <pre> &lt;&lt;Why Master Data Should Start with the Business Process, Not the Data /byLoraine Lawson &lt;http://www.itbusinessedge.com/cm/people/LoraineLawson&gt;, IT Business Edge 10-abr-2012 17:33:37/ *Jignesh Shah &lt;http://www.linkedin.com/in/jshah0209&gt;*(&lt; at &gt;*jshah0209 &lt;https://twitter.com/#%21/jshah0209&gt;*),*Software AG &lt;http://www.softwareag.com/&gt;*'s vice president of business infrastructure products and solutions, discusses with IT Business Edge's Loraine Lawson the benefits of taking a process-driven approach to master data management, as opposed to a data-driven approach. (In the interest of disclosure, this month Loraine Lawson began writing for*B2B.com &lt;http://www.b2b.com/&gt;*, a business-to-business site owned by Software AG and overseen by Shah's division. However, this interview was scheduled in response to an ITBE blog post Lawson wrote on*marrying BPM with MDM &lt;http://www.itbusinessedge.com/cm/blogs/lawson/integrating-management-adding-master-data-to-business-process-is-slow-going/?cs=50011&gt;*.) Jignesh Shah VP of Business Infrastructure Software AG *Lawson:*I know that in 2010, towards the end of the year, Software AG --- which is known for its BPM tool --- bought Data Foundations, an MDM company. How do you see BPM and MDM coming together? *Shah:*What's interesting is that the process-driven MDM story at Software AG precedes Data Foundations, and not a lot of people know this because it actually stems from the IDS Scheer side of the house. Definitely we put process-driven MDM messages on the forefront for the Data Foundation acquisition, but IDS Scheer, which became a part of Software AG in 2009 and has been around for about 20 years, has been doing process-driven MDM for about 15 years. IDS Scheer started out as a process improvement company and a lot of their practice around process improvement was around SAP implementations. So they took a very process-driven approach to implementing SAP. They would document customers' processes, how they could be changed, modified, automated, and then use all that information to then guide the implementation of SAP systems and modules. Even with SAP, the databases and the data models are not homogenous, so frequently they would implement master data management within SAP modules or between SAP modules and other systems that clients may have. And guess what? Being a process company, they adopted a process model to do MDM as well. Initially, it started out as an extension of just process thinking, but very soon they actually had developed a whole methodology and discipline around how MDM can be implemented and tied to process improvement initiatives. It's a six-point methodology starting from strategy, organization, process, data, applications and governance. The article that you wrote and some of the things that Andrew White of Gartner writes, they often kind of equate process with BPM, which maybe it's true these days, but you know processes have been around as long as we've had the human race, right? So, BPM and processes are not one and the same, is the point I'm trying to make. And IDS Scheer was doing process improvement before BPM became fashionable and they've been doing process-driven MDM before people started talking about marrying BPM and MDM, shotgun or otherwise. So that's the backgrounds. So we've been doing this part of the initiative for about 15 years, and then when we acquired in 2010 OneData, it just made natural sense to say, "Hey, we're going to go to market with this tool and with the methodology that we have developed over the last 15 years as a combined, unified offering," and that's how we came about the process-driven MDM message, the process-driven MDM dummies book and that's how we go to market these days.&gt;&gt; *You can read this at: http://www.itbusinessedge.com/cm/community/features/interviews/blog/why-master-data-should-start-with-the-business-process-not-the-data/?cs=50188&amp;utm_source=itbe&amp;utm_medium=email&amp;utm_campaign=EEB&amp;nr=EEB &lt;http://www.itbusinessedge.com/cm/community/features/interviews/blog/why-master-data-should-start-with-the-business-process-not-the-data/?cs=50188&amp;utm_source=itbe&amp;utm_medium=email&amp;utm_campaign=EEB&amp;nr=EEB&gt; * * Gervas* Ger </pre> Gervas Douglas 2012-04-19T15:50:22 2nd CfP: WoMO 2012 - 6th Int'l Workshop on Modular Ontologies http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12381 <pre>======================================================== 6th Int'l Workshop on Modular Ontologies (WoMO) Graz, Austria, July 24, 2012 held in conjunction with FOIS 2012 --- Second Call for Papers --- ======================================================== Submission deadline: May 11, 2012 ======================================================== INVITED SPEAKERS: * Thomas Eiter, Vienna University of Technology, Austria Title TBA * Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy Multi context logics: a formal support for structuring knowledge and beliefs (Tentative title) http://www.informatik.uni-bremen.de/~ts/womo2012 MODULARITY, studied for years in software engineering, allows mechanisms for easy and flexible reuse, generalization, structuring, maintenance, design patterns, and comprehension. In formal and applied ontology, modularity is central to reducing the complexity of designing and understanding ontologies, and to facilitating ontology verification, reasoning, development, maintenance and integration. Recent research on ontology modularity shows substantial progress in foundations of modularity, techniques of modularization and modular development, distributed reasoning and empirical evaluation. These results provide a solid foundation and exciting prospects for further research and development. The workshop continues a series of successful events that have been an excellent venue for practitioners and researchers to discuss latest and current work; the most recent WoMOs were held at FOIS 2010 and ESSLLI 2011. TOPICS include, but are not limited to: - What is modularity?: kinds of modules and their properties; modules vs. contexts; design patterns; granularity of representation; - Logical/foundational studies: conservativity; modular ontology languages; reconciling inconsistencies across modules; formal structuring of modules; heterogeneity; - Algorithmic approaches: distributed and incremental reasoning; modularization and module extraction; sharing, linking, reuse; privacy; evaluation of modularization approaches; complexity of reasoning; implemented systems; - Applications: semantic web; life sciences; bio-ontologies; natural language processing; space and time; ambient intelligence; social intelligence; collaborative ontology development and ontology versioning. IMPORTANT DATES Paper Submission: May 11, 2012 Notification: June 12, 2012 Camera ready: July 1, 2012 Workshop: July 24, 2012 SUBMISSION GUIDELINES: We welcome submissions on modularity in a broad sense. The workshop is open to papers of theoretical or practical nature. Submissions should be of up to 11 pages in length, formatted according to Springer LNCS style (see http://www.springer.com/comp/lncs/Authors.html ), prepared in PDF format and submitted no later than May 11, 2012, through the EasyChair Submission System (see http://www.easychair.org/conferences/?conf=womo2012 ). Submitted papers will be peer-reviewed by members of the program committee. Accepted papers will be made available in the proceedings to be published electronically in the CEUR Workshop Proceedings series (see http://www.ceur-ws.org ). (Find the WoMO 2010 and 2011 proceedings here http://www.booksonline.iospress.nl/Content/View.aspx?piid=16268 and http://www.booksonline.iospress.nl/Content/View.aspx?piid=20369 ) WORKSHOP CHAIRS: Thomas Schneider, University of Bremen, Germany Dirk Walther, Technical University of Madrid (UPM), Spain PROGRAM COMMITTEE: Kenneth Baclawski, Northeastern University, Boston, MA, USA Stefano Borgo, Italian National Research Council, Trento, Italy Oscar Corcho, Universidad Politecnica de Madrid, Spain Bernardo Cuenca Grau, University of Oxford, UK Mike Dean, Raytheon BBN Technologies, Ann Arbor, MI, USA Silvio Ghilardi, Universita degli Studi di Milano, Italy Michael Gruninger, University of Toronto, Canada Janna Hastings, EMBL-EBI, Cambridge, UK Robert Hoehndorf, University of Cambridge, UK Boris Konev, University of Liverpool, UK Roman Kontchakov, Birkbeck College, London, UK Thomas Meyer, Meraka Institute, CSIR, Pretoria, South Africa Till Mossakowski, University of Bremen, Germany Immanuel Normann, Birkbeck College, London, UK Leo Obrst, MITRE, McLean, VA, USA Adrian Paschke, Free University of Berlin, Germany David Perez del Rey, Universidad Politecnica de Madrid, Spain Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy ------------------------------------ Yahoo! Groups Links &lt;*&gt; To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ &lt;*&gt; Your email settings: Individual Email | Traditional &lt;*&gt; To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) &lt;*&gt; To change settings via email: service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ </pre> WoMO 2012 2012-04-19T12:41:16 [ZapFlash] Cloud-Oriented Architecture and the Internet of Things http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12380 <pre> Cloud-Oriented Architecture and the Internet of Things Document ID: | Document Type: ZapFlash By: /Jason Bloomberg/ | Posted: /April 18, 2012/ Quick quiz for all your Cloud aficionados out there: what's /missing/ from the NIST definition of Cloud Computing &lt;http://t.ymlp280.net/uyeqbaoamhubagauuqacambmuu/click.php&gt;? To make this challenge easy for you, here's the definition: "Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction." Give up? What's missing is any mention of /data centers/. Sure, today's Clouds typically consist of resources in data centers, running one way or another on racks full of physical servers. But there's nothing in the definition of Cloud that specifies anything about the physical location of Cloud resources. Look at the NIST definition again. If you've seen this definition before, you may notice a new word that NIST presumably added after their now-seminal definition entered the blogosphere: /ubiquitous/. I don't know what fevered discussion led to the late inclusion of this word, but its addition is telling. After all, it doesn't matter how many data centers you have, they will never be ubiquitous. But NIST in their wisdom never intended the resources in the definition of Cloud to be limited to data centers, or for the list of Cloud resources to be exhaustive, for that matter. We could add, say, mobile phones, automobiles, factory equipment, and the proverbial fridge to the list, and as long as we have the convenient, on demand network access as well as the automated provisioning and deprovisioning, then this entire "Internet of Things" is part of the Cloud. This globally ubiquitous interpretation of Cloud Computing should be especially exciting to architects, since it falls to them to understand all the technology resources at the disposal of the organization and how to address business challenges with such resources. From ZapThink's perspective, the Internet of Things provides a grand stage for our ZapThink 2020 vision &lt;http://t.ymlp280.net/uyeqhafamhubaoauuqaiambmuu/click.php&gt; to play out. There are fundamental differences, after all, between data centers and the Internet of Things, which means that fundamental Cloud architecture principles must also transform to support this new reality. This transformation promises to be truly disruptive---a true paradigm shift as we figure out what it means to implement what we call /Cloud-Oriented Architecture/. *Understanding Resources* Since Cloud-Oriented Architecture (COA, natch) extends past the data center to the ubiquitous resources of the Internet of Things, we must expand our definition of /resource /beyond the list in the NIST definition of Cloud Computing. The obvious place to go for such a definition is the REST architectural style &lt;http://t.ymlp280.net/uyeqwalamhubagauuqapambmuu/click.php&gt;, which defines a resource as "an entity or capability on a network." Note that resources in "traditional" (i.e., data center-based) Clouds are a subset of this broader definition of resource. In RESTful terms, Web pages, php scripts, and ASP/JSP pages, for example, can all be resources. We wouldn't normally lump such resources in with servers, storage, networks, and the other Cloud resources we typically talk about in the Cloud context. But in COA, where we free the Cloud from the data center, /anything/ we can give a Uniform Resource Indicator (URI) to can be a resource. And of course, with IPv6 &lt;http://t.ymlp280.net/uyeqqaxamhubalauuqarambmuu/click.php&gt; we have plenty of IP addresses to go around, where anything might have one---and if a thing has an IP address, it can certainly have one (or more) URIs. So far, so good, but beware a pitfall in our path: Resource-Oriented Architecture &lt;http://t.ymlp280.net/uyeqyanamhubaiauuqanambmuu/click.php&gt; (ROA). ROA takes certain elements of REST and recasts traditional integration by leveraging RESTful APIs. ROA has its place to be sure, as it resolves some of the knottier problems of Web Services-based SOA, but ROA is decidedly /not/ COA. In fact, they are at opposite ends of a philosophical spectrum that underscores the paradigm shift inherent in moving to the Cloud. *ROA + HOA = COA* In fact, COA is really more about Hypermedia-Oriented Architecture &lt;http://t.ymlp280.net/uyeysacamhubaxauuqalambmuu/click.php&gt; (HOA) than ROA. The point to assigning URIs to resources, after all, is to build distributed hypermedia applications, which are the point of REST &lt;http://t.ymlp280.net/uyeyuakamhubafauuqavambmuu/click.php&gt;. This is where you need to make a conceptual leap: while the traditional notion of a hypermedia app is a glorified Web site, with COA, applications consist of hyperlinked resources of any type, from mobile apps to traffic signals. We've been networking traffic signals for decades, of course, so what's really new here? The answer: /control/. Traditional distributed applications have centralized control, while distributed hypermedia apps do not. In fact, this distribution of control is what we mean by the prefix "hyper," and is what makes the Web what it is today. Remember the green screen menu-based interfaces from the 1960s and 1970s? You clicked on a menu item to load a different screen. But those links weren't /hyperlinks/, because they couldn't take you to a screen (or page) on a different system. The secret of hypertext (now hypermedia) is that it enables the Web to be /worldwide/, with no central point of control. Fast forward to the present, and today's world of distributed computing has a schizophrenic nature: the world of enterprise IT with its inherently centralized control, and the world of the Web---horizontally scalable, partition tolerant &lt;http://t.ymlp280.net/uyeyeakamhubakauuqafambmuu/click.php&gt;, and lacking a single point of control. And now we have the Cloud, and COA bringing the two together. It's time to bring enterprise IT into the 21^st century, kicking and screaming. We managed to survive the rise of the Web itself, as IT managers begrudgingly provided Internet access to employees' desktops. Now with the ubiquitous penetration of mobile technology (there's the U word again!), those managers are once again struggling to maintain control, lest the enterprise rank and file download some malicious app or other malware that brings the organization to its knees. This situation is only going to get worse (or better, depending on your point of view). Mobile devices are only going to get more powerful. The Internet of Things will continue to grow past our smartphones as Cloud resources penetrate every aspect of our daily lives. The cybersecurity &lt;http://t.ymlp280.net/uyeymaiamhubadauuqatambmuu/click.php&gt; implications are profound, let alone the day-to-day issues of governance. Enterprises who don't rise to the challenge and revamp their thinking about how technology contributes to the operations of the business are sticking their heads in the sand. We encouraged IT organizations to loosen the ties of control as far back as 2008, when we explained Why Today is a Perfect Time for No-ESB SOA &lt;http://t.ymlp280.net/uyeyjapamhubagauuqatambmuu/click.php&gt;. Move the control to the Service composition level, we argued, and free yourself from the limitations and inflexibility of a middleware-centric approach to integration. Four years later, this move to lightweight, decentralized Business Process Management &lt;http://t.ymlp280.net/uyeybakamhubaiauuqaiambmuu/click.php&gt; (BPM) is still a work in progress, in part because the BPM tools on the market follow the old middleware-centric patterns, but also because the marketplace is not yet ready for the paradigm shift that we're now in the midst of. Today's question, therefore, is whether the market---that is, /you/---are ready for COA. Are you ready to free the Cloud from the data center? Are you ready to give up centralized security in favor of a lightweight, federated approach? Are you ready to discard the API-centric ROA in favor of the truly RESTful HOA? Perhaps. But such changes in thinking take time. But ready or not, change is afoot. Be an ostrich and continue to do things the old way at your peril. *The ZapThink Take* ZapThink has been piecing this story together for years now, and we'll pull all the threads together in our upcoming book, /The Agile Architecture Revolution/ (John Wiley &amp; Sons, 2013). As we move away from vertically scalable enterprise applications that require and promote central control to a Cloud of distributed resources that cross organizational boundaries, organizations will need to rethink---and in many cases, reinvent---their approach to governance &lt;http://t.ymlp280.net/uyeyhanamhubaoauuqatambmuu/click.php&gt;, security, scalability, and change. In other words, a new way of looking at architecture. We don't call this shift a revolution &lt;http://t.ymlp280.net/uyeywagamhubapauuqapambmuu/click.php&gt; lightly. True revolutions require paradigm shifts: throwing out old ways of thinking and replacing them with entirely different approaches. As a result, paradigm shifts suggest some manner of disruption and discontinuity that in turn differentiates revolutionary change from evolutionary change. Furthermore, revolutionary change is difficult to identify while it's happening. People usually aren't sure they've been through a revolution until after the fact. Evolutionary change, on the other hand, is far easier to detect, and can move so fast that people confuse it with a true paradigm shift. We got it wrong in the dot.com era. The hype around the "New Economy" turned out to be just that---hype. The Web turned out to be more of a new marketing channel than a true paradigm shift. The Agile Architecture Revolution, however, is more subtle, because it involves so many different types of change across so many different areas of endeavor &lt;http://t.ymlp280.net/uyeyqavamhubazauuqalambmuu/click.php&gt;. We won't be sure till we're done, of course, but the disruption is already upon us. Don't be an ostrich. </pre> Gervas Douglas 2012-04-18T14:07:27 Call for Tutorial Proposals co-located with the International Semantic Web Conference (ISWC 2012) http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12379 <pre>------------------------------------------------------------------------ Call for Tutorial Proposals http://iswc2012.semanticweb.org/call-tutorial-proposals In conjunction with the 11th International Semantic Web Conference http://iswc2012.semanticweb.org/ Boston - USA November 11-15, 2012 ------------------------------------------------------------------------ The International Semantic Web Conference (ISWC) is the primary conference on the use of semantic technologies on the web and linked data, constantly attracting a high number of high quality submissions participants from academia and industry. It brings together researchers from different areas of computer science, like artificial intelligence, databases, natural language process, information retrieval and others that aim at the development and use of novel technologies for accessing, interpreting and using information on the web in a more effective way. Besides the main technical program, ISWC will host a number of tutorials on all major topics related to the Semantic Web / Linked Data research, enabling attendees to fully appreciate current issues, main schools of thought, and possible application areas. In order to meet these goals, tutorials should address topics that satisfy the following criteria: - the topic falls in the general scope of ISWC 2012, - there is a clear focus on a specific technology, problem or - application, and - there is a sufficiently large community interested in the topic. In particular, we encourage the submission of tutorial proposals on: - fundamental problems of the Semantic Web/Linked Data such as ontology mining, heterogeneity, scalability and distribution, - applications of Semantic Web technologies in specific domains and trends, - important enabling technologies and their adaptation to the needs of the Semantic Web, - aspects of semantic web research that have been neglected so far, and - techniques from other research fields that are of relevance for Semantic Web research (e.g., machine learning, NLP). Additionally, we expect tutorials to: - have practical parts in terms of examples or preferably exercises to be carried out by the participants Proposers of accepted tutorials have to prepare a tutorial webpage containing detailed information about the tutorial. Submission Guidelines ----------------------------------- Tutorial proposals should be submitted via EasyChair https://www.easychair.org/conferences/?conf=iswc2012tutorials as a single PDF file of no more than 5 pages and should contain the following information: - Title - Abstract (200 words) - Motivation on why the topic is of particular interest at this time - Overview of content, description of the aims, presentation style, potential/preferred prerequisite knowledge - Indication on whether the tutorial should be considered for a half-day or full-day - Intended audience and expected number of participants - Audio-visual or technical requirements and any special room requirements (for hands-on sessions, any software needed and download sites must be provided by the tutorial presenters) - Data of the presenters (name, affiliation, email address, homepage) and short description of their expertise, experiences in teaching and in tutorial presentation Important Dates -------------------------- - Event: November 11 &amp; 12, 2012 - Tutorial proposal due: May 6, 2012 - Tutorial Notifications: May 20, 2012 Chairs -------------- Claudia d’Amato, Unversity of Bari Thomas Scharrenbach, University of Zurich ------------------------------------ Yahoo! Groups Links &lt;*&gt; To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ &lt;*&gt; Your email settings: Individual Email | Traditional &lt;*&gt; To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) &lt;*&gt; To change settings via email: service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw&lt; at &gt;public.gmane.org &lt;*&gt; Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ </pre> Oshani Seneviratne 2012-04-17T12:37:25 Update from Anne http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12378 <pre> &lt;&lt;Manes on SOA in 2012: "People get the architecture" -mail &lt;http://searchsoa.techtarget.com/feature/Manes-on-SOA-in-2012-People-get-the-architecture#&gt;in &lt;http://searchsoa.techtarget.com/feature/Manes-on-SOA-in-2012-People-get-the-architecture?vgnextfmt=print&gt; * A &lt;http://searchsoa.techtarget.com/feature/Manes-on-SOA-in-2012-People-get-the-architecture#&gt; * AA &lt;http://searchsoa.techtarget.com/feature/Manes-on-SOA-in-2012-People-get-the-architecture#&gt; * AAA &lt;http://searchsoa.techtarget.com/feature/Manes-on-SOA-in-2012-People-get-the-architecture#&gt; * LinkedIn &lt;http://searchsoa.techtarget.com/feature/Manes-on-SOA-in-2012-People-get-the-architecture#&gt; * Facebook &lt;http://searchsoa.techtarget.com/feature/Manes-on-SOA-in-2012-People-get-the-architecture#&gt; * Twitter &lt;http://searchsoa.techtarget.com/feature/Manes-on-SOA-in-2012-People-get-the-architecture#&gt; * Share This &lt;http://searchsoa.techtarget.com/feature/Manes-on-SOA-in-2012-People-get-the-architecture#&gt; * RSS &lt;http://searchsoa.techtarget.com/rss/ContentSyndication.xml&gt; * Reprints &lt;http://reprints.ygsgroup.com/m/techtarget&gt; Growing use of Web and mobile apps challenge established application strategies. Long-time SOA expert Anne Thomas Manes sees mobile and Web as a possible game changer. Famed in SOA circles for her pointed "SOA-is-dead" critique of 2009, Manes saw progress with use of service-oriented architecture in 2011. We spoke with her recently to get a few ideas about the more complex environments in the future that will require new patterns and approaches. /Anne Thomas Manes &lt;http://www.gartner.com/AnalystBiography?authorId=37083&gt;is a vice president and distinguished analyst at Gartner. She directs research for a team in the Gartner for Technology Professionals (GTP) research group. The focus of her research is on BPM, SOA and cloud computing. Manes' areas of expertise include application development and integration and data management and integration. / *Back in 2009, you blogged that "SOA is dead." You talked at the time of how it was being oversold. What is your opinion on the state of SOA today?* *Anne Thomas Manes:*I think that people's realization that they want a single application tosupport multi-channel interfaces &lt;http://searchsoa.techtarget.com/news/2240111867/Gartner-AADI-2011-Manes-says-software-architecture-must-change&gt;---they want to support a browser, a mobile app, a programmatic interface---is inspiring people to really grasp what the SOA paradigm is all about. They are, in fact, now starting to design/services/as opposed to/multi-tier applications/. We're now reaching a point where people are saying, "I don't want to have separate application systems---one for my mobile apps, one for my browser-based apps." They're saying, "I want to have one implementation of this order-entry system and I want that same implementation to be able to support my mobile clients and my regular desktop clients. That is driving people to reallyadopt service-orientation. &lt;http://searchsoa.techtarget.com/feature/Mobile-application-integration-gets-SOA-ized-SOA-goes-mainstream-2012&gt; When I wrote that blog post [the approach to SOA] was all about technology, it was all about the protocol. It wasn't actually about the change in architectural model. Now we've reached the point where people are starting to actually get the architecture.&gt;&gt; *You can find this at: http://searchsoa.techtarget.com/feature/Manes-on-SOA-in-2012-People-get-the-architecture * *Gervas* </pre> Gervas Douglas 2012-04-11T19:04:39 Mann on SOA & Mobile http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12377 <pre> &lt;&lt;Will ''mobile business model'' influence the future of SOA? Stephanie Mann * E-mail &lt;http://searchsoa.techtarget.com/feature/Will-mobile-business-model-influence-the-future-of-SOA#&gt; * Print &lt;http://searchsoa.techtarget.com/feature/Will-mobile-business-model-influence-the-future-of-SOA?vgnextfmt=print&gt; * A &lt;http://searchsoa.techtarget.com/feature/Will-mobile-business-model-influence-the-future-of-SOA#&gt; * AA &lt;http://searchsoa.techtarget.com/feature/Will-mobile-business-model-influence-the-future-of-SOA#&gt; * AAA &lt;http://searchsoa.techtarget.com/feature/Will-mobile-business-model-influence-the-future-of-SOA#&gt; * LinkedIn &lt;http://searchsoa.techtarget.com/feature/Will-mobile-business-model-influence-the-future-of-SOA#&gt; * Facebook &lt;http://searchsoa.techtarget.com/feature/Will-mobile-business-model-influence-the-future-of-SOA#&gt; * Twitter &lt;http://searchsoa.techtarget.com/feature/Will-mobile-business-model-influence-the-future-of-SOA#&gt; * Share This &lt;http://searchsoa.techtarget.com/feature/Will-mobile-business-model-influence-the-future-of-SOA#&gt; * RSS &lt;http://searchsoa.techtarget.com/rss/ContentSyndication.xml&gt; * Reprints &lt;http://reprints.ygsgroup.com/m/techtarget&gt; The SearchSOA.com Reader Challenges &amp; Priorities 2011-2012 Survey indicates that businesses are investing more in mobile apps: 44% of respondents said that mobile application integration and infrastructure software will gain more budget within their organizations in the next two years (see*Figure 1*). The natural question is whether---and how---the resulting needs of mobile application and integration development will influencethe future of SOA &lt;http://searchsoa.techtarget.com/feature/Mobile-application-integration-gets-SOA-ized-SOA-goes-mainstream-2012&gt;. &lt;http://cdn.ttgtmedia.com/rms/onlineImages/SSOA-MobileFigure2-3-29-12-SM2.png&gt; *Figure 1:*SearchSOA.com's 2011-2012 Reader Survey suggests a future trend of increased spending on mobile applications. In recent years, SOA has been forced to adapt to emerging cloud and mobile app development requirements. Limits to memory, storage and screen size on mobile devices have compelled developers to"chunk" services &lt;http://searchsoa.techtarget.com/tip/Service-chunking-integrates-mobile-apps-into-enterprise-portfolios&gt;to better serve mobile users. Application design has transformed to address thevulnerability of mobile back-end systems &lt;http://searchsecurity.techtarget.com/news/2240118656/Developers-must-improve-mobile-app-security-or-face-backlash-experts-say&gt;. And themiddleware &lt;http://searchsoa.techtarget.com/feature/Mobile-middleware-services-help-connect-devices-to-back-ends&gt;has had to address the unique needs of a mobile space packed with diverse platforms and devices. Perhaps more important is this: The rush to mobile applications could well lead both IT and business leaders to rethink their business architectures. Experts suggest that, going forward, the mobile worker and the consumer will be more central to successful IT planning. "Whatever we've done with SOA up to now, we've done in support of the traditional model of worker-productivity empowerment, because that's the only model we've had," said Tom Nolle, president of CIMI Corp., a telecommunications and media strategy consultant group. "If there's anything that's going to be the focus of re-conceptualized business processes, it's going to be the mobile worker." As mobile expands, it shows signs of changing traditional business models. Increasingly intelligent devices are changing the way businesses operate, allowing workers instant access to information and providing them support faster than ever before. "That [the mobile] device is uniquely able to follow workers wherever they are---support whatever activity is essential to their productivity---means that that device is probably going to be a big part of how we do business in the future," Nolle said. The answer to how mobile will influence SOA, then, could depend on how mobile will change the way people do business. According to Forrester Analyst Randy Heffner, mobile should not fundamentally change SOA---if it is being done well. He also noted that the transition to mobile is better for businesses with solid SOA infrastructure already in place. "If you're doing SOA well, it will be easier to do the things you need to do via mobile or any other platform," he said. "If you aren't doing SOA well, then maybe one of the impacts of doing mobile is it exposes the weaknesses in how you've been approaching the design of your services. And it/feels/like it's changing how SOA should be done when really you've just been doing it wrong." The idea that implementing mobile will expose "bad" services design could be at the root of how mobile might influence the future of SOA: from the business-side. How businesses design services is linked to their business models. "Entering into mobile [points out] how you need to be designing much more around your business rather than application integration," Heffner explained. SearchSOA.com survey respondent Howard Gunn, vice president of WorldView Network Services and author of/The Basics of IPTV/ &lt;http://www.amazon.com/Basics-IPTV-Books/dp/193169558X&gt;, reflected that as mobile needs become more widespread, SOA will have to change to further address the issues of security inherent in cloud and mobile applications. "We're not yet at the point of being able to trust a wireless device," he said. "Virtually any person using a wireless device today is exposed to hacks. As long as there are electronic wallets existing in cell phones, there will be electronic pick-pockets." Gunn also pointed to the mobile device user as a prime driver of future change. "Today, complex applications are being driven by the device user," he said. "And eventually, business processes will move toward the consumer." The rapid pace of device innovation on the front end requires flexible SOA on the back end. "You don't know what the method of interaction will be in the future and your approach to SOA best not be dependent upon it," Heffner said. With the advent of the Web and Web browser, elements of software architecture changed drastically. More change is in store. The recent wave of "always connected" smart devices might be the next frontier of communication and customer engagement, but it certainly will not be the last.&gt;&gt; *You can find this at: http://searchsoa.techtarget.com/feature/Will-mobile-business-model-influence-the-future-of-SOA * *Gervas* </pre> Gervas Douglas 2012-04-11T18:38:27 SnapLogic, REST and Clouds http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12376 <pre> &lt;&lt;SnapLogic Uses REST-Based Approach to Cloud and On-Premise Integration /byLoraine Lawson &lt;http://www.itbusinessedge.com/cm/people/LoraineLawson&gt;, IT Business Edge 26-mar-2012 11:57:36/ *John Schuster &lt;http://www.linkedin.com/in/jcsjcsjcs&gt;*, vice president of engineering at*SnapLogic &lt;http://www.snaplogic.com/&gt;*, explains to IT Business Edge's Loraine Lawson how he sees both cloud and Big Data putting new demands on ETL and EAI integration approaches. "We have the ability to deploy SnapLogic in the cloud, but connect to data sources that are on-premise behind a customer firewall. This is really important because a lot of customers want to build pipelines that connect sources and destinations that are in different security zones ... " John Schuster VP of Engineering SnapLogic *Lawson:*What's the basis for your integration work? Is it ETL? *Schuster:*Actually, we find ourselves answering questions about what we are quite a bit because in cloud integration, ETL and EAI are not quite as clear. Typically in cloud integration there's a little bit of both to get your job done. We really see ourselves as enabling our customers to integrate their cloud applications. That requires some amount of ETL-like data movement and transformations, but certainly also requires EAI-like functionality to interface with the different applications that might be data sources or data destinations. Beyond that, we also see that Big Data and cloud are in fact changing the landscape quite a bit. In some ways, you can think about it as Big Data pushing on ETL and cloud pushing on EAI and creating this gap in market opportunity that we're trying to basically fill the void by providing the right set of features and functionality to allow customers to get their job done. *Lawson:*Why do you say cloud is "pushing" EAI? *Schuster:*It's making demands on EAI products. The number and diversity of applications and data formats is drastically increasing over time. If you think about products that were designed 10 years ago or longer, in the '90s, they're really designed for a smaller number of applications, typically running on a LAN or a fast, reliable network. When the number increases and the networks become less reliable and the cloud service providers become much more reliable, it actually changes the product requirements on EAI. Anytime you kind of have an order of magnitude increase in the number of things that you're processing or the amount of data that you're processing, it really changes how you architect products. For example, if you're designing a system to be reliable, you might make the assumption that the network has low latency and is fast, but actually, if you take the product that you built for that and put it on the Internet and tell it to transfer data between Salesforce and SAP behind a firewall, it might not work out the way you hoped. You might need a product that understands how to recover from failures, how to deal with high latency, how to retry in the event of failure. That would be an example of how I see cloud changing EAI landscape. *Lawson:*How is Big Data changing ETL? *Schuster:*Again, when you designed a system to move data from point A to point B and transform it, you might have made assumptions like, for example, that you can actually process all that data on a single server. In fact, with Big Data, that's no longer the case. When you need to process say a terabyte or 10 terabytes of data instead of a sizable chunk like maybe 100 GBs, you need a different product. You need a Big Data processing engine like Hadoop has Hadoop Cluster and you need a product that knows how to interface with that. Again, when things tend to grow by orders of magnitude, you really need to design differently.&gt;&gt; *You can find this interview at: http://www.itbusinessedge.com/cm/community/features/interviews/blog/snaplogic-uses-rest-based-approach-to-cloud-and-on-premise-integration/?cs=50072&amp;utm_source=itbe&amp;utm_medium=email&amp;utm_campaign=EEB&amp;nr=EEB &lt;http://www.itbusinessedge.com/cm/community/features/interviews/blog/snaplogic-uses-rest-based-approach-to-cloud-and-on-premise-integration/?cs=50072&amp;utm_source=itbe&amp;utm_medium=email&amp;utm_campaign=EEB&amp;nr=EEB&gt; * * Gervas* </pre> Gervas Douglas 2012-04-07T00:00:55 [ZapFlash] Avoiding Unexpected Cloud Economics Pitfalls http://comments.gmane.org/gmane.comp.web.services.soa.yahoo-1/12375 <pre> Avoiding Unexpected Cloud Economics Pitfalls Document ID: | Document Type: ZapFlash By: /Jason Bloomberg/ | Posted: /April 4, 2012/ Anybody who is considering a move to the Cloud knows that the greatest economic motivation for Cloud Computing is the pay-as-you-go, pay-for-what-you-need utility computing benefit, right? Deal with spikes in demand much more cost-effectively, the public Cloud service providers gush, since we can spread the load over many customers and pass the savings from our economies of scale on to you. The utility benefit is also a central premise of Private Clouds. Build a Private Cloud for your enterprise, the vendors promise, and you can achieve the same economies of scale as Public Clouds without all that risk &lt;http://t.ymlp257.net/uyujuaiamjjwagaeuyadambmuu/click.php&gt;. Unfortunately, what sounds too good to be true usually is. There are a number of gotchas on both the Public and Private Cloud provider sides that limit---or even prevent---organizations from obtaining a full measure of the utility benefit. Let's go back to economics class and take a closer look. *Clouds Like Water?* Turn on the faucet, only instead of water, you get Cloud. Sounds good, but we use water very differently than we do IT resources. With water, we generally use all we need without worrying about price. We may try to economize, and perhaps we'll go through the trouble of digging a well if we need to fill our pool, but generally we don't think about the cost of each flush or load of laundry. The Cloud is just the opposite. The techies might not be thinking in terms of cost, but the bean counters definitely are. For a CIO or purchasing manager comfortable with entering resource costs into annual budget spreadsheets, the unknown nature of the Cloud bill strikes fear into their hearts---and their wallets. Instead of focusing on lowered costs, their worry is /increased costs/, since Cloud usage is inherently unpredictable. After all, that's why landlords don't like including heating costs in the rent. If the tenants aren't responsible for keeping costs down then /pay-as-you-go/ inevitably translates into /pay more---/and just how much more is a mystery until the bill arrives. Enterprise Cloud customers in particular are beginning to push back, and as a result, Public Cloud providers must change their pricing model accordingly. Unfortunately, there aren't many alternatives to simple pay-as-you go. One increasingly popular alternative that might ease Cloud purchasers' minds is for providers to offer a tiered pricing system, with a fixed price for any consumption up to a pre-defined threshold, and pay-as-you-go above that. However, tiered pricing is not a panacea. While such a pricing model is straightforward and gives organizations an increased measure of predictability, it still doesn't solve the problem of cost spikes. If tiered pricing sounds more like paying for your mobile phone service than for utilities like water or electricity, you're right. Not only does this approach reduce perceived risks for Cloud purchasers, it's also a familiar model for the telcos, all of whom are looking to enter the Cloud market, or at the least, grow their existing Cloud offerings. As a result, ZapThink expects tiered pricing to become the norm for Public Cloud services over time, in spite of its drawbacks. The irony with tiered Cloud pricing is that the more you require elasticity &lt;http://t.ymlp257.net/uyujeaxamjjwaoaeuyarambmuu/click.php&gt;, the greater the risk that you'll use up your allotted consumption for the month---but elasticity is the most important benefit of the Cloud. Sure, if you have steady, predictable consumption then tiered pricing is low risk, but if all you want is steady, predictable availability, then chances are keeping your resources on-premise or in a traditional hosted facility will be more cost-effective than moving to the Cloud in the first place, since you're not particularly worried about spikes in demand. To make matters worse, not everyone likes tiered pricing, of course. Anyone who's used up their minutes or texts for the month only to be surprised by an excessive phone bill knows what I'm talking about. It seems the mobile phone providers love to play games with their pricing plans for the sole purpose of squeezing every penny out of their hapless customers. I'm sure we don't want our Cloud providers to play the same dirty tricks. *The Subtleties of Cloud Churn* While it's a common water cooler pastime to demonize mobile phone companies for their underhanded pricing policies, there is a downside for the providers as well: the dreaded customer churn. Since it's relatively easy for customers to change phone providers, especially now that number portability is a reality, shifty behavior on the part of providers simply chases away customers. Cloud churn is a very real problem for Public Cloud providers as well, as the ease of deprovisioning Cloud resources naturally eases the deprovisioning of customers. But there is an extra complication with Cloud churn that doesn't have a parallel in the mobile phone world: Cloud resources that are no longer being used but still remain allocated to customers. Depending on the provider's pricing model, the cost to the customer to maintain such resources may be minimal, but it's not always clear whether those minimal amounts sufficiently cover the providers' costs. For example, I get monthly charges on my credit card from Amazon Web Services (AWS) for a few cents each month. I can't remember how I signed up for AWS, but the amounts are so minimal, it's not worth my time or trouble to cancel the service. Do those few cents per month cover Amazon's costs, assuming there are potentially millions of such customers? Perhaps in Amazon's case---but for less experienced providers with wafer thin margins, the economics might work to their disadvantage. Furthermore, the proliferation of such idle instances may be a more significant issue for Private Cloud providers, since they typically have constrained budgets for data center buildouts. Amazon may be building new data centers as fast as they can, but your Private Cloud likely has a maximum practical size given your budget for the effort. The last thing you want is to fill it up with idle resources that various people in your organization can't be bothered to fully deprovision. *The Demotivation Paradox* For the Public Cloud provider, the obvious solution to the problem of idle resources left over from Cloud churn is to charge enough for those resources. Either the cost will motivate people to fully deprovision them, so the argument goes, or at the very least, they generate enough money so that keeping them around is worthwhile for the providers. But what if we're talking about Private Clouds here? The way to charge internal customers for using Cloud resources is via /chargebacks/. And /everybody/ hates chargebacks. Not only are they a bookkeeping hassle, but they also demotivate the consumption of shared resources. We went through this problem when we dealt with shared Services and SOA, and now we're sharing Cloud resources, but the problem remains: the whole point to the Private Cloud is to achieve economies of scale across the enterprise, but the only way to make such economies work is if most or all divisions participate. Chargebacks, however, discourage that participation. As it was with shared Services, the way to compensate for chargebacks is through /effective/ /governance/: establish and enforce Cloud consumption policies that counteract the demotivational effects of chargebacks, and come up with a way to motivate people to follow such policies. While you're at it, formulate policies governing the deprovisioning of instances that no one needs any more &lt;http://t.ymlp257.net/uyujmapamjjwanaeuyalambmuu/click.php&gt;. But in the Cloud, such governance is especially challenging because of the diversity of resources and their corresponding consumption scenarios: policies for provisioning virtual machines as part of IaaS is quite different from, say, provisioning development tools on PaaS. It will take organizations with Private Clouds a good bit of trial and error to get the balance right. *The ZapThink Take* Another downside to the idle-resource-masquerading-as-paying-customer problem is that it makes it very difficult for financial analysts to gauge the health of a Public Cloud provider. This obfuscation can skew traditional metrics like number of customers or revenue per customer, and the distortion may be different from one provider to another. Combine the resulting confusion with the lean profit margins in today's Cloud space, as providers push their prices ever lower to encourage growth, and you have a recipe for disaster. An ostensibly healthy Cloud provider might suddenly collapse &lt;http://t.ymlp257.net/uyujjanamjjwavaeuyanambmuu/click.php&gt; due to a foundation of underperforming customers and idle resources. Private Clouds face a corresponding problem, as executives review the financials for the Cloud effort. ZapThink predicts a backlash against Private Clouds in the next year or two, as vendors underdeliver on their Cloud promises---not necessarily through any fault of their technology, but rather because the reality of achieving cost advantages with Private Clouds is far more difficult than the vendors' and analysts' spreadsheets might have you believe. If you'd like to learn more about the subtleties of Cloud economics, I'd be happy to have a deeper discussion at Cloud Expo in New York &lt;http://t.ymlp257.net/uyujbadamjjwanaeuyagambmuu/click.php&gt; or The Business of Cloud Computing &lt;http://t.ymlp257.net/uyumuacamjjwavaeuyaoambmuu/click.php&gt; in Dallas, or any of the other conferences I'll be presenting at. Please drop me a line &lt;mailto:info-8lJlQpJYY41Wk0Htik3J/w&lt; at &gt;public.gmane.org&gt; if you're interested. I'm curious as to whether issues of Cloud churn or Private Cloud demotivation are concerns in your organization. </pre> Gervas Douglas 2012-04-04T20:47:09 Search Engine Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.services.soa.yahoo-1