Gartner AADI Summit: SOA going into 2009

Discussions

News: Gartner AADI Summit: SOA going into 2009

  1. Gartner AADI Summit: SOA going into 2009 (14 messages)

    At this year's Gartner's Application Architecture, Development & Integration Summit 2008 in Las Vegas, Gartner analyst Yefim Natis marked defining SOA traits. He said that a SOA is modular, discoverable, shareable, swappable and can be distributed. "SOA is integration. It is a strategic initiative," he said. "You can only do it in parts of a domain where you have control." Read more about how after several years into the SOA era of application and integration development, SOA continues on without a full consensus opinion of what it is.

    Threaded Messages (14)

  2. ECHO Echo echo...[ Go to top ]

    Is anybody in the real world really getting anywhere with SOA? I mean, not only in whitepapers, announcements, reports of incredible savings from companies *selling* SOA consulting or products. My impression is that some really useful technologies spread like wildfire without any advertising (like, Hibernate, AJAX, Open Source in general), and with SOA it is the other way round: lots of advertising, tons of hype, many promises, and so little materializing. I worked with large companies claiming they successfully employ SOA. The inside view: management claims they successfully employ SOA. Developers in the same company wonder what these people are talking about. Just by having systems talk to each other via MQ and putting an ESB-sticker on it does not make the whole thing SOA (whatever that now might exactly be). Or how about the "great" idea of putting all services in a company-wide UDDI directory. This is not about "find me a general service to obtain book prices and order a book" - the services are all so specific there is no chance any body else will want to (or be able to) use a certain service. Chris
  3. Re: ECHO Echo echo...[ Go to top ]

    Just by having systems talk to each other via MQ and putting an ESB-sticker on it does not make the whole thing SOA (whatever that now might exactly be).
    I'd say your observations seem accurate based on the anecdotal evidence I've seen. I've worked on a number of projects management has bandied around as being "SOA" - most of the time it has been about using a little XML between systems, maybe sticking a few message queues or topics in between. That's it. There are a lot of good individual principles in the "SOA" space, but they seem to be applied in some cases as if SOA is a hammer and every problem is a nail..
  4. Re: ECHO Echo echo...[ Go to top ]

    Completely agree with you ! Making a web service call from within a silo application doesn't mean you're doing SOA. Same observation for the projects I'm working with : everybody talks about SOA but never met any implementation
  5. Re: ECHO Echo echo...[ Go to top ]

    Is anybody in the real world really getting anywhere with SOA?

    I mean, not only in whitepapers, announcements, reports of incredible savings from companies *selling* SOA consulting or products.
    I have been working at central role in a company that implemented SOA and I consider it a success. Within a year we started reusing services an thus saving money.
    My impression is that some reallye and with SOA it is the other way round: lots of advertising, tons of hype, many promises, and so little materializing.
    Don't blame a good strategy for all the companies trying to make money on something. We have the same problem with Agile and cloud computing (not claiming they are as good as SOA).
    I worked with large companies claiming they successfully employ SOA. The inside view: management claims they successfully employ SOA. Developers in the same company wonder what these people are talking about. Just by having systems talk to each other via MQ and putting an ESB-sticker on it does not make the whole thing SOA (whatever that now might exactly be).
    Here is the problem. SOA is not about integrating with XML or webservices. SOA is about designing the services first based on the companies business processes.
    Or how about the "great" idea of putting all services in a company-wide UDDI directory. This is not about "find me a general service to obtain book prices and order a book" - the services are all so specific there is no chance any body else will want to (or be able to) use a certain service.
    It can not be repeated often enough. SOA is not about technology. If you start with a technology you start at the wrong en. UDDI is a technology that I have never found a use for in any situation.
  6. Re: ECHO Echo echo...[ Go to top ]

    SOA is not about technology.
    Ok but you need to use a technology of some kind. Which one did you use for your successfull SOA project ? - Web services ?? What implementation ? How did you deal with version incompatibility within an implementation ? - ESB ?? What implementation ? Was it mature enough ?
    UDDI is a technology that I have never found a use for in any situation.
    How does a new application knows which services are available ? What exactly do these services do ? what version of that service should I use ?
  7. Re: ECHO Echo echo...[ Go to top ]


    SOA is not about technology.


    Ok but you need to use a technology of some kind.
    Which one did you use for your successfull SOA project ?
    Obviously I am not getting through to you. The success of SOA has NOTHING to do with the technology you use. Use whatever your envrionment require (RMI, Corba, SOAP, JMS, Rest, MQ,.....)

    - Web services ?? What implementation ? How did you deal with version incompatibility within an implementation ?
    - ESB ?? What implementation ? Was it mature enough ?


    UDDI is a technology that I have never found a use for in any situation.


    How does a new application knows which services are available ? What exactly do these services do ? what version of that service should I use ?
    Where worked we did not have self developing systems that had to find out which service to use when creating itself. We had people that developed applications and they asked the governing team if there was a suitable service available or if a new one had to be created or a new version of an existing one.
    A new application should always use the latest version. Whenever a new version is created all consumer has to eventually migrate to that version.
  8. Re: ECHO Echo echo...[ Go to top ]

    I have been working at central role in a company that implemented SOA and I consider it a success. Within a year we started reusing services an thus saving money.
    I agree with Chris that many services are not sharable -- actually IMHO majority of business tasks are not sharable so they are really NOT services. Can you please give us some examples of services you implemented (high level description) and how many applications are reusing these services? Thanks Danny
  9. Re: ECHO Echo echo...[ Go to top ]

    I have been working at central role in a company that implemented SOA and I consider it a success. Within a year we started reusing services an thus saving money.

    I agree with Chris that many services are not sharable -- actually IMHO majority of business tasks are not sharable so they are really NOT services.

    Can you please give us some examples of services you implemented (high level description) and how many applications are reusing these services? Thanks

    Danny
    How many applications are sharing the same database (including stored procs, triggers, etc) but no code?
  10. Re: ECHO Echo echo...[ Go to top ]

    I have been working at central role in a company that implemented SOA and I consider it a success. Within a year we started reusing services an thus saving money.

    I agree with Chris that many services are not sharable -- actually IMHO majority of business tasks are not sharable so they are really NOT services.

    Can you please give us some examples of services you implemented (high level description) and how many applications are reusing these services? Thanks

    Danny
    The most central BO we had was "vehicle". Most applications used that. Part of the information was located outside of our databases so the reuse of how data was cached and fetched was a great benefit. Another service was making a booking. There where several clients (voice, internet, callcenter). One of the great things with SOA is that it works even if your system is a mess, and can coexist on the progress to a better structured system. When all consumer systems has been migrated to using the SOA services cleaning up is easy, there will only be one place. We had only stared so we had 3 systems using the SOA services and all of them used the most central services.
  11. Re: ECHO Echo echo...[ Go to top ]

    I have been working at central role in a company that implemented SOA and I consider it a success. Within a year we started reusing services an thus saving money.

    I agree with Chris that many services are not sharable -- actually IMHO majority of business tasks are not sharable so they are really NOT services.

    Can you please give us some examples of services you implemented (high level description) and how many applications are reusing these services? Thanks

    Danny
    The Health Care industry is in desperate need of SOA. Yes - some are doing it. The need is not just internal but between vendors (Insurers, Labs, Imaging, etc.). But most seem clueless as how to do it and the importance of it. Their SOA seems be be mainly done via ETL and shared databases or archaic systems like Cloverleaf and HL7.
  12. SOA in CHINA[ Go to top ]

    there are many SOA projects in China. I did two SOA projects in Jiangsu Province Electric Power Company and Foshan Electric Power Company. The project team broke EP systems into services, business processes are composed by these services. Jiangsu EP SOA project last two year, from 2006 to 2008, these were 4 ISV and more than 50 developers. Foshan EP SOA project is still going on.
  13. SOA = service overloaded architecture[ Go to top ]

    its goign to die the "ejb" death. Now a days everyone is writing a service for a simple function even if that function is used in one place for one client. its the same way EJBs were dealt with - create EJBs for a container running in the same VM.
  14. yep[ Go to top ]

    its goign to die the "ejb" death.

    Now a days everyone is writing a service for a simple function even if that function is used in one place for one client.

    its the same way EJBs were dealt with - create EJBs for a container running in the same VM.
    That's my take too. Some are also using web services for what are really components. Architecturally, services should look the same as the old session facade pattern, a course grained service preforming high level services. The lower level services should just be pojos provided no other concerns exist. Unfortunately, the proponents of the silo approach (everything is an independent service unaware of anything else) are vocal and passionate. Spring fanboys seem to love this since it gives them even more XML glueware to obfuscate the app :)
  15. It's the most important aspect of SOA. EIP gives us four EI style, they have their usage in different context, just as Design patterns, nothing is a all-in-one solution. SOA is a design perspective from business, not from data share level. UDDI is a good model for service management, but not a good choice in today's solution. it's too precise, fine-grained. So we can't use it in real project, but only used as a reference model.