Welcome!

Cloud Expo Authors: Pat Romanski, Elizabeth White, Brad Anderson, Liz McMillan, Christopher Campbell

Related Topics: Java

Java: Article

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.

    • More Stories By 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.

      Comments (58) View Comments

      Share your thoughts on this story.

      Add your comment
      You must be signed in to add a comment. Sign-in | Register

      In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


      Most Recent Comments
      Ralph 02/27/04 09:31:52 AM EST

      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 02/20/04 06:15:17 PM EST

      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 02/19/04 12:49:45 PM EST

      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 02/18/04 09:48:32 PM EST

      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 02/18/04 11:49:42 AM EST

      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 02/18/04 04:37:42 AM EST

      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 02/14/04 08:12:58 PM EST

      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 02/13/04 07:50:09 PM EST

      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

      Mark Rosenthal 02/13/04 05:59:51 PM EST

      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.

      Yadi Hooshmand 02/13/04 02:15:52 PM EST

      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

      Huy Nguyen 02/13/04 10:21:08 AM EST

      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

      Mark Rosenthal 02/13/04 09:16:06 AM EST

      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.

      john hardin 02/13/04 08:14:01 AM EST

      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 02/13/04 01:21:00 AM EST

      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 02/12/04 10:56:33 PM EST

      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 02/12/04 11:28:46 AM EST

      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 02/12/04 11:21:47 AM EST

      I see you have a very large Schwartz...

      Huy Nguyen 02/12/04 03:02:10 AM EST

      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 02/10/04 08:07:18 PM EST

      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 02/10/04 07:26:55 PM EST

      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.

      Philip Berman 02/10/04 03:57:35 PM EST

      Perhaps SUN''s middleware efforts are dead. They killed NetDynamics, Kiva, and iPlanet. I don''t see Oracle''s 10g AS, IBM WebSphere or BEA going away anytime soon. I guess Jonathan Schwartz does have a big fancy title, and a nice pony tail, but he has no idea what he''s talking about. He''s eating his own HYpe, and seems to no little about actual work i.e. programming.

      Leif Ashley 02/10/04 03:42:21 PM EST

      You have to admire someone of this worth managing to slip in to and hold a top level position at SUN. This has to be the stupidest comment I''ve seen since Gates said 640KB should be enough for anyone.

      SUN and others have been hailing "services" from the SOAP/XML beginnings, and nothing has come of it, mainly due to middleware complexities. I might also add the complexities arise from crap like EJB specs.

      I think about 50 of us good developers should get together and build something else that works instead of waiting for SUN to make it happen.

      Michael 02/10/04 03:22:01 PM EST

      What is the going rate to run an ad -- oops, I mean article like this in JDJ? I''ve got some software I''d like to sell -- oops again, I mean explain as well.

      Bob 02/10/04 03:14:49 PM EST

      There will always be a middle. It just moves around a lot.

      Joe 02/10/04 03:08:30 PM EST

      No sure if sun really understand the concept of middleware. If they do, BEA will not exist any more.

      Jim 02/10/04 02:17:34 PM EST

      Does Sun has ever built any successful software? How about its memory-leaking Solaris libraries and the failed ONE?

      Mike C 02/10/04 02:14:47 PM EST

      I''m glad everyone else sees through this load he dropped. I was going to say something similar to Chuck Sinnett and Darren Pye. What about the "middleware" that runs the WebServices?! Just because he''s trying to call it a platform doesn''t change anything.

      John Son 02/10/04 02:09:45 PM EST

      Did anyone find themselves scrolling/sizing their window so as to obscure the annoying pictures of Jonathan while reading this article/sales pitch?

      Ben Dover 02/10/04 02:08:04 PM EST

      Was this an article to read, or an excuse to have some executive get off on having his photo plastered all over a sales pitch?

      Vincent DeFrazio 02/10/04 12:04:14 PM EST

      Unfortunately reps from Sun keep putting out this junk. They used to be a company I respected and now I can''t wait for them to go away. I respect them less than Microsoft these days. Why must they confuse the market like this. They are bitter and dying. Intel, Linux, Microsoft, WebLogic, die Sun die but give Java to an open consortium first. JDJ, please stop publishing such junk from Sun.

      Tom Bender 02/10/04 11:26:08 AM EST

      Perhaps you need to spread a few 8"x10" photos of yourself across this 200 word piece of trash.

      Brad O''Hearne 02/10/04 11:10:04 AM EST

      Joseph,

      I don''t think Tony''s concern was about JDJ -- its about Sun''s "software czar" basically blowing a gaping hole in the side of J2EE. When the provider of the technology that the industry has invested in basically talks down its primary use, that''s an issue. Now I''ve heard from elsewhere that the point being made is one that stand-alone middleware is dead, but middleware in the operating system is the future. That may be true, but Sun ought to be careful about firing on developers in their own Java development community. Such an OS-centric view is extremely ironic, and sounds a whole lot like Microsoft...

      Mark Rosenthal 02/10/04 11:05:40 AM EST

      Shared services reduce the effort in establishing communication with applications. This is good. I still want an abstraction layer in the middle. In a world where there is much overlap between what functions commercial apps provide, this allows me to break inter-application dependency and minimize the impact of replacing apps or even changing the relationships between apps and the information they provide. Middleware lets me keep subscribers to content isolated from change.

      Joseph Ottinger 02/10/04 10:52:45 AM EST

      Tony, note that JDJ isn''t a monolith - there are dissenting opinions internally, as you can expect from people drawn from a lot of areas.

      An article like this *is* his opinion. You''re free to disagree with it.

      Tony Hsieh 02/10/04 10:48:00 AM EST

      JDJ, Schwartz: please cite your source and back up what you say.

      JDJ, please cite that this is some sort of either a) a shock journalism article to generate reader ire or b) a paid ad. Either way, it seems pretty thin on anything substantive.

      Schwartz, is this just your opinion? Clarify how this $100/person Office fits with your overall SUN corporate goal. Planning to jettison J2ee?

      Free hint: exit in the fashion year of 1993, lose the ponytail.

      Jim Buckner 02/10/04 10:35:29 AM EST

      Jonathan should be glad that Middleware IS ALIVE and well -- otherwise J2EE wouldn't stand a chance in a world where key business components exist in silos. We and most other organizations would not spend the money and could probably not bring together the resources to re-develop business software on a J2EE Platform without middleware like EntireX.

      Colin Waterhouse III 02/10/04 10:31:12 AM EST

      I think the only thing this article lacks is a few more pictures of Jonathan Schwartz.

      Brad O'Hearne 02/10/04 10:03:53 AM EST

      Sun really needs a PR firm to start auditing its employees' public statements. From the CEO down, its just one foot in the mouth after another. This is not only a weak sales pitch, it really undermines the leadership and technical knowledge at Sun. Nothing like making silly, nonsensical technical comments to try to sell a new product, while at the same time blowing a hole in Java''s primary area of success: J2EE.

      Darren Pye 02/10/04 09:16:15 AM EST

      Andy S,

      I think you could consider J2EE middleware in his context. Stick a web services front end on that and now your J2EE EJBs, app server services and connectors are the middleware. Since the model seems to relegate J2EE as middleware, I hope he didn''t mean J2EE is "history" ;)

      A poor sales pitch/article (umm..right) overall, pitched to the wrong audience.

      Buckminster Fuller 02/10/04 09:13:05 AM EST

      Big Deal. I told my CFO this 10 months ago, and Gartner said it 18 months ago.

      Dale 02/10/04 09:07:39 AM EST

      Jonathan definitely needs to get out more often and see whats going on in the "real world".

      Please spare us the death-throes sales pitches of Sun 02/10/04 08:50:17 AM EST

      To put an article like this in a developers'' magazine is utterly foolish. JDJ should be ashamed they let ANY vendor have this kind of space to put out an absolutely content-free article like this. Even as a sales pitch, it''s not a very good one. Poor Sun.

      Dave Geise 02/10/04 08:50:13 AM EST

      Hmmm... since Sun can''t find a way to make money on its middleware, what have they got to lose by declaring middleware is dead? The only middleware that''s dead is Sun''s.

      Andy S 02/10/04 08:48:34 AM EST

      I dunno. Maybe he is talking about web services light weight soap infastructure replacing messaging and corba
      infastructures. Is J2EE EJB considered a middleware in
      his context? He should have said something about J2EE.
      The way I see it, web services are good for communicating between 2 processes. Somebody has to build and webservice enable the 2 processes.

      Chuck Sinnett 02/10/04 08:20:30 AM EST

      So, if middleware is dead, what are you going to use to create these shared services? What will provide the workflow, transformation and integration tools needed to do it? Hummm.... ....

      What is Middleware?

      It''s not dead, it just moved a little...

      cas

      Darren Pye 02/10/04 08:15:23 AM EST

      Of course integration is better. Of course you''re going to save if you can have everything integrated by a service layer. Yes J2EE is a good for all of this.

      However, in the scenario he proposes, unless you are starting from the ground up, you won''t be eliminating middleware by using J2EE. You will be using J2EE as middleware.

      I think his catch phrase should have read, "Middleware is J2EE", rather then "Middleware is history".

      I love J2EE and highly recommend it, but I certainly wouldn''t try to sell it as though its a magical solution that can make all other middleware history. Yes it would be wonderful if all companies could develop a single service layer that instead of being the glue that binds, is the framework upon which they rely...but rarely is anything that simple. Its an idealized view wich oversimplifies the realities. Worth shooting for sure, and even some times achievable, but the concept is nothing new.

      In a sense he has diminished the value of J2EE by making it sound like just another middleware solution...the Parlay of business systems.

      IMO, this article is just another sales pitch, and not a very good one.

      Ed 02/10/04 08:08:49 AM EST

      If the readers of the JDJ don''t buy into this ''vision'', who will? The basic concept of ''one fits all'' for any area of IT is intrinsically flawed.

      John Vekich 02/10/04 08:02:30 AM EST

      Schwartz is off smoking the curtains on this one. He needs to get out into the real world. And any java developer who swallows such assetions on blind faith also needs a reality check. You are selling an overly complicated solution here as a magic solution to all of IT''s ills. Somewhere along the line Sun aka Scott forgot the KISS Rule. Way too many moving parts and levels of obfuscation.

      Paul Barns 02/10/04 07:30:30 AM EST

      Man... is he trying to be the poster-boy for the end of middleware ? How many times does someone's mug shot need to be in an article ? There should have been other graphics depicting a network diagram or something to support his thesis. All he needs now is maybe a string of numbers on a placard held below his chin...

      NICK XIDIS 02/10/04 07:05:43 AM EST

      Pretty pathetic. Sun, JDJ and Jonathan can do much better. There are some real issues of real substance; SOA, software licensing, etc... in what Jonathan has to say. Too bad it comes wrapped in sensationalism and a poorly delivered sales pitch.

      Cloud Expo Breaking News
      Simply defined the SDDC promises that you’ll be able to treat “all” of your IT infrastructure as if it’s completely malleable. That there are no restrictions to how you can use and assign everything from border controls to VM size as long as you stay within the technical capabilities of the devices. The promise is great, but the reality is still a dream for the majority of enterprises. In his session at 14th Cloud Expo, Mark Thiele, EVP, Data Center Tech, at SUPERNAP, will cover where and how a business might benefit from SDDC and also why they should or shouldn’t attempt to adopt today.
      MapDB is an Apache-licensed open source database specifically designed for Java developers. The library uses the standard Java Collections API, making it totally natural for Java developers to use and adopt, while scaling database size from GBs to TBs. MapDB is very fast and supports an agile approach to data, allowing developers to construct flexible schemas to exactly match application needs and tune performance, durability and caching for specific requirements.
      APIs came about to help companies create and manage their digital ecosystem, enabling them not only to reach more customers through more devices, but also create a large supporting ecosystem of developers and partners. While Facebook, Twitter and Netflix were the early adopters of APIs, large enterprises have been quick to embrace the concept of APIs and have been leveraging APIs as a connective tissue that powers all interactions between their customers, partners and employees. As enterprises embrace APIs, some very specific Enterprise API Adoption patterns and best practices have started emerging. In his session at 14th Cloud Expo, Sachin Agarwal, VP of Product Marketing and Strategy at SOA Software, will talk about the most common enterprise API patterns and will discuss how enterprises can successfully launch an API program.
      The social media expansion has shown just how people are eager to share their experiences with the rest of the world. Cloud technology is the perfect platform to satisfy this need given its great flexibility and readiness. At Cynny, we aim to revolutionize how people share and organize their digital life through a brand new cloud service, starting from infrastructure to the users’ interface. A revolution that began from inventing and designing our very own infrastructure: we have created the first server network powered solely by ARM CPU. The microservers have “organism-like” features, differentiating them from any of the current technologies. Benefits include low consumption of energy, making Cynny the ecologically friendly alternative for storage as well as cheaper infrastructure, lower running costs, etc.
      Next-Gen Cloud. Whatever you call it, there’s a higher calling for cloud computing that requires providers to change their spots and move from a commodity mindset to a premium one. Businesses can no longer maintain the status quo that today’s service providers offer. Yes, the continuity, speed, mobility, data access and connectivity are staples of the cloud and always will be. But cloud providers that plan to not only exist tomorrow – but to lead – know that security must be the top priority for the cloud and are delivering it now. In his session at 14th Cloud Expo, Kurt Hagerman, Chief Information Security Officer at FireHost, will detail why and how you can have both infrastructure performance and enterprise-grade security – and what tomorrow's cloud provider will look like.
      Today, developers and business units are leading the charge to cloud computing. The primary driver: faster access to computing resources by using the cloud's automated infrastructure provisioning. However, fast access to infrastructure exposes the next friction point: creating, delivering, and operating applications much faster. In his session at 14th Cloud Expo, Bernard Golden, VP of Strategy at ActiveState, will discuss why solving the next friction point is critical for true cloud computing success and how developers and business units can leverage service catalogs, frameworks, and DevOps to achieve the true goal of IT: delivering increased business value through applications.
      Web conferencing in a public cloud has the same risks as any other cloud service. If you have ever had concerns over the types of data being shared in your employees’ web conferences, such as IP, financials or customer data, then it’s time to look at web conferencing in a private cloud. In her session at 14th Cloud Expo, Courtney Behrens, Senior Marketing Manager at Brother International, will discuss how issues that had previously been out of your control, like performance, advanced administration and compliance, can now be put back behind your firewall.
      More and more enterprises today are doing business by opening up their data and applications through APIs. Though forward-thinking and strategic, exposing APIs also increases the surface area for potential attack by hackers. To benefit from APIs while staying secure, enterprises and security architects need to continue to develop a deep understanding about API security and how it differs from traditional web application security or mobile application security. In his session at 14th Cloud Expo, Sachin Agarwal, VP of Product Marketing and Strategy at SOA Software, will walk you through the various aspects of how an API could be potentially exploited. He will discuss the necessary best practices to secure your data and enterprise applications while continue continuing to support your business’s digital initiatives.
      The revolution that happened in the server universe over the past 15 years has resulted in an eco-system that is more open, more democratically innovative and produced better results in technically challenging dimensions like scale. The underpinnings of the revolution were common hardware, standards based APIs (ex. POSIX) and a strict adherence to layering and isolation between applications, daemons and kernel drivers/modules which allowed multiple types of development happen in parallel without hindering others. Put simply, today's server model is built on a consistent x86 platform with few surprises in its core components. A kernel abstracts away the platform, so that applications and daemons are decoupled from the hardware. In contrast, networking equipment is still stuck in the mainframe era. Today, networking equipment is a single appliance, including hardware, OS, applications and user interface come as a monolithic entity from a single vendor. Switching between different vendor'...
      Cloud backup and recovery services are critical to safeguarding an organization’s data and ensuring business continuity when technical failures and outages occur. With so many choices, how do you find the right provider for your specific needs? In his session at 14th Cloud Expo, Daniel Jacobson, Technology Manager at BUMI, will outline the key factors including backup configurations, proactive monitoring, data restoration, disaster recovery drills, security, compliance and data center resources. Aside from the technical considerations, the secret sauce in identifying the best vendor is the level of focus, expertise and specialization of their engineering team and support group, and how they monitor your day-to-day backups, provide recommendations, and guide you through restores when necessary.
      Cloud scalability and performance should be at the heart of every successful Internet venture. The infrastructure needs to be resilient, flexible, and fast – it’s best not to get caught thinking about architecture until the middle of an emergency, when it's too late. In his interactive, no-holds-barred session at 14th Cloud Expo, Phil Jackson, Development Community Advocate for SoftLayer, will dive into how to design and build-out the right cloud infrastructure.
      You use an agile process; your goal is to make your organization more agile. What about your data infrastructure? The truth is, today’s databases are anything but agile – they are effectively static repositories that are cumbersome to work with, difficult to change, and cannot keep pace with application demands. Performance suffers as a result, and it takes far longer than it should to deliver on new features and capabilities needed to make your organization competitive. As your application and business needs change, data repositories and structures get outmoded rapidly, resulting in increased work for application developers and slow performance for end users. Further, as data sizes grow into the Big Data realm, this problem is exacerbated and becomes even more difficult to address. A seemingly simple schema change can take hours (or more) to perform, and as requirements evolve the disconnect between existing data structures and actual needs diverge.
      SYS-CON Events announced today that SherWeb, a long-time leading provider of cloud services and Microsoft's 2013 World Hosting Partner of the Year, will exhibit at SYS-CON's 14th International Cloud Expo®, which will take place on June 10–12, 2014, at the Javits Center in New York City, New York. A worldwide hosted services leader ranking in the prestigious North American Deloitte Technology Fast 500TM, and Microsoft's 2013 World Hosting Partner of the Year, SherWeb provides competitive cloud solutions to businesses and partners around the world. Founded in 1998, SherWeb is a privately owned company headquartered in Quebec, Canada. Its service portfolio includes Microsoft Exchange, SharePoint, Lync, Dynamics CRM and more.
      The world of cloud and application development is not just for the hardened developer these days. In their session at 14th Cloud Expo, Phil Jackson, Development Community Advocate for SoftLayer, and Harold Hannon, Sr. Software Architect at SoftLayer, will pull back the curtain of the architecture of a fun demo application purpose-built for the cloud. They will focus on demonstrating how they leveraged compute, storage, messaging, and other cloud elements hosted at SoftLayer to lower the effort and difficulty of putting together a useful application. This will be an active demonstration and review of simple command-line tools and resources, so don’t be afraid if you are not a seasoned developer.
      SYS-CON Events announced today that BUMI, a premium managed service provider specializing in data backup and recovery, will exhibit at SYS-CON's 14th International Cloud Expo®, which will take place on June 10–12, 2014, at the Javits Center in New York City, New York. Manhattan-based BUMI (Backup My Info!) is a premium managed service provider specializing in data backup and recovery. Founded in 2002, the company’s Here, There and Everywhere data backup and recovery solutions are utilized by more than 500 businesses. BUMI clients include professional service organizations such as banking, financial, insurance, accounting, hedge funds and law firms. The company is known for its relentless passion for customer service and support, and has won numerous awards, including Customer Service Provider of the Year and 10 Best Companies to Work For.