www.archive-org-2014.com » ORG » E » EBPML

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".

    Archived pages: 467 . Archive date: 2014-12.

  • Title: ebpml | radio
    Descriptive info: .. ABOUT.. |.. COPYRIGHT.. Business.. | Process |.. Management.. Service {.. Oriented.. Computing.. }.. architecture.. driven.. = model /.. Home.. wsper.. infoq.. Blog.. publications.. latest news.. 5.. 29.. 2011 Canappi Launches.. Canappi is a Mobile Application Development Platform that enables you to build great iOS and Android native apps in half the time.. read more.. Book.. Blog roll.. Richard Veryard.. Steve Sfartz.. Johan den Haan.. Judith Hurwitz.. archives.. The old ebpml.. Welcome to ebPML.. org.. ebPML.. is a site dedicated to the standards, technologies and products of Service Oriented Computing, Business Process Management and Model Driven Architectures.. Grab this Headline Animator.. My main interest is to contribute to the concept of Service Oriented Computing that was initially coined by Prof.. Mike Papazoglou, with the hope to find an architecture and application model that will fully enable BPM and the convergence of EAI, B2B and application platforms like J2EE or.. NET.. I follow actively most BPM related standards: BPEL, BPEL4PEOPLE, BPMN, BPDL, XPDL, WS-CDL and ebBP.. I was one of the editors of the ebBP 1.. 1.. and 2.. 0 specifications.. The.. PML.. section (Process Markup Languages) provides an analysis of the leading specifications.. I have also started an effort to create the.. metamodel.. of the whole SOA specification stack, including the BPM related standards.. Here are a few places to start:.. You can download.. this minibook.. on InfoQ.. com (free after registration):.. Composite Software Construction: understanding SOA in the context of a programming model.. I have created.. a two hour flash presentation.. introducing the main concepts of the book.. If you need some of the figures from the book for your presentations, I have made them available.. here.. , an abstract SOA framework that I am working on.. This.. presentation.. which I gave as a guest of Prof..  ...   the implications of connectedness.. Jean-Jacques Dubray.. Quotes.. Barbara Liskov.. I believe that the fundamental role of programs is to modify state not just the bits.. Jon Bosak.. Business is complicated.. Any solution that doesn't reflect that complexity is not a real solution.. Steve Ballmer.. I believe our industry has a responsibility, and an opportunity, to dramatically simplify the computing environment by seamlessly weaving together all of the devices, services and multiple layers of software into a coherent, efficiently managed technology framework.. Matthieu Hug.. SaaS can not just be read as Software-as-a-Service, but most importantly as Service-as-a-Software.. Don Box.. [CORBA/DCOM] really assumes shared classes [.. ] between the two endpoints.. [SOA] exists to break this dependency.. This is the biggest architectural change but it's profound.. Kevin Pollari.. The real secret sauce of Service Oriented Architecture is enabling better uses and standardization of business application logic.. Fred Cummins.. The data that must remain the primary focus of attention for SOA are the data produced, consumed and managed by business systems that represent the past, present or future state of the enterprise.. From a business perspective, the concerns are not a matter of distributed storage but how the data are validated, managed and protected.. T.. Reenskaug.. Any method that prevents the programmer writing code, is a good method.. Joe Armstrong.. The world is concurrent but we program in sequential languages.. Ira Fuchs.. Programming languages today remain syntactic, abbreviated, and procedural, as opposed to semantic, verbose, and declarative.. Andrej Bauer.. It is good to have a simple language, but it is not good to sacrifice its expressiveness to the point where most of the time the programmer has to encode the concepts that he really needs indirectly with those available in the language.. ccopyright © 2001-2011 ebpml.. org |.. gmail/ebpmlblog.. design by dcarter..

    Original link path: /
    Open archive

  • Title: ebpml | about
    Descriptive info: Service Oriented, Process Centric, Model Driven Heresies.. ebpml.. FEED.. About.. Jean-Jacques Dubray is.. a Platform.. Strategist and Architect.. He is a contributor to InfoQ.. com, the creator of ebpml.. org and founder of.. Convergence Modeling.. He earned a Ph.. D.. from the Faculty of Science of Luminy (Marseilles, France), home of the Prolog Programming language, where he taught an Object Oriented Programming  ...   de Lyon (Ecully, France).. He lives near Seattle where he enjoys hiking, kayaking, gardening and playing soccer or music with his kids.. Even though Washington wines are quite an experience, his favorite is still a simple Patrimonio Rosé (chilled) from.. the island of Corsica where his family is from.. He can be contacted at gmail / jdubray.. copyright © 2007 ebpml.. gmail/jdubray..

    Original link path: /about.htm
    Open archive

  • Title: ebpml | radio
    Descriptive info: Feed.. This work is licensed under a.. Creative Commons Attribution-Share Alike 3.. 0 License..

    Original link path: /copyright.htm
    Open archive

  • Title: wsper.org | primer
    Descriptive info: about.. copyright.. wsper soa made simple.. home.. primer.. specificiaton.. samples.. contact.. 10.. 21.. 2007.. BPEL4PEOPLE 1.. 0 metamodel published.. 19.. BPMN 1.. 09.. 24.. SCA 1.. 23.. WSDL 2.. 07.. 08.. WSPER's primer released for comments.. Analyses.. WSDL.. SCA/SDO.. WS-BPEL.. QUOTES.. ABSTRACT.. Over the last 10 years the concept of Service Oriented Architecture grown from the simple idea of sending XML over HTTP.. A large stack of loosely related specifications followed to formalize these interchanges of data.. However, and by design, this stack never intended  ...   various vendor products has created a fairly large heterogeneity of concepts, yet achieving interoperability at the wire level.. wsper is a new programming language which supports an abstract SOA framework.. This framework is abstract because it can be implemented in several different ways and on top of different SOA infrastructures (SOI).. The goal of wsper is to federate the concepts that make service oriented architecture unique and help lower the barrier of entry to become a SOA developer or architect.. wsper's primer.. copyright 2007 wsper.. info@..

    Original link path: /wsper/wsper/primer.html
    Open archive

  • Title: ebpml | radio
    Descriptive info: Business.. | Process |.. 06.. 27.. 0 published as a W3C recommendation.. Conferences.. QCon San Francisco.. Nov 7-9, 2007.. SOA Business Process Conference.. Microsoft.. Oct 29 - Nov 1, 2007.. Eric Newcomer.. Radovan Janecek.. Brandon D.. Satrom.. John Evdemon.. Mark Masterson.. Sandy Kemsley.. Stefan Tilkov.. Jeff Schneider.. Paul Brown.. David Chappell.. Christian Bernard.. Swik.. Gabriel Morgan.. Jean-Jacques Dubray.. The Seven Fallacies of Business Process Execution.. After 8+ years of intense research, the software industry and its customers are hitting a wall.. The vision defined by BPM startups in the dotcom era has not materialized yet: we are still far from having the ability to use the business process models designed by business analysts to create complete executable solutions (even with minimal interventions from developers).. The need for process driven application models is real: Business Process Improvement initiatives are humming and running everywhere in G2000 companies, but despite such a strong need to continuously improve processes, the BPM market still remains marginal in 2007 (compared to what it could be).. Mike Papazoglou, Jean-Jacques Dubray.. A survey of Web Service Technologies.. The Web has become the means for organizations to deliver goods and services and for customers to search and retrieve services that match their needs.. Web services are self-contained, Internet-enabled applications capable not only of performing business activities on their own, but also possessing the ability to engage other web services in order to complete higher-order business transactions.. Simple web services may provide simple functions such as credit checking and authorization, inventory status checking, or weather reporting, while complex services may appropriately unify disparate business functionality to provide a whole range of automated processes such as insurance brokering, travel planning, insurance liability services or package tracking.. The act of building applications and processes as sets of interoperating services is enabled by means of unified service-oriented architecture (SOA).. SOA introduces a new philosophy for building distributed applications where elementary services can be published, discovered and bound together to create more complex valued-added services.. This article aims at providing a comprehensive survey of web service technologies, examining its usage, its relation with other technologies, the newest developments in the field, architectural models and standards.. The article presents an extended architecture on the basis of whose functional layers we taxonomize research activities.. Microsoft's Next Frontier.. Microsoft understands that the future belongs to those who can master connected systems.. Microsoft seems to be patiently establishing technical services, tools, an application model, programming languages, and domain specific languages for service oriented computing, with an appetite for innovation that is unmatched in the industry.. Constructing Software for Service Oriented Architecture.. Lots of people talk about web services, but few about how to construct (composite) applications which are using the web services.. This is my first  ...   the context of Service Oriented Architectures and offer some recommendations on key design aspects.. A case study: replacing the layer persistence of a business process engine with JDO.. , February 2003,.. The JDO specification (JSR-12) was released from the Java Community Process in April 2002.. Its goal is to provide transparent persistence to Java classes.. JDO offers the following features: Database independence, Transparent persistence, A degree of vendor independence (especially at the run-time level), Relatively low cost of a JDO product compared to the cost of developing and maintaining our own persistence code.. JDO is also well adapted to granular data models like the one of a business process engine.. Ira Fuchs,.. Web Services and Business Process Management Platforms -Understanding Their Relationship and Defining an Implementation Approach.. , November 2002.. Mr.. Fuchs develops a rationale for using BPM technologies in combination with Web Services.. Based on his analysis of different products and Microsoft BizTalk Server, he demonstrates the readiness of this technology and the immediate and tangible benefits for an enterprise.. This article is published with the written authorization of Microsoft for related sections.. Mike Papazoglou et al.. XSRL: XML Web Service Query Language paper.. , October 2002.. The paper details a novel approach to web service composition and orchestration: XSRL (XML Web Service Request Language).. XSRL help federate web services via a precise domain model and enable client interaction with this federation via a plan with possibility of managing non-deterministic results.. This work is key to address a class of problems which can be classified as semi-structured processes operating on information rich web services.. By contrast, for instance, a framework like ebXML addresses problem associated to structured business processes operating on transactional web services.. The end in mind.. , August 2002.. In this article I give my opinion on where the BPM.. enchilada.. is going and how it is positioned with respect to B2B, Web Services, Enterprise Infrastructures and modern Application Architectures.. A Novel Approach for Modeling Business Process Definitions.. , July 2002.. This article shows how it is possible to define the metamodel of a business process definition such that it leads to: a) decentralized business processes where the process management system is merely a mediator when needed and a monitor of the overall process state and integrity, b) technology neutral process definitions (Web Services, ebXML,.. ) c) enable clear modeling of collaborations with business partners, and users, d) is compatible with Enterprise Application Integration concepts.. A new model for multiparty collaborations.. July 2002.. This article shows how ebXML BPSS specification could be used to specify multiparty collaborations mixing ebXML business transactions and web service operation invocation.. In particular, the same model can be used to define the choreography of web services only.. ccopyright © 2007 ebpml..

    Original link path: /publications.htm
    Open archive

  • Title: ebPML.org
    Descriptive info: Carnets de bord.. Search for.. Web.. org.. |.. Process.. |Management.. Service.. {.. Computing}.. =.. model.. /.. Copyright Notice.. Events.. If you are new to the site the best places to start are:.. QCon.. San Francisco.. 11/07 - 11/09.. 2007.. Composite Software Construction.. Coming September, 2007.. , an abstract SOA framework.. You may also want to check this white paper I wrote on.. or.. Blogroll.. for the latest buzz.. The view  ...   concept of Glogs (Google logs).. This is the list of document (not web pages) generated via the Google web service API for a given set of keywords.. ebXML is no more complicated than it has to be in order to implement real-world business collaborations.. Conversely, Web services as they are currently defined seem simple precisely because they're not trying to deal with the complexities of real business relationships involving independent enterprises..

    Original link path: /old_home.htm
    Open archive

  • Title: Process Markup Languages
    Descriptive info: Carnets de bord.. There are five major business process definition languages being specified today.. BPML.. XLANG.. WSFL.. EDOC.. XPDL.. UML 2.. 0.. BPMI.. Microsoft.. IBM.. BEA.. OMG.. Workflow Management Coallition.. See also the summary from the Cover pages.. The meta model of each language vary quite a bit from one specification to another.. BMPL, XLANG and WSFL are all relying on the concept of Web Services.. They also clearly define a data flow (as XML documents), a control flow (block structured or transition based), a message flow (web services) and transaction flow.. However, they do not spend much time on specifying how users may interact with a BPMS.. The WfMC has mostly focused on that problem in the past (see user friendly column below).. On the other hand, the WfMC specification does not support a real message flow and only a very limited data flow (process variables).. The following table summarizes the differences between each data model.. (Please note that I do not have the UML 2.. 0 data points yet).. Note that.. Stefan Haberl.. provides another view of this matrix which I like better.. Specification.. Control flow.. Data flow.. Message flow.. Transaction.. EAI friendly.. B2B friendly.. User friendly.. BPML 1.. 0.. Block structured.. XML..  ...   account user interactions, though they are essential to resolve business process exceptions.. None of them is considering ebXML (or B2B semantics) as a first class citizen though they all claim that the main justification for BPMS is to handle and process the flow of business messages comes into an organization every day.. Lastly, only BPML has a few semantics (produce and consume) which come close of those needed for enterprise application integration.. One of the role of this web site is to pin point these discrepancies, and stimulate each consortium to complete their metamodel.. Will all PML specification converge? unfortunately, I think the answer is no.. There are schools of thoughts (e.. g.. block structured versus transition based) as well as specific requirements (e.. transactions) which will prevent the convergence.. I do hope that there are some level of convergence at the layers of a PML: control, data, message, transaction flows.. This will make the exchange of business process definitions easier, as well as enable the concept of.. libraries of business processes.. (IE5.. 0 only).. Here is a pointer to an article from web services architecture that compares and constrats BPML, WSFl, Xlang and BPSS.. Business Process Standards for Web Services: the candidates.. (.. David O'Riordan)..

    Original link path: /status.htm
    Open archive

  • Title: wsper.org | about
    Descriptive info: Primer.. specification.. additional links.. Links.. Specifications.. WS-BPEL 2.. BPEL4People 1.. 0 and WS-HumanTask 1.. WADL 2006.. HTTP/1.. APP 1.. Reference articles.. Boris Lublinsky.. Defining SOA as an architectural style.. , Jan 2007.. Olaf Zimmermann et al.. Elements of Service Oriented Analysis Design.. Ali Arsanjani.. Service Oriented Modeling and Architecture.. Adrian Mos.. STP Internal Model Discussion.. info@wsper..

    Original link path: /wsper/wsper/links.html
    Open archive

  • Title: ebpml | radio
    Descriptive info: ebpml's Introduction to SOA.. del.. icio.. us.. An Introduction to SOA.. This presentation is a newer version of the 2004 Constructing Software for Service Oriented Architecture.. The older version can be found.. This new presentation.. is the companion for the Composite Software Construction ebook, published on InfoQ.. com.. The 90 slide Presentation covers:.. Software Construction.. Service Orientation Crash Course.. The Composite Information System Vision.. What is Changing?.. A Case Study: a job application system.. Composite Application Patterns.. SOA Standards support a composite programming model.. Starting a composite software factory..

    Original link path: /com/an_introduction_to_SOA.htm
    Open archive

  • Title: wsper | an abstract SOA framework
    Descriptive info: wsper soa made simple.. PRIMER.. SPECIFICATION.. SAMPLES.. introduction.. WSPER ( whisper ) is the specification of an abstract SOA framework which can potentially be implemented with any SOA infrastructure or combination of SOA infrastructure elements.. The framework concepts extend and combine the concepts of.. SCA.. /SDO and.. BPEL.. The main goal of the framework is to create a service oriented, process centric and model driven application model from the point of view of the business logic that needs to be expressed when building composite information systems.. The framework is expressed as a programming language which enables the encoding of business knowledge in both a deployment and platform independent way.. WSPER aims at achieving portability and interoperability of the business logic as well as the standardization of the skills necessary to build a service oriented architecture.. The WSPER specification and licensing model are designed to enable anyone to write compilers to specific targeted platforms.. org will provide a compiler's reference implementation based on an open source infrastructure.. FAQ.. Is WSPER an acronym?.. WSPER stands for web, service, process, event resource which are the key ingredients of the language.. WSPER is published with a fairly restrictive licensing model, why?.. WSPER is published under the Creative Commons Attribution-NonCommercial-NoDerivs 3.. It will be so while WSPER is being designed.. The v1.. 0 of the specification will be published for royaltee-free, unrestricted commercial usage and with the capability to create derivatives, however, WSPER.. org will reserve the rights to incorporate these derivatives in the WSPER specification.. When do you expect to have the v1.. 0 completed?.. WSPER.. org intends to publish 2 versions (v0.. 8 and v0.. 9) prior to the 1.. 0 in order to seek community feedback and participation.. The reference implementation will start after v0.. 9 is published to help refine the specification.. The samples that you provide are using some java syntax, is WSPER part of the Java world?..  ...   and specified an application model from it.. WSPER itself is quite different from the concepts enumerated in these standards, however, it has been designed to be compiled into artifacts specified in these industry standards.. How does WSPER relate to other efforts that aim at simplifying the way business logic is expressed?.. We live in a distributed world, there is no single system today that can be build without leveraging other systems in its environment (be it local or remote).. Whether it is data or business logic, or both, systems can be build better without the need to replicate data and business logic that already exist somewhere.. Yet, no programming model today is geared towards describing such systems.. Inter system communication is something that developers have to stitch together.. Programming models provide help at the wire level but not at the system construction level.. Current efforts like spring, SCA or OGSi are geared towards isolating the code from middleware specific APIs but this is not enough because a POJO or a BPEL based model does not have the capability to express the business logic of such systems.. All this goes in the right direction, but there is no programming model today that starts the other way, from the system description.. WSPER is a programming language, how could you possibly claim that it is model driven?.. It seems that somewhere in the late 90s, early 2000s the software community has created an unnecessary dichotomy by introducing model driven concepts and opposing them to code.. In reality, every programming formalism is based on an explicit metamodel (even OO or structured programming of course) and processing instructions.. WSPER is designed as a metamodel where some of the elements are implementable , i.. can be associated to a series of processing instructions, just like a method in the OO metamodel.. Please see the.. for a more detailed discussion on this topic.. copyright 2007 WSPER..

    Original link path: /wsper/wsper/
    Open archive

  • Title: Wag the Dog
    Descriptive info: Digg.. DZone.. Furl.. Reddit.. Subscribe in a reader.. 09/16/08 :: [REST] Wag the Dog.. [.. permalink.. ].. Everyone who knows me, knows that I am not a WS-* guy.. So it is a bit odd to take the stand and defend a technology that I find attractive only because we can fix it and we should not spend the energy to reinvent the wheel.. As an introduction to this second response to Stu, I would like to state a strong belief.. I would like to state the belief that our industry has delivered all but sloppy technologies over the last 15 years: they barely help you do your job, and vastly useless or buggy or both until version 5.. 0, without a clear upgrade path in between and subject to change any day, even though they were never built for change.. I don't want to overly criticize anyone here, this is probably a side effect of a very innovative space.. I am pretty sure that people in BioTech could say the same.. I just would like to see people reflect on the effect of an ever changing sloppy landscape on people building and maintaining solutions.. Since Tim.. has twitted my previous post.. , he might twitt this one too, so I might give a bit of background.. In this post, I will summarize all the discussions I have had with the RESTifarians and demonstrate that they offer nothing different than what others have offered over the last 15 years.. However, our industry (and our economy) is at a very different point in its lifecycle than it was 15 years ago.. The question I would like to answer is what's going to happen if we Wag the Dog one more time in this context? What I mean by Wag the Dog is paint a pretty picture of a technology that end up being just another sloppy, useless, buggy, without a clear upgrade path technology? Can IT withstand it? can the business withstand it or have any patience for it?.. The thesis that I will defend here is that technologies such as WS-*, SCA, BPEL.. are good enough, they can be fixed, made more useful, less buggy and stable to the point where they will enable sustainable upgrade paths.. I will demonstrate that the RESTafarians proposal amounts to starting over, to create the exact same thing wasting years in the process and creating possibly a final blow to IT, loosing any and all credibility from the business.. 1.. What is the end goal?.. I don't want to sound to enterprisey here, by the end goal today to create the programming model of connected systems.. A connected system is built from reusable (autonomous) assets, assembled into a solution.. These assets can live within or outside the firewall, within the control of the enterprise or a 3rd party.. The key concepts behind connected systems are federation/assemblies and composition.. 2.. What are the contenders for creating connected systems?.. RESTful HTTP: resource oriented programming model based on the REST architecture style.. MVC: action oriented programming model.. WS-*/SCA: service oriented programming model.. EDA: event-oriented programming model (this is not well defined, please see the great work of.. Udi Dahan.. for an example).. There is probably a few more, but let's assume that we have the 4 main ones.. Each of these programming model rely on endpoints to implement federation/assembly and composition concepts.. As I mentioned in a previous post, they all represent perfectly valid solutions to some classes of problems.. The question is, can one of them make all the other obsolete? My answer is no.. I could argue that the weakest of all is RESTful HTTP, let's see if I can demonstrate that.. None of the other programming models claim an hegemony over connected systems.. 3.. So where does RESTful HTTP comes from?.. Roy Fielding who contributed significantly to the design of the Web standards such as HTTP wrote a Ph.. thesis explaining.. a posteriori.. why the architecture of the Web contributed to the scale that we experience today.. I personally believe every word of his thesis.. Roy has done a remarkable job both before and after his standard work.. But Roy was also very clear, he designed HTTP and REST based on Tim Berners-Lee's requirements:.. What was needed was a way for people to store and structure their own information, whether permanent or ephemeral in nature, such that it could be usable by themselves and others, and to be able to reference and structure the information stored by others so that it would not be necessary for everyone to keep and maintain local copies.. Tim was a scientist at CERN and information is critical to scientists.. I can't imagine what it is to be a Ph.. student today when you can google anything.. I remember when I first entered the physics library at Penn State University.. All the journals were there, decades at a time.. My search engine then, was based on table of content and indexes.. When I was in a Ph.. student in France, we did not even have anything like that and I had to rely on a librarian to help me find and order articles relevant to my research.. Well, we also had current contents (the blogs at the time).. Anyways,.. the Web was never created with the Enterprise, B2B or even connected systems in mind.. The Web was designed as a very basic content management system (without full text search because of obvious federation problems).. Even though it was designed to PUT and DELETE some new and updated content, these features were never really opened to the public for yet obvious security reasons.. Actually they may not have been so obvious after all when we look at the popularity of wikis.. So let's assume that HTTP, the Web and REST were all designed on the foundation of creating a massive, federated content management system.. Boy, was this mission accomplished.. That makes Tim no less than a modern Gutenberg and his influence on the world is no less than the one of Johannes.. But, can a technology that was invented to fulfill the requirements shown above really work beyond what it was designed for? as-is? This is no less than the claim of the RESTafarians.. They are telling us that all the capabilities delivered by RESTful HTTP are enough to build enterprise b2b capable connected systems.. Is this another instance of Dog Wagging or is it true?.. 4.. REST in depth (from the perspective of a connected system).. Connected Agent Boundaries.. REST offers two types of boundaries:.. the resource.. the network authority upon which a particular resource depends on.. In REST, and RESTful HTTP, you interact with a resource and a resource is located within the boundaries of a network authority (a domain or subdomain).. This really does not help much security, monitoring and management as each resource can actually be implemented or stored on a different server.. REST does not support the definition of arbitrary boundaries, it is not even a question of defining an interface other than the RESTful uniform interface, it is really a question of defining things that you can manage, monitor and secure, things that you know when they are down and which impact they have on your business.. Again, Tim's vision of the Web would have never required anything like that (I won't repeat it each time).. = boundaries are inadequate.. Actually this boundary scheme also create an insurmountable problem in the programming model as all resources that participate in the same RESTful connected system need to belong to be dependent on the same network authority.. If you need to post a PO to a customer and both the PO and customer depend on separate network authorities, you are out of luck and you are on your own to stitch the references together.. We know how practical that can be in the SaaS/Web 2.. 0 era.. = boundaries are vastly inadequate.. 2.. Identity.. RESTful HTTP  ...   (Hypermedia is defined by Roy as the presence of application control information embedded within, or.. as a layer above, the presentation of information.. ) work together.. This is truly a marvel of engineering.. Unfortunately it works only when a user is in the loop -above the presentation of information.. A user can make sense of any changes in the actions embedded in the resource representation.. Unfortunately a software agent can generally not do that.. Because die hard RESTafarians refuse to define a contract, then any modification on the server cannot be validated by the client.. So the claim you hear most often by the RESTifarian that the uniform interface helps you make changes on the server without impacting the client is only true when a human is in the loop.. In a connected system this claim is a complete Wag, probably the biggest wag of all and despite all the discussions we could have had, people like John Heintz keep wagging this absolute fallacy.. = REST cannot deal efficiently with modifications on the resource side (the action interface) when the consumer is not a human.. The uniform interface is unidirectional and synchronous.. Best practices of connected system construction require a bidirectional interface representing interactions between resources and asynchrony.. = REST is missing fundamental connected system interaction patterns.. The uniform interface cannot support events.. = REST's uniform interface was never design to create notifications of particular occurrences of a state.. Last but not least, one of the biggest problem of resource orientation in the enterprise is that none of the legacy systems are resource oriented.. If you layer a resource oriented access on top of these legacy systems (the resources have to live somewhere right?) then you are going to experience a terrible mismatch between this resource oriented access and the way these systems operate.. O/R mapping is going to look simple in comparison.. You can trade this mismatch for mashup flexibility for instance, but mashing up is only a small part of connected systems.. = Resource orientation does not work well with legacy systems.. 5.. Security.. REST does not offer any federated security mechanism, including no support for user identity propagation which is essential in Enterprise system construction.. You need an envelope mechanism to support identity propagation and REST is using APP (a non extensible envelope mechanism).. = REST security infrastructure is vastly incomplete to support connected systems.. I'll let REST get away with Transaction and Reliability but they can't support that either.. 6 Caching.. Lots of RESTafarians are prompt to point that REST enables caching.. Yes, the Web needs caching and offers lots of opportunities to use caching.. In the enterprise the story is far less compelling.. Entity Beans tried to deliver a caching engine to enterprise data without any success.. Enterprise data simply does not cache well.. = Caching is useless for enterprise data.. 7.. REST from the perspective of BPM.. REST programming model is incompatible with BPM.. User activities need to be implemented with a proprietary mechanism and because of it's lack of bidirectional interfaces REST cannot support events or orchestration components used for instance to manage the resource lifecycle in a business process.. = REST is going to set BPM 10 years back.. Where do we go from here?.. The conclusion is that REST has only two dimensions to express application semantics: URIs and Media Types, this is not enough.. Whatever tricks the RESTafarians will come up with, they will be never enough room there.. So, I hope everyone is convinced by now that the RESTafarians are wagging the (IT) dog by what's left of the tail.. Their claims are far stretched if not plain wrong.. Nothing that I said in the.. REST fallacies.. post proved to be wrong:.. Yes, I agree there are.. a lot of interesting concepts in REST.. that can be reused when building connected systems, but at the end of the day, REST.. alone.. cannot drive IT where it needs to be (nor WS-* or SCA or EDA).. IT needs a programming model where resources, processes, events, (inter)actions and services are exposed as primary concepts rather than reified behind a single one.. The era of Everything is a XXX is gone (where XXX is: resource, process, service, event.. This approach has been a dead end each time someone came out with such monolithic programming model.. You just can't reify some concepts behind others, just because you are Turing complete.. Turing is no match for this kind of job (.. metamodel driven programming.. ).. to show how these concepts can fit in a programming model.. So, Stu, it is probably time to move forward, none of these arguments will change until you create REST-*.. I hope that you will agree with me that, indeed, the fundamentals of IT are not strong enough to sustain another wagging the dog wave.. Maybe we could agree that delivering.. sloppy technologies, that barely help you do your job, and vastly useless or buggy or both until version 5.. 0, without a clear upgrade path.. is the reason why IT cannot do its job.. The (other) REST is no different.. Nice try guys, you say look this works for the Web, it is well-formed, stable, not buggy, useful , but this is only true in the Web.. In the Enterprise your statement is fallacious and frankly ludicrous, you will have to recreate REST-* and REST-* is sloppy to say the least.. Steve, in the most ironic fashion, REST could prove to be a disruptive technology, but in the way that was never predicted by Clayton Christensen, REST, as yet another.. technology is about to transform consumers into non-consumers, because you see, if IT can't deliver value, it won't get any money and be pair down to keep the light on, giving its true meaning to IT as a utility.. Stu, you may also agree that at this point creating communities that conflict with each other is not going to solve any problem.. We need a Willy Brandt that will reach out across the iron curtain and stop this nonsense.. Hopefully architects, like me, have now enough material to go back to their management and put the (other) REST to rest.. Jean-Jacques Dubray, September 16, 2008.. References.. Stefan on REST.. The REST fallacies.. and.. Yet another REST fallacy.. Bill de Hora's Response.. my response.. What a strange debate.. Bill de Hora complains about RESTfaces.. REST, resources, lifecycles and actions.. REST processes and resource.. WADL metamodel.. Uniform interfaces and application semantics.. Not even a scratch.. REST and search.. An answer for Sergey.. The very dark side or REST.. REST creates strong coupling.. REST and interactions.. The 10 questions a solutions should ask himself before using REST.. A Question of Style.. Interaction Definition Language.. The Myth of the Uniform Interface is Gone.. Drawing some Conclusions.. Understanding SOA.. WSDL sucks deeply and totally.. Interaction DLS and PLS.. Spaghetti Oriented Architecture.. Trans-action and composition.. SCA Rocks.. Saas: CRUD-oriented Architecture?.. (II).. REST: CRUD oriented architecture.. SCA and JBI bring nothing to the table.. What's great about REST.. REST easy.. WOA the future of SOA.. Loose coupling.. cohesion.. cohesive response.. ) +.. What is Cohesive in SOA.. Is SOA about building distributed systems?.. SOA Data Services.. Roy's POST.. Open letter to the (other) REST community.. answer to my letter.. Versioning.. Stefan and Teo answer my questions.. The fundamental achievement of SOA.. Web Services is an RPC-oriented technology.. Architecture of a $7 Billion dollar loss.. See it for yourself.. Full circle.. The remoting bunch.. Remoting is dead.. The real face of REST.. REST is a fraud and everyone knows it.. Programming models matter.. Protocol Bufffers.. Stu's response.. Here we go again.. What the remoting bunch will never understand.. Designing RESTful Rails applications.. Damien Katz on REST.. IT's Silver Bullet.. What's missing in REST.. SOA is a failure.. The RESTafarian Dilemma.. Come on.. Accidental programming.. A question of Style.. The Restpolitik.. copyright © 2001-2008 ebpml.. org | com.. GMAIL.. @J.. DUbray |.. design by.. DCARTER |.. HaloScan..

    Original link path: /blog/136.htm
    Open archive





  • Archived pages: 467