Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Expo on Google News
SYS-CON.TV
Cloud Expo & Virtualization 2009 East
PLATINUM SPONSORS:
IBM
Smarter Business Solutions Through Dynamic Infrastructure
IBM
Smarter Insights: How the CIO Becomes a Hero Again
Microsoft
Windows Azure
GOLD SPONSORS:
Appsense
Why VDI?
CA
Maximizing the Business Value of Virtualization in Enterprise and Cloud Computing Environments
ExactTarget
Messaging in the Cloud - Email, SMS and Voice
Freedom OSS
Stairway to the Cloud
Sun
Sun's Incubation Platform: Helping Startups Serve the Enterprise
POWER PANELS:
Cloud Computing & Enterprise IT: Cost & Operational Benefits
How and Why is a Flexible IT Infrastructure the Key To the Future?
Click For 2008 West
Event Webcasts
Flashback: The End of Middleware – Exclusive 2004 Perspective by Sun President, Jonathan Schwartz
Schwartz Explains Why He Believes That Middleware is History

  • JDJ's "2004 Predictions by i-Technology Leaders" Feature Story
  • "Offshore Outsourcing" by Jack Martin
  • From the Founding Editor by Steve Benfield
  • "HP's Problem Ain't the SAP Install," Says Sun's Schwartz

      The marketplace tells you that "middleware is everywhere" when all along it should wise up and recognize that "middleware is dead." Because that's the new reality of enterprise computing today, according to Sun's president & CEO Jonathan Schwartz.

      What's more important: Running your business or integrating middleware?

      Should be an obvious answer, right?

      Then why is the marketplace spending so much energy wallowing in the history of "middleware is everywhere"? Habit. A habit to which thousands of IT professionals devote their lives. But integrating middleware to build one-off business systems is about to perish with the rise of shared services - the services you'd like to build once, then execute on behalf of all your business systems.

      As an example, when's the last time you hired someone? Remember what it was like getting them "badged" and into the company? You had to grant them access to payroll, benefits, a desktop login, e-mail, the CRM, and forecasting systems, then assign them an office and a phone.

      Most likely, your company built a unique provisioning mechanism for each of the systems I just cited. One for HR, one for the sales force, one for information security, and yet another for physical security. And then you likely created even more redundancy by building one set for your intranet employees and another for your Internet customer or supplier systems. That's inefficient, and in the world of Sarbanes-Oxley, a real problem - who has access to what? And why did you build 17 different systems?

      Because it looked like a good idea at the time.

      The same is true for most services that now make far more sense in a shared environment, from portals (how many does your company have?), to e-mail and application services, down to clustering and Web servers. There's no real utility in having multiples of these services, as Nicholas Carr would point out, where your implementation doesn't generate a competitive advantage. How you authenticate users and provision them with access to your systems is an unlikely competitive advantage. So why build a one-off solution instead of relying on an integrated system?

      Good question.

      Our belief is that the vast majority of Web services are better run as shared services. What's the holdup, then? When we looked into this a year ago, we found three challenges:

      1.  Roadmap sprawl
      There's no coordinating force causing all the required elements of shared services (from authentication to portals, Web services to clustering) to coalesce around a common release, interoperability, or support matrix. So you have no choice but to build your own.

      2.  Pricing
      Middleware pricing is anything but shared - per CPU, per identity, per mailbox, per portal, per cluster node - pricing opacity obscures the real savings in running shared services. And if you can figure it out, you probably can't afford them.

      3.  Licensing
      The industry relies on "common access licenses," often tripling prices for services that touch the Internet - that's clearly an obstacle to shared services.

      So here's how we solved the problems:

      1.  The rise of Sun's Java Enterprise System
      Sun's Java Enterprise System offers all the basic components, from directory and identity management to Web services, even e-mail and clustering. All in a single deliverable, prequalified, tested, and supported on multiple platforms.

      2.  Pricing goes to a $100/employee subscription
      Why buy software differently than how you buy office furniture - by the employee? If your workforce decreases, you pay less, and vice versa. The ultimate in predictable, transparent pricing.

      3.  Licensing - infinite RTU
      If the distinction between the intranet and extranet is disappearing, so should the distinction in our licensing. So $100/employee buys you the right to use (RTU) all these services on all systems. At infinite scale - once you've paid for your employees, your customers are free. Free. It's your software.

      The vendors who believe hardware is commoditizing suggest the same forces won't affect software. We believe it affects both.

      And as the world moves to recognize the value of a shared services infrastructure, it's our belief that middleware is history. Long live the system. The Java Enterprise System.

    • About Jonathan Schwartz
      Jonathan Schwartz is president and chief operating officer of Sun Microsystems. In this role he is responsible for operations and execution of Sun's day-to-day business including Systems, Software, Global Sales Operations, worldwide manufacturing and purchasing, customer advocacy and worldwide marketing. Prior to this position, he served as EVP of Sun's software group where he was responsible for the company's software technologies and business. While in this position, he revolutionized Sun's software strategy with the introduction of the Java System, an innovative collection of highly integrated software for the development, deployment and operation of Java technologies.

      In order to post a comment you need to be registered and logged in.

      Register | Sign-in

      Reader Feedback: Page 1 of 4

      Total Trash! At the very least, the guy could write a few paragraphs outlining why it is dead, instead of saying "its too expensive" so buy our crap. I expect more from JDJ than this, maybe I shouldn''t.

      The best Sun can do to follow BEA Systems, Gartner Group and IBM vision on Application Platform Suites and SOA.
      But it is nstill ot enough to catch the front runners.

      Several respondents picked up on this immediately: Another thinly disguised (if it were disguised at all) sales pitch, with a direct attack against IBM.

      What "Jonathon" fails to recognize is that it is crazy (cost prohibitive) to rip and replace legacy systems. Oracle pitches a similar message (one source - Oracle), I think. A company who does that risks its own demise: while they spend money rearchitecting existing processes and functionality, their competition will push them into oblivion.

      Web Services is one of the many keys to the future, along with information integration (both EAI and EII). Middleware helps make that happen.

      jackprogrammer: If you can write a program to generate marketing hype, I am not sure if you are a genius or sick...

      A catchy title yes but what you are offering is just your own middleware with Sun branding. In short a sales pitch for your own product. Lame. Joining the party rather late don''t you think? A dollar short and a day late. Must have read those briefs by Gartner that this area of the market is hot!

      This is just another sales pitch for the newest fashionable abstraction. And those web services, what do they run behind the scenes, if not middleware ?

      This is really useful stuff for all of us Java programmers. Please give me more! and more! Long Live the Schwartz! I think I could write a program to generate this sort of garbage.

      Hello John,

      Yes, the lack of Canonicals costs me far more in up-front integration effort than differences in format and protocol. Couldn''t agree more. It''s amazing that format and protocol get so much of the SOA discussion bandwidth.

      But if the challenges in establishing Canonicals were mostly technical, I wouldn''t still today be having semantics discussions with EDI trading partners. How long will it take for semantic (not technical) conformance to emerge? Recent experience with UCCnet is making me think this (the semantics, not the mechanism/technology) is much harder than most people thought.

      Regards.

      Mr. Rosenthal -
      Yep, I work a few levels under Tony Scott. So regarding decoupling the semantics from the app that creates it... Take an example of the UDEF ID''s being assigned to each data element in a schema, or each data element in an RDF taxonomy. This exists as an online resource, and there would be resolver services on the wire to perform lookups and transforms in real time. By the way, an example UDEF ID appears as d.t.2_8, which is literally translated as purchase.order.document_identifier. So the ID is an attribute of the actual data element.

      Then consider an approach like the new Content Assembly Mechanism (CAM) TC in OASIS to actually compose the content.

      Using common, or Canonical, based formats like OAGIS, we can achieve real human-free integration, where the formats are well defined, and all data elements are labeled with UDEF IDs.

      See more on the CAM, OAGIS and NIST proposal for a Proof of Concept at the udef.builders discussion group. http://www.topica.com/lists/udef.builders/read

      john

      Hello Yadi,

      If shared services through standard protocol and formatting make creating point-to-point connections between applications easier, than I submit they are evil.

      If in a few years, a shared service is replaced with another which has somewhat different content and semantics, then each and every application that was coded to directly use that service may need to adapt. In an environment with a large number of point-to-point connections between shared services, the arithmetic of change becomes absolutely frightening. Inter-application "spaghetti" is not a result of multiple protocols and formats or even semantics, it''s a result of multiple point-to-point application connections.

      If I had to make a choice between point-to-point shared services versus hub-and-spoke messaging through proprietary interfaces, I''d choose hub-and-spoke every time.

      Fortunately there is no need for such a choice. Shared services will just make the job of connecting services to my middleware layer easier.

      Regards.

      John, Huy and all other dear readers and software engineers:

      I strongly believe the whole problem with the article is in the different interpretations of the word middleware. Mr. Schwartz is referring to middleware as opposite of shared service. I understood what he means by middleware is really repeated, un-sharable, scattered services that are floating in an enterprise. If this is what he is referring to then he really has to fix the terminology. And if he is referring to such services, I agree with that. The age of un-shareable services has come to an end.

      But what is next. SOA techniques have not really matured to a level that we can say SOA implementation solves all the problems. For example we can talk about reuse and SHARED SERVICES. A service cannot be called a shared service until others outside a project use such service by adoption and integration with their system. So even term shared service is a very delicate term to use. This is an extensive discussion by itself. The other issue with shared service is versioning. How do we version such service? How do we deprecate old services? There are many answers but what is the unified, standard answer to such issue.

      SOA as you said has to go through many trials and implementations until we can come up with a set of standard practices and patterns, which can be used in most enterprise implementations.

      By the way, in my earlier posting I said that Mr. Schwartz is right in his assessment. I should have said also that it is true if he thinks of services (e-mail, portal, application services, and etc) being middleware not the real meaning of middleware(the glue).

      Now if I am correct in my assessment of the article here are some good definition for Mr. Schwartz to consider. Let look at some of the definition I found on the web:
      1. In http://www.scit.wlv.ac.uk/~jphb/comms/esppt/esppt1/sld024.htm it says: Layer of software that is between client and server processes that deliver the extra functionality. This basically refers to RPC, SOAP, RDA and etc..
      2. In http://www.cren.net/crenca/glossary/cpglossary.html : Middleware: Software that connects two otherwise separate applications OR separate products that serve as the glue between two applications. It is, therefore, distinct from import and export features that may be built into one of the applications. Middleware is sometimes called plumbing because it connects two sides of an application and passes data between them. (For example, there are a number of middleware products that link a database system to a Web server. This allows users to request data from the database using forms displayed on a Web browser, and it enables the Web server to return dynamic Web pages based on the user''s requests and profile.)
      3. In http://www.hyperdictionary.com/dictionary/middleware : Software that mediates between an application program and a network. It manages the interaction between disparate applications across the heterogeneous computing platforms. The Object Request Broker (ORB), software that manages communication between objects, is an example of a middleware program.

      Yadi Hooshmand
      Sadra Inc.
      www.sadrasoft.com

      Hi John

      I assume the following

      > GM use Web service and XML to exchange information (or online transactional invocation) over some standard protocol such as HTTP. This requires high bandwidth
      > Significant upgrade of hardware and software infrastructure to accommodate a new SOA

      I would carefully consider the following

      > ROI of services within internal as most organization have similar development standard and platform (except case of so much difference è I would question about the standards governance practice)
      > Security of key services as far as I know this is still key issue with WS
      > Provide a level of playing field to partners with Web Services is a fair call. However, be more careful with high volume transactions as high bandwidth and slow consumer will cause issues with expired transaction at the provider end. I face this once by mistake with our design / architecture.

      Well I believe Middleware still around for a while and certainly Jonathan Schwartz are too optimistic of his SUN strategy with Enterprise Java offerings.

      Messaging still dominate the bridge and message-compliant product vendor will watch SOA closely ever. We need some good and large SOA implementation for all of us to learn and increase its profile so key players are getting serious about this.

      It is good to hear you are doing this. Please email, as I would love to discuss and to know how you are going with this with its achievement and any challenge you may have faced.

      -h

      Technical Architect
      American Express
      Operations JAPA

      (e) huy.nguyen@consultant.com

      Good morning John,

      Is it any wonder EDI won''t die? Even with phonebook-sized X.12 manuals and carefully constructed implementation guides, we still work through semantic issues with EDI.

      The XML based messaging standards have a long way to go before reaching even that level of conformity. It will take multiple organizations with influence like GM to push this forward. To me, this looks like a problem that is years away from a solution.

      In the meantime... as you pointed out previously, how do you deal with differences in semantics, never mind format and protocol? And as I mentioned earlier, I would add the need to de-couple content from the specific application that produces it, allowing for a change in application architecture over time. Don''t hard-wire your enterprise business content semantics to an arbitrary set of application silos that existed at one point in time. Middleware is the solution of course.

      By the way, it''s always entertaining to listen to Tony Scott. Do you work in his organization?

      Regards.

      Huy - Regarding the SOA from large corporations, I am currently working as a Chief Architect at General Motors, where the focus of the group I work in is not only delivering ebXML to a large group of trading partners (30K +) but also an internal enterprise wide SOA.

      And I agree with your comments: the protocol I believe should be one or several of the OASIS and W3 based methods, specifically Schema and CAM to name a few. I believe that several will work in concert to provide these kinds of services.

      - john john.hardin@gm.com

      Agree in some aspects

      The answer to that need to include protocol to bridge various systems which often have a completely different infrastructure such as O/S, protocol, languages, threads, etc.

      IMO, Java Desk Top and Enterprised is not the answer. One of a credible solutions to that is Service Oriented Architecture which as I mentioned still need to convince from big players.

      -h

      Middleware will be dead, as soon as there is an answer to the semantic equivalency problem! One of the purposes of middleware is to bridge between formats that have the same data elements, but that are named differently. For example in OAGIS is the same as in xCBL. If a company needs to transform from OAGIS to xCBL, there is a human mapping effort, and map code in middleware to execute.

      The Universal Data Element Framework is gaining steam in standards bodies to provide an open standards based mechanism to resolve the semantic equivalency between disparate formats.

      Check out http://www.udef.org and http://www.topica.com/lists/udef.builders/read for info including an upcoming NIST and OAGIS proposal for a Proof of Concept.

      john hardin
      chief architect, general motors


      Feedback Pages:


      Your Feedback
      Ralph wrote: Total Trash! At the very least, the guy could write a few paragraphs outlining why it is dead, instead of saying "its too expensive" so buy our crap. I expect more from JDJ than this, maybe I shouldn''t.
      Guidosky wrote: The best Sun can do to follow BEA Systems, Gartner Group and IBM vision on Application Platform Suites and SOA. But it is nstill ot enough to catch the front runners.
      Rod wrote: Several respondents picked up on this immediately: Another thinly disguised (if it were disguised at all) sales pitch, with a direct attack against IBM. What "Jonathon" fails to recognize is that it is crazy (cost prohibitive) to rip and replace legacy systems. Oracle pitches a similar message (one source - Oracle), I think. A company who does that risks its own demise: while they spend money rearchitecting existing processes and functionality, their competition will push them into oblivion. Web Services is one of the many keys to the future, along with information integration (both EAI and EII). Middleware helps make that happen. jackprogrammer: If you can write a program to generate marketing hype, I am not sure if you are a genius or sick...
      Fred Smith wrote: A catchy title yes but what you are offering is just your own middleware with Sun branding. In short a sales pitch for your own product. Lame. Joining the party rather late don''t you think? A dollar short and a day late. Must have read those briefs by Gartner that this area of the market is hot!
      Serban Florea wrote: This is just another sales pitch for the newest fashionable abstraction. And those web services, what do they run behind the scenes, if not middleware ?
      jackprogrammer wrote: This is really useful stuff for all of us Java programmers. Please give me more! and more! Long Live the Schwartz! I think I could write a program to generate this sort of garbage.
      Mark Rosenthal wrote: Hello John, Yes, the lack of Canonicals costs me far more in up-front integration effort than differences in format and protocol. Couldn''t agree more. It''s amazing that format and protocol get so much of the SOA discussion bandwidth. But if the challenges in establishing Canonicals were mostly technical, I wouldn''t still today be having semantics discussions with EDI trading partners. How long will it take for semantic (not technical) conformance to emerge? Recent experience with UCCnet is making me think this (the semantics, not the mechanism/technology) is much harder than most people thought. Regards.
      John Hardin wrote: Mr. Rosenthal - Yep, I work a few levels under Tony Scott. So regarding decoupling the semantics from the app that creates it... Take an example of the UDEF ID''s being assigned to each data element in a schema, or each data element in an RDF taxonomy. This exists as an online resource, and there would be resolver services on the wire to perform lookups and transforms in real time. By the way, an example UDEF ID appears as d.t.2_8, which is literally translated as purchase.order.document_identifier. So the ID is an attribute of the actual data element. Then consider an approach like the new Content Assembly Mechanism (CAM) TC in OASIS to actually compose the content. Using common, or Canonical, based formats like OAGIS, we can achieve real human-free integration, where the formats are well defined, and all data elements are labeled with UDEF IDs. See more on the CAM, OAGIS...
      Mark Rosenthal wrote: Hello Yadi, If shared services through standard protocol and formatting make creating point-to-point connections between applications easier, than I submit they are evil. If in a few years, a shared service is replaced with another which has somewhat different content and semantics, then each and every application that was coded to directly use that service may need to adapt. In an environment with a large number of point-to-point connections between shared services, the arithmetic of change becomes absolutely frightening. Inter-application "spaghetti" is not a result of multiple protocols and formats or even semantics, it''s a result of multiple point-to-point application connections. If I had to make a choice between point-to-point shared services versus hub-and-spoke messaging through proprietary interfaces, I''d choose hub-and-spoke every time. Fortunately there is no n...
      Yadi Hooshmand wrote: John, Huy and all other dear readers and software engineers: I strongly believe the whole problem with the article is in the different interpretations of the word middleware. Mr. Schwartz is referring to middleware as opposite of shared service. I understood what he means by middleware is really repeated, un-sharable, scattered services that are floating in an enterprise. If this is what he is referring to then he really has to fix the terminology. And if he is referring to such services, I agree with that. The age of un-shareable services has come to an end. But what is next. SOA techniques have not really matured to a level that we can say SOA implementation solves all the problems. For example we can talk about reuse and SHARED SERVICES. A service cannot be called a shared service until others outside a project use such service by adoption and integration with their system. So e...
      Huy Nguyen wrote: Hi John I assume the following > GM use Web service and XML to exchange information (or online transactional invocation) over some standard protocol such as HTTP. This requires high bandwidth > Significant upgrade of hardware and software infrastructure to accommodate a new SOA I would carefully consider the following > ROI of services within internal as most organization have similar development standard and platform (except case of so much difference è I would question about the standards governance practice) > Security of key services as far as I know this is still key issue with WS > Provide a level of playing field to partners with Web Services is a fair call. However, be more careful with high volume transactions as high bandwidth and slow consumer will cause issues with expired transaction at the provider end. I face this once by mistake with our design / arch...
      Mark Rosenthal wrote: Good morning John, Is it any wonder EDI won''t die? Even with phonebook-sized X.12 manuals and carefully constructed implementation guides, we still work through semantic issues with EDI. The XML based messaging standards have a long way to go before reaching even that level of conformity. It will take multiple organizations with influence like GM to push this forward. To me, this looks like a problem that is years away from a solution. In the meantime... as you pointed out previously, how do you deal with differences in semantics, never mind format and protocol? And as I mentioned earlier, I would add the need to de-couple content from the specific application that produces it, allowing for a change in application architecture over time. Don''t hard-wire your enterprise business content semantics to an arbitrary set of application silos that existed at one point in time....
      john hardin wrote: Huy - Regarding the SOA from large corporations, I am currently working as a Chief Architect at General Motors, where the focus of the group I work in is not only delivering ebXML to a large group of trading partners (30K +) but also an internal enterprise wide SOA. And I agree with your comments: the protocol I believe should be one or several of the OASIS and W3 based methods, specifically Schema and CAM to name a few. I believe that several will work in concert to provide these kinds of services. - john john.hardin@gm.com
      Huy Nguyen wrote: Agree in some aspects The answer to that need to include protocol to bridge various systems which often have a completely different infrastructure such as O/S, protocol, languages, threads, etc. IMO, Java Desk Top and Enterprised is not the answer. One of a credible solutions to that is Service Oriented Architecture which as I mentioned still need to convince from big players. -h
      john hardin wrote: Middleware will be dead, as soon as there is an answer to the semantic equivalency problem! One of the purposes of middleware is to bridge between formats that have the same data elements, but that are named differently. For example in OAGIS is the same as in xCBL. If a company needs to transform from OAGIS to xCBL, there is a human mapping effort, and map code in middleware to execute. The Universal Data Element Framework is gaining steam in standards bodies to provide an open standards based mechanism to resolve the semantic equivalency between disparate formats. Check out http://www.udef.org and http://www.topica.com/lists/udef.builders/read for info including an upcoming NIST and OAGIS proposal for a Proof of Concept. john hardin chief architect, general motors
      David B wrote: Yea...middleware is dead...right, just like COBOL, CICS and mainframe apps that have been around forever and will continue to be around forever.
      Dark Helmet wrote: I see you have a very large Schwartz...
      Huy Nguyen wrote: commmm''on Jon SUN Vision + Sales Talk Middleware is not dead now or in the near future. SOA does look good with high bandwith infrastructure. SOA still evolve to convince. -h
      Glenn Johnson wrote: It would be far more accurate to say that "middleware is not enough." Message Qeueus (JMS, MSMQ, WebSphere MQ, for example) all lack the kind of cross-platform integration framework needed to efficiently implement an SOA. The major vendors all make the mistake of trying to force one into a single paradigm (J2EE, .NET) while ignoring the need to generate legacy objects (from 5250, 3270, VT, CICS, COBOL, RPG, etc.) that can be deployed across platforms. Sure, as developers it would be great to live in a world of infinite time and infinite investment in software development, but in the real world you need to leverage existing apps, bridge platforms and complete projects once in a while.
      spam4tomi@yahoo.com wrote: Middleware is dead because we have service oriented architectures everywhere? But how are the services communicating? Maybe there is a new name for Middleware now. Aren''t we working in a great field, where people create new Hype words for the same old solutions all the time? That article is only good for non techies to impress each other with there tech knowlege.
      Latest Cloud Developer Stories
      The precious oil is extracted from the seeds of prickly pear cactus plant. After taking out the seeds from the fruits, they are adequately dried and then cold pressed to obtain the oil. Indeed, the prickly seed oil is quite expensive. Well, that is understandable when you conside...
      The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed...
      There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering cons...
      ScaleMP is presenting at CloudEXPO 2019, held June 24-26 in Santa Clara, and we’d love to see you there. At the conference, we’ll demonstrate how ScaleMP is solving one of the most vexing challenges for cloud — memory cost and limit of scale — and how our innovative vSMP MemoryON...
      Darktrace is the world's leading AI company for cyber security. Created by mathematicians from the University of Cambridge, Darktrace's Enterprise Immune System is the first non-consumer application of machine learning to work at scale, across all network types, from physical, vi...
      Subscribe to the World's Most Powerful Newsletters
      Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
      Click to Add our RSS Feeds to the Service of Your Choice:
      Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
      myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
      Publish Your Article! Please send it to editorial(at)sys-con.com!

      Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021



      SYS-CON Featured Whitepapers
      ADS BY GOOGLE