Discussions

News: Ask TSS: The move towards a service-oriented architecture

  1. There's a lot of hoopla in the industry about web services. What many are not seeing is that web services also represents a paradigm shift towards a service-oriented architecture. Let's discuss whether this paradigm shift is really happening, and if so, what challenges organizations might face.

    Some background information:

    A service-oriented architecture is one where an organization's applications are decomposed into services available on the network. Rather than building applications the standard monolithic way, an application is broken up into smaller, fine-grained services.

    For example, a purchase order system needs to tap into an employee database. That employee database could be used by other applications as well, such as a payroll application. One possibility would be to rearchitect an organization's employee database as a service. That service could be built with J2EE or .NET. Other services (either built with J2EE or .NET) could tap into this service, such as the purchase order system, or payroll system.

    Questions:

    1) Do you think that the organization of the future will be service oriented or application oriented?

    2) What challenges do you think organizations will face when embracing a service-oriented model?

    Threaded Messages (15)

  2. At the moment I'm a very strong advocate of service oriented architectures. In particular I believe there are a few core domain independent services which most(all?) organisations require. For example, consider the interest in CRM systems. One hot topic at the moment is the 'customer centric information architecture'. Just imagine if customer management was a service. We would no longer have to duplicate customer management in each app. Each app just uses the service. As a service, the customer data store can finally provide a realtime view of the customer.

    So what are the challenges? Well in the example above, we would want the customer data store to be very extensible, as it potentially stores a lot of data and metadata (XML?). The other major issue I see is quality of service. How reliable is the service, how scalable is it, does it support transactions.

    regards

    Rob
  3. Personally, web service enabling applications within an enterprise seems like a great idea, as traditional EAI solutions are expensive, propietory and time consuming to implement (assuming web service enabling an application is quicker and less expensive). However, I just wonder whether issues like transactions, scalability and reliability can be addressed adequately by the web services model with today's technology and standards? This is where traditional EAI players excel (or so they claim), and they all tout web-services as more suitable for inter-company integration (B2Bi). Will be interested to hear people's experiences and views with using web services within an enterprise.

    Cheers
    James
  4. I totally agree with you. This is a fundemantal shift facilitated by XML and addresses the shortcomings of business objects.

    In my experience, business objects have been a dubious way of modelling the enterprise. For instance, i'm more interested in the interactions i have with a supplier rather than some generic notion of a supplier. The nature of such interactions are volatile (especially in a B2B world) and tend to change; synchronising business objects with such changes can be a nightmare.

    A set of fine-grained services - implementing specific business tasks- sounds a much more flexible architecture that can facilitate rather than undermine business change.

    Additionally, more often than not business, objects have led to non-scealable systems or stateless objects that simply act as logical binders for transactions. Increasingly, data comes out from data stores as XML and goes out to clients as XML. Relying more and more to standard XML techniques (XPAth, transformations etc) is becoming an appealing devlopmenty alternative that could accelerate bulding web services.

    What the shift highlights is the need for comprehensive web services management tools. And because these services represent elements of a business process, business process management becomes the new business object. One that acts as the binder for those services and determines their flow.
  5. Here is a good article "Web Services: The Economic Argument".

    Should we speak about "web services" or "xml services" ?
  6. Just some thoughts:

    I think the service-oriented architecture is THE thing for the future. Traditional markets have already proven the value of a service-oriented architecture, although nobody calls it that way. Traditional value chains, a market of suppliers, assembler, retailers and detailers, it's all there.

    The software industry is finally adopting this, by standardizing things like a system with roles (containers providers, component developers, assemblers, etc.) as specified in the J2EE specs. The software market is finally maturing and resembling traditional markets (that have proved the concepts) more and more, the service-oriented architecture perfectly fits in.

    While maturing to a traditional value-chain kind of market, the software industry will face major problems in my opinion. What are the boundaries of the different roles, who's responsible for what. My own experience is that for instance a integrator often does not fully understand yet what the strengths and weaknesses of a component structure are and how he should integrate the components, providing services to HIS clients. We're a component provider. Integrators often don't see how our components could be used in a business. One could show it by making a simple (for instance html or xml based) demo. But that's not what you want! These, I think are the problems while moving to a service oriented architecture. Seeing the benefits, knowing how to combine services, knowing where to set the boundaries...

    By the way, I think we should call it neither web services, nor xml services. Just s e r v i c e s. It perfectly fits in the component ides of for instance J2EE (or .NET, I haven't looked into it, and I probably won't). And whether or not it's accessible through the web, by an XML interface, bean-interface, connector interface, that's not what's wanted. The thing to do is making the services and making it possible to reach them, thus not specifying HOW to reach them.

    As far as the questions asked about reliability, scalability and ability to do transactions are concerned, I think that's all part of the maturing software industry. Probably traditional markets had the same problems. Maybe Philips attached the wrong power plug to their cathode-tubes thus making it Mitshubishi impossible to assemble everything to a TV.

    Alef Arendsen
    Senior Software Engineer
    SmartHaven
  7. Yes, Web Service is part of the future. However, web services should not live without applications.

    Service-oriented architecture is not new. Most of us have tried to build TP-monitor based systems (e.g. using TUXEDO). These systems were service-oriented architectures. The message format back then was for example EDIFACT. (EDIFACT is text based like XML, however, not so advanced as the EDIFACT technology dates back to the eighties).

    So what is new here? All right, a lot of new stuff is added, however, the old paradigm's problems still exist.

    One major problem with service-based architecture is that it focuses upon functionality. The services are built to suit business cases; this is in contrast to object-oriented paradigm where objects and classes are the primary focus point. By developing service-base systems we end up with services that are very alike, but servers different business cases (duplicated functionality).

    Now, how do we get around this? One way is to implement web services using applications. The applications could be build using object-oriented technologies, and the web services could then be a facade on top of the application. Thereby we keep the possibility of reusing the core structure of the business domain and at the same time support de-coupled application-to-application integration.


    Just another note:

    Using XML all the way from the database to the client, without having an object-model, is not a recommended solution for complex or large application. I know Microsoft recommends using XML all the way, but then is Microsoft really targeting large enterprise systems?

    /Erik Lund Jensen
    Cyber Com Consulting
  8. Erik, I agree with you. I was already begining to think that I was the only one who remembers that service-oriented architectures are nothing new. Perhaps the web services advocates should also take a look in the past and see what they can learn.

    I do not think that 'web services' have solved what I have considered to be the fundamental problem of service-oriented architetures. The fact that they are build upon functionality quickly leads into groups of stovepipes that are complex to integrate and where the abstraction level is so low that it is really hard to reuse them in unpredictable contexts. This integration is even harder if the underlaying infrastructure does not support sharing of security and transaction contexts between the applications. (Of course, if you are in the system integration business this is a good thing(tm).) If you want to provide services that work on higher levels of abstraction you quickly run into technical restrictions of XML-over-HTTP.

    I am a bit worried that many 'web services' advocates (especially microsoft) try to sell them as a solution for all the worlds problems. The web service have their use, but I do not think there is much point in trying to re-invent the things that have been defined in DCE, CORBA and EJB just because 'web services' are the hype right now.

    my $.25,
         -Joose
  9. I think that the point is missed when talking about service-oriented architecture just in terms of technology. The service-oriented architecture is a way of creating larger grained distributed facades on the network. The distributed facades wrap subsystems that represent some autonomous business concept.

    Web services implies a set of technology to implement this architecture (SOAP, UDDI, etc). But, the same architecture may be implemented using just about any technology.

    The merits of the architecture are clear, and outlined in patterns on this site. The greatest benefit is the reduction of coupling. By inserting the abstract interface between the clients and the subsystem implementation, dependendies become much easier to manage. By simplifying the management of dependencies, maintenance becomes easier and the unit of reuse becomes the service interface.


    Mike S.
    mike@mestevens.com
  10. yes but CORBA is very heavy weight - that is it needs significant runtime support. it will probably fill a need for a while - you are right though, this is a new way of doing SOA not a revolution but an evolution.

    also EJBs arent threatened by this either.
  11. Just started reading this thread which I think is a great discussion. A comment that I would make in response to your point Erik is that Services do not live 'on their own'. They need to be co-ordinated. In a traditional application world we can see 'applications' built around Business Process Management/ Automation which orchestrates the end-to-end Application via activity steps which call out to the required services.

    In a Web Services world these these are federated 'services' which are likely to be orchestrated via technologies such as IBM's WSFL or Microsoft's XLANG.

    The end result is the same but it is a different way of designing apps. Services become reusable by their process definition 'blueprint's which themselves are re-usable - no need for duplication.
  12. Hmmm...this sounded familiar, so I replaced "services" with "objects" and this is what I got:

    "A(n) object-oriented architecture is one where an organization's applications are decomposed into objects available on the network. Rather than building applications the standard monolithic way, an application is broken up into smaller, fine-grained objects."

    Sounds like what the CORBA folk have been talking about for more than a decade. I guess the reason web services is going to succeed where CORBA has failed is that everyone is actually going to agree on the protocols (and implement them in a standard way) this time around?
  13. In the Java app server world, there are two very exciting movements going on right now. One I think can be called "Instant J2EE" and the other is Java Web services.

    Instant J2EE is the ability to directly or reverse engineer a complete J2EE system from a UML/XMI model. There are at least four systems that have been announced in the past four days that can do "Instant J2EE" -- from Compuware, Sygel, Wakesoft, and Roaming Media. Each incorporate a visual user interface UML or IDE like TogetherSoft or Forte for Java. Each generate Java source for a JSP/Struts EJB layers and each emphasize design patterns. See Java Skyline: Web services for a list and categories of Web service enabling technologies for Java.

    Web services is more specific than just "XML" but also more general than just Java or J2EE. Service oriented architecture is probably a good way to look at it.

    In some ways I'd like to think the word "Web services" was not the best term. "Registered services" might have been better because that's largely what these systems are - services that are described and discovered in a registry. Also Registered services implies a more of a business orientation. However, there are those who believe that "Web services" should remain "simple" as would reflect standards that goes through W3C. I have no indication that they will, however.

    Have a great day.

    Regards,

    Rich Katz


     
     
  14. In the Java app server world, there are two very exciting movements going on right now. One I think can be called "Instant J2EE" and the other is Java Web services.

    Instant J2EE is the ability to directly or reverse engineer a complete J2EE system from a UML/XMI model. There are at least four systems that have been announced in the past four days that can do "Instant J2EE" -- from Compuware, Sygel, Wakesoft, and Roaming Media. Each incorporate a visual user interface UML or IDE like TogetherSoft or Forte for Java. Each generate Java source for a JSP/Struts EJB layers and each emphasize design patterns. See Instant J2EE with design patterns.

    This looks like good news, and for once the Gartner Group seems to agree. If the Instant J2EE move is effective, it may make it possible to more easily evolve business systems by adding to their design so that users and vertical applications do not become trapped or thwarted by architectural challenges.

    And now on to the challenges - because at the same time, we are seeing Web services evolve. For Java/J2EE there are a number of flavors of Web service enabling technologies. The simplist involves making a J2EE server available as a simple stateless Web service.

    This seems simple -- but a better description is more like "simplistic." The JSP/servlet layer is very robust and capable of far more than just stateless connection. And in the Web service world, stateless doesn't always provide enough interactivity or answer all the questions.

    There are loads of questions. In fact, if you went to Web Services Edge you found a lot of people who had more questions than there were answers. And rightly so. "Edge is the right word because the technology is just on the horizon.

    And you can still have some effect on how Web services goes. Organizations like OASIS and W3C are still evolving what Web services will be. As one person from Systinet noted, there's no Marshall MacLuhan of Web services yet to suddenly interrupt your conversation like in Annie Hall and correct you: "No! You don't understand what I meant! That's not what Web services is!..."

    Server applications and J2EE will be major players in Web services, but Web services isn't just an add-on for J2EE. It's a whole new many-centered way of thinking that emphasizes WSDL (Web services Description Language) and other UML forms as models. Web services has a whole new set of non-J2EE terminology including: contracts, leasing, choreography, itinearies, and remote services. And there is a whole set of business practices and registration to evolve like service agreements and service level agreeements and ways of addressing best (and permissible) business practices.

    And there are many roles to play in Web services -- registries that qualify web services, service managers that combine and manage external and internal service components, portals that manage services and user interface, and business process integrators. See Java Skyline: Web services for a list and categories of Web service enabling technologies for Java.

    Web services is more specific than just "XML" but also more general than just Java or J2EE. Service oriented architecture is probably a good way to look at it.

    In some ways I'd like to think the word "Web services" was not the best term. "Registered services" might have been better because that's largely what these systems are - services that are described and discovered in a registry. Also Registered services implies a more of a business orientation. However, there are those who believe that "Web services" should remain "simple" as would reflect standards that goes through W3C. I have no indication that they will, however.

    Have a great day.

    Regards,

    Rich Katz


     
     
  15. i know this is going slightly off topic, but doesnt the UML that most people know contain limitations that dont allow sophisticated "instant j2ee" - for example except for the latest spec UML doesnt allow describing the temporal domain.
  16. Service based architecture is probably most interesting for large internal corporate sites where there are many development projects. This can greatly reduce duplication of development efforts across the organization and lead to a more centralized model.

    While a simple public remotable api approach may seem to accomplish the same thing, in a large organization there are so many projects that it's hard to get reuse. However, in following and setting up a standard for both the service, and the data exchange, service based approaches make reuse more approachable.

    The key is to set solid standards and centralized concepts for the organization. I don't think that simply adopting a technology like XML or SOAP is nearly strong enough to ensure consistency. This becomes especially clear in the case of cooperative id management.

    I wonder how service based architecture will complement workflow based architectures such as tibco and MQ? Any thoughts on this?