Anthony Bradley

A member of the Gartner Blog Network

Anthony J. Bradley
GVP
3 years at Gartner
19 years in IT

Anthony J. Bradley is a group vice president in Gartner Research, managing teams that cover business process management, project and portfolio management, enterprise architecture, IT procurement, IT sourcing, and vendor management. Read Full Bio

Coverage Areas:

OMA and the Importance of Standards in Enterprise Mashups

by Anthony J. Bradley  |  October 2, 2009  |  12 Comments

Last week JackBe announced the formation of the Open Mashup Alliance to support an XML-extension specification called EMML (Enterprise Mashup Markup Language). JackBe is a leading boutique mashup platform vendor and EMML is their mashup language. They are the only ones using it now but they have “donated” it to the cause of mashup executable standards. A nice post by Dion Hinchcliffe gives a great summary of the OMA effort. It should be noted that, as of yet, there is no open spec alternative to OMA/EMML for mashup portability.

OMA is a noble effort. The primary benefit to enterprises if EMML gains support comes in the form of mashup portability. This means that if I build a mashup or mashable using EMML then I can run it more easily in any other mashup vendor technology environment that supports EMML. Currently, if you build a mashable using Serena it won’t run in a JackBe environment and vice versa. This creates vendor lock-in which, as you can imagine, vendors don’t mind so much. But especially in an emerging technology market like mashups, it can scare buyers off the effort. And it definitely makes them think twice about a smaller boutique vendor like JackBe. If EMML adoption takes off it will be good for buyers and good for boutiques.

It should come as no surprise that the megavendors (IBM, Microsoft, Oracle) are not members of OMA. What does this mean? It definitely makes adoption more challenging. It also puts the onus on you, the mashup technology buyer. Is mashup portability important to you? OMA/EMML gives buyers a good opportunity to ask vendors about their mashup standards strategy. If not EMML, then what?

Gartner just published a report on this topic entitled “Open Mashup Alliance Needs More Support to Create Standardization” (available to the general public).

12 Comments »

Category: Uncategorized     Tags:

12 responses so far ↓

  • 1 Tweets that mention OMA and the Importance of Standards in Enterprise Mashups -- Topsy.com   October 5, 2009 at 12:58 pm

    [...] This post was mentioned on Twitter by Mancilla. Mancilla said: If not EMML, then what? … http://bit.ly/hSgBX [...]

  • 2 Patrick Logan   October 5, 2009 at 7:29 pm

    “if I build a mashup or mashable using EMML then I can run it more easily in any other mashup vendor technology environment that supports EMML.”

    There aren’t many of these. OTOH if you make resources available as html or json then there are a whole slew of tools that can mashup those.

    i.e. EMML is a misguided implementation language, not a “mashup” language.

    Don’t hurt the web!

  • 3 Anthony Bradley   October 6, 2009 at 9:39 am

    Patrick,

    You bring up a good point for clarification. There are differences between mashup enablement, mashup interoperability and mashup portability. You are talking about mashup enablement which is the act of making a systems capability (data, logic, presentation) available for mashing. Absolutely, the basic Web standards (RSS, JSON, XML, XHTML) are what makes a resource mashable. But those standards do not enable mashup portability or interoperability. More needs to be done. Extensions to XML, like EMML, don’t hurt the web. They can evolve the Web as long as they don’t break the principles of the WWW vol1 and RESTful design. Of course they only evolve the Web if they become widely adopted. If they don’t, then they are too insignificant to hurt anything.

  • 4 Deepak Alur   October 7, 2009 at 2:24 am

    Patrick,
    Thanks for your comments. But, reading from your brief comments, I think you are misunderstanding the intent of EMML, what it is, and how it relates to HTML/JSON. EMML in no way hurts or displaces HTML/JSON. Are you by any chance thinking of EMML as mashups on the client (browser), hence your confusion with HTML/JSON? EMML does not aim to replace mashups on the client which you are probably going to perform using a combination of JavaScript/JSON/HTML/…

    With EMML, we are talking about server-side mashups. The question EMML addresses is how do you define, declare and execute a mashup; a mashup that mashes HTML/JSON sources that you mention and also mash other data coming from different enterprises data sources such as databases, web services (WSDL and REST based), XML files, RSS feeds, and so forth.

    No one is advocating that EMML replaces HTML/JSON in any way. EMML is not a general purpose language. EMML is not a client-side mashup language. I wrote about what EMML is in my blog, hopefully it clarifies what it is targeted for: http://blogs.jackbe.com/2009/09/omg-we-launched-oma-and-emml.html

    Once you review my blog, and also review the language itself (see complete documentation here: http://www.openmashup.org/omadocs/v1.0/index.html), and perhaps trying it yourself using the reference implementation provided there (see http://www.openmashup.org), I would really be interested to know what exactly you mean by ‘misguided implementation language’.

  • 5 Patrick Logan   October 7, 2009 at 12:48 pm

    “Extensions to XML, like EMML, don’t hurt the web.”

    I think you’re right. That was too dramatic. I do think EMML *distracts* from the web though. i.e. there are two things necessary for enterprise mashups…

    (1) making good information available with “back office” machinery

    (2) making that good information available to as many consumers as possible with as low friction as possible

    Step (1) is just good information/data management/quality/availability

    Step (2) is putting a good web infrastructure around that good data

    The EMML spec seems to be addressing some of both, but I think there are better tools for each. EMML kind of confuses by playing in the middle of (1) and (2) and although it is “open” it is also an unnecessary element. Current web standards and practices work better than EMML for (2) and current “back office” systems and languages work better than EMML for (1).

    I’m having trouble seeing how EMML makes either (1) or (2) better, and I am having trouble seeing anything other than (1) and (2) being necessary and sufficient for enterprise mashups.

  • 6 Deepak Alur   October 8, 2009 at 2:01 am

    Patrick,
    Not sure what you mean by “back office” machinery. I would ideally like to understand the specifics from you before responding, but based on the above comments, here are my thoughts.

    If (1), the “back office” machinery, provides good data/information and (2), a good “infrastructure”, provides ways (interfaces/methods) to access to that data/information, where do you propose mashups should manifest (create, deploy, run, use, etc.)?

    IMO, given that the agile, quick assembly/change, user specific needs that mashups address, putting it in back office machinery is too distant from the user and the applications that use that data (e.g. business units). Putting it in the infrastructure is too rigid since you don’t want the infrastructure to change constantly as business / user needs keep changing. In other words, what we need is a layer that characterizes the dynamic synthesis of information by mashing up the data in your (1), exposed via interfaces in your (2). So, the mashup layer is probably best situated between the presentation layer and the business/data/integration layer. See this (dated – year old) blog post where I show a picture of “introducing” a mashup layer in the architecture (http://blogs.jackbe.com/2008/11/mashups-new-and-agile-way-to-integrate.html). This new middle layer (mashup layer) is composed of mashups, which represents a thin layer of mashup objects that are dynamic, user oriented, easy to assemble/change, and secure/governed by the enterprise.

    Also, in a SOA Magazine article titled “Enterprise Mashups: Bringing SOA to the People” (http://www.soamag.com/I18/0508-1.asp), the authors talk about enterprise mashups; see the section titled “But I can do that with my… “, which I am thinking addresses your comments that you can do all that (mashups) with (1), “back office machinery”, and (2), “infrastructure”.

    Assuming you agree that there is a need for server-side mashups / mashup layer, the next set of questions are:
    1. How do we define and implement a mashup?
    2. How do we deploy a mashup?
    3. How do we change / modify a mashup ?

    Now, when you say that “current web standards and practices work better than EMML”, I am assuming you are talking about using conventional methods of programming with your favorite language (e.g. Java, C#, Python, Ruby, etc.). Can you implement a mashup using these languages? Yes, of course.

    Now add some more questions/considerations:
    A. How can we do all of the above quickly and dynamically (at runtime or mashup time)?
    B. What is the cost (time/effort) of creating a mashup?
    C. What is the cost (time/effort) of modifying a mashup?
    D. What skills do you need to create a mashup?
    E. How do we tool the above processes?
    F. How do we make these mashups interoperable and portable across different runtime environments?

    You will start seeing varying mileage depending on your choices. The disadvantages of doing mashups on the server-side with conventional approaches start piling up.

    This is the whole reason EMML was created, to provide a dynamic and declarative approach to defining, implementing, deploying and securing mashups by means of a relatively simple XML-based language, so that it is tooling friendly (hence XML-based), standards-based (i.e. uses XML, XPath, XQuery, XSLT, and so forth), and general purpose language friendly (e.g. you can embed Java, JavaScript, Ruby, etc. for procedural processing inside a mashup). One can envision soon we will have DSLs based on EMML implemented in other languages such as Ruby, Java, Groovy, etc. to make it even more easier for folks who don’t want an XML-based approach.

  • 7 Alexi   October 8, 2009 at 9:19 am

    Patric,

    I think you are right EMML does not address 1 and 2. It is not its goal.

    But 1 and 2 does not give you a “mashup”. 1 and 2 is just a give you a data which you can use to produce “mashup”. In other words 1 and 2 are preconditions to be able to build mashups.

    This is what EMML is for – language to define your mashup logic. Given that 1 and 2 already happen and data is available, you can use EMML to “combine” this data and services and derive new data and services (produce mashup).

    So I think you are missing the point of EMML, it does not “distract” from any existing web technologies. EMML leverage web technologies and builds on top of them

    Regards, Alexi

  • 8 Patrick Logan   October 9, 2009 at 9:07 am

    (How does that go? “I apologize for the length. If I had time, I would have written a shorter response.” :)

    “Not sure what you mean by “back office” machinery.”

    I mean all the databases, apps, services, etc. that are running
    today behind an enterprise’s current user-facing applications.

    “where do you propose mashups should manifest (create, deploy,
    run, use, etc.)?”

    There should be very few exceptions to the rule that all data to
    be “mashed” would be provided via an HTTP server using a
    widely-consumable format like HTML, JSON, RSS, Atom, and standard
    RDF formats (RDF/XML, Turtle, N-triples). The rare exceptions
    should be common formats as well, e.g. CSV, Office XML, etc.

    In other words, SQL, etc. via transactions, and SOAP calls should
    be relegated to the back office. They are difficult to consume
    and they only propogate legacy dependencies further around the
    enterprise. The web’s HTTP protocol and common formats are an
    abstraction barrier to isolate the new world of mashups from the
    old back office that simply must be much more isolated than it
    tends to be in current data centers, in order to evolve.

    EMML promotes the legacy of yesterday up into the mashup
    notation, which is one of its worse faults. IT is a logjam of
    systems that can never go away because everything in the data
    center depends on them. That is difficult enough, before
    embedding them further in a mashup notation for all future web
    systems.

    “putting [mashups] in back office machinery is too distant”

    Yes, agreed. Mashups come from “up front” as in my paragraph
    above. The back office machinery is needed to get good data up to
    the web servers in a timely and correct manner.

    “what we need is a layer that characterizes the dynamic synthesis
    of information by mashing up the data… the mashup layer is
    probably best situated between the presentation layer and the
    business/data/integration layer”

    Yes, and that’s (2) in my previous comment, i.e. it is the web
    using garden-variety web infrastructure and formats. That’s
    worked out in the wild, it’s worked to some extent inside the
    enterprise already, and it’s what everyone in the world knows and
    uses successfully. No need for EMML.

    “See this (dated – year old) blog post where I show a picture of
    “introducing” a mashup layer in the
    architecture (http://blogs.jackbe.com/2008/11/mashups-new-and-agile-way-to-integrate.html). This
    new middle layer (mashup layer) is composed of mashups”

    I agree with the picture, but I disagree that EMML is a necessary
    ingredient. The whole idea of a good “REST” style HTTP
    architecture is that good data over HTTP using common formats can
    be “mashed up” on servers as well as in browsers and other
    clients. i.e. web servers can also be web clients. Consider blog
    aggregators, as well as more general capabilities like “yahoo
    pipes” – these take web content and make new, combined web
    content – with common HTTP and web formats.

    Yahoo Pipes is a good comparison with EMML. Pipes take in data
    sources that are already web-based, and produces web-based
    mashups. If EMML did only this, I for one would be much more
    favorable toward EMML.

    “a thin layer of mashup objects that are dynamic, user oriented,
    easy to assemble/change, and secure/governed by the enterprise”

    This can be done more profitably using only the web, as I’ve
    repeated probably too many times here already. To reemphasize,
    the “easy to assemble/change” will not come from EMML per
    se. Significant changes in the back office data quality,
    information management, an availability will far and away be the
    greatest key and the most effort needed to make mashups
    successful. Otherwise mashups will at best be propogating bad
    data based on legacy structures and values, that few people
    understand.

    “in a SOA Magazine article titled “Enterprise Mashups: Bringing
    SOA to the People” (http://www.soamag.com/I18/0508-1.asp)… see
    the section titled “But I can do that with my… “, which I am
    thinking addresses your comments that you can do all
    that (mashups) with (1), “back office machinery”, and (2),
    “infrastructure”.”

    That seems like a pretty good article, but I don’t see EMML as
    the solution. Most back offices are in no way ready to support
    data for good mashups, I agree. The solution is to improve good
    data availability in the back office and make it available over
    the (intra-)web in common formats. That is a huge undertaking in
    order to do it well, something most IT shops don’t realize, or
    push off into the future.

    “Assuming you agree that there is a need for server-side mashups
    / mashup layer…”

    Yes.

    “1. How do we define and implement a mashup?”

    a. identify initially narrow sources of data that would be
    useful.

    b. take the steps necessary to make it clean, well-defined,
    available, and independent of specific source-system legacy
    values, etc.

    c. take the steps necessary to make that data available over HTTP
    using common web tools and appropriate common formats, supporting
    good lifetime information, etc. in headers, and so on.

    d. repeat (c) for server-side mashups by consuming multiple data
    sources (i.e. specific subject area data) via their *web*
    interfaces only. Make this mashed-up data available as well
    through URLs using common formats over web servers.

    e. Do not go to the underlying databases, services, or apps
    directly from the server-side mashup. (The possible exceptions
    are mashups that are contained within one subject area,
    e.g. Sales, could go directly to Sale back office systems, but
    that should be discouraged as much as possible, and should
    *never* take place across subject area boundaries, e.g. Sales
    going directly to Product’s back office systems.

    “2. How do we deploy a mashup?”

    A server-side mashup is deployed as a RESTful web system using
    common formats and protocols, and conventional web practices (web
    security, web proxying, etc.)

    “3. How do we change / modify a mashup?”

    Server-side mashups should use common web development tools,
    e.g. ruby, PHP, javascript, and so on that nearly every developer
    knows or can pick-up on quick notice. Then with a well-structured
    architecture from back-to-front as listed above, make the
    appropriate changes and redeployments in their respective
    components.

    “Now, when you say that “current web standards and practices work
    better than EMML”, I am assuming you are talking about using
    conventional methods of programming with your favorite
    language… Yes, of course.”

    Correct.

    “A. How can we do all of the above quickly and dynamically (at
    runtime or mashup time)?”

    Within the enterprise there is typically a *lot* of legwork
    needed to make good data clean, available, and
    well-defined. That’s the biggest chunk of work required whether
    EMML is in the picture or not.

    Doing things quickly and dynamically above and beyond that has
    been demonstrated very well by web development teams around the
    world. When good data is available over the web, people do not
    find it at all difficult to manipulate server-side or
    browser-side.

    “B. What is the cost (time/effort) of creating a mashup?”

    The greatest cost by far will be the usual data
    quality/availability work that most IT shops should be doing
    anyway, but often do not.

    “C. What is the cost (time/effort) of modifying a mashup?”

    Assuming (B) is in place as I described in more detail above,
    then the cost of modifying a mashup should be very small indeed -
    ideally proportional to the change in business
    requirements. Otherwise the cost tends to be very large indeed -
    proportional to the number of groups that need to be coordinated,
    budgeted, allocated plus proportional to the obscurity of the
    legacy systems and lack of available definition of how good that
    data is.

    “D. What skills do you need to create a mashup?”

    Again assuming the architecture above, mashup skills are those of
    any good web server-side and/or client-side developer’s. Plus
    enough domain knowledge to understand what are hopefully good
    descriptions of what that data “means” to the enterprise.

    “E. How do we tool the above processes?”

    For just the server-side mashups, there should not be much more
    than the garden-variety web tools in place today all over the
    world. That’s the beauty of using the web and putting everything
    on the web.

    Isolation from idiosynchratice, anachronistic legacy bad stuff
    can be isolated, and eventually replaced. The tough slogging to
    get there has nothing to do with the web or mashups.

    “F. How do we make these mashups interoperable and portable
    across different runtime environments?”

    The web.

    “The disadvantages of doing mashups on the server-side with
    conventional approaches start piling up.”

    I’m not aware of what those disadvantages might be, if things are
    as well-structured as listed above. I am not saying it will be
    easy for the typical IT shop, but I don’t see how EMML makes that
    effort any easier or better in the long-run.

    “This is the whole reason EMML was created… tooling
    friendly (hence XML-based), standards-based (i.e. uses XML,
    XPath, XQuery, XSLT, and so forth), and general purpose language
    friendly (e.g. you can embed Java, JavaScript, Ruby, etc. for
    procedural processing inside a mashup). One can envision soon we
    will have DSLs based on EMML implemented in other languages such
    as Ruby, Java, Groovy, etc. to make it even more easier for folks
    who don’t want an XML-based approach.”

    Some people may like that. I don’t think EMML is addressing the
    real effort, and don’t see the need for it. Compared to the
    knowledge already available for doing web work using current
    tools, I don’t think there will be a large market of available
    EMML expertise any time soon, nor do I see a growth path to get
    to that pool of expertise. I could be wrong, but I think it is a
    diversion from what’s really needed to leverage in-house the
    successful approaches to mashups on the internet generally.

    I think there is room for better tools, etc. but I don’t think
    EMML is it, as it stands.

  • 9 Patrick Logan   October 9, 2009 at 9:11 am

    Hi Alexi,

    “I think you are right EMML does not address 1 and 2. It is not
    its goal. …But 1 and 2 does not give you a “mashup”. 1 and 2 is just a give you a data which you can use to produce “mashup”. In other words 1 and 2 are preconditions to be able to build mashups.”

    Yes, I agree.

    “This is what EMML is for – language to define your mashup
    logic. Given that 1 and 2 already happen and data is available,
    you can use EMML to “combine” this data and services and derive
    new data and services (produce mashup). So I think you are
    missing the point of EMML, it does not “distract” from any
    existing web technologies. EMML leverage web technologies and
    builds on top of them”

    Yes, I can see this point. But then my question becomes: once you
    have (1) and (2) why do you need EMML?

    Certainly in my experience (1) is 80 percent of the problem and
    effort. And (2) is just “good web practices”. Then…

    (3) build and maintain server-side and client-side enterprise
    mashups

    …just becomes “build on the web using the web” using common web
    tools and languages.

    EMML has some good things in it, but it also has some terrible
    things in it (e.g. transactions, SQL, etc.) all that back-office
    stuff that distracts from truly doing the work of (1) back-office
    readiness.

    As with SOA, so with EMML, there is an implicit assumption that
    all you need is access to the bad data currently in the
    enterprise. That *data* iss the true problem inhibiting mashups.

  • 10 Anthony Bradley   October 9, 2009 at 2:39 pm

    Availability of good mashable enterprise capabilties (data expecially) is indeed a problem.

  • 11 Alexi   October 9, 2009 at 3:04 pm

    Patric,

    I am glad that we agree that, to make meaningful data available is a difficult problem and is a precondition to be able to produce mashups.

    Lets leave this problem aside since we also agree that this problem exists does not matter what tools you use to build mashups ,EMML or others.

    If we leave data problem aside, essentially it boils down to “…why do you need EMML? ” , when one can just ““build on the web using the web” using common web tools and languages.”

    I assume you mean why can you just use a programming language Perl, Python, Java … to express mashup logic.

    I think Deepak already answered this question in his post, but let me try to answer it again in my own way.

    The general answer is “yes you can”, but if it will be the most optimal way of doing things depends on particular situation.

    If you a developer who develops an application certainly you can just use language of your choice. But what if you are relatively not technical user tries to quickly combine/mashup data from different sources ?

    What if the vendors like JackBe or Yahoo (Yahoo Pipes) want to provide a graphical environment for rapid mashup building ? I argue that for those porposes EMML is much better language, because it is a DSL for domain of capturing mashup logic.

    In other words EMML is a DSL for creating mashups and as such it is much more efficient to write mashup in EMML then in C for example.

    The same way as make or Ant is a DSL for defining build logic.
    If we follow your arguments we can say “why we need Ant or make we can just use C or Perl to implement our build processes”. Yes you can use C to implement a build, but nobody does it, because it is wrong tool for a job. Even if you are C developer.

    Regarding

    “EMML has some good things in it, but it also has some terrible
    things in it (e.g. transactions, SQL, etc.) all that back-office
    stuff that distracts from truly doing the work of (1) back-office
    readiness.”

    Like with any other language, different people will have features they like and features they hate. Every person or organization can choose a subset of language they are comfortable with. So if you don’t like to access your RDBMS from mashup layer, then don’t use this feature, use other “good things” which EMML has. Obviously you have to be lucky enough to have all your data nicely exposed as some sort of services.

    Unfortunately we can talk as much as we want about “back office reediness” and availability of the data through nice service tier, but reality is that we are talking about SOA for years and yet there is still tons of data which not available as services. The only way to get at this data is using SQL. The business people in the enterprise want to use the data and don’t want to wait until they become available as services. So we can either take a academic approach of “you get this data when we come up with nice service tier” or we can address business need for rapid situational apps(which mashups are by definition) with feature which allows a user to get at data in SQL store.

    In summary, if you have all your data exposed as services then don’t use SQL in EMML, but if you need and want to access data from RDBMS then this feature is there.

    With respect

    “As with SOA, so with EMML, there is an implicit assumption that
    all you need is access to the bad data currently in the
    enterprise. That *data* iss the true problem inhibiting mashups.”

    You are making this assumption not EMML. EMML can consume data from various sources. It does not make any assumption about data quality. If data is junk then mashup will be a junk. The same way as you were doing mashup with Perl or Python.
    Again data problem is orthogonal to EMML.

    Regards, Alexi

  • 12 Patrick Logan   October 9, 2009 at 9:24 pm

    Alexi – fair enough, I see your points re:

    “Every person or organization can choose a subset of language they are comfortable with.”

    “reality is that we are talking about SOA for years and yet there is still tons of data which not available as services”

    “You are making this assumption not EMML”

    Thanks
    -Patrick

Leave a Comment