locked
What would you consider as SOA? RRS feed

  • Question

  • During a conversion with someone from marketing it became clear to me that we had a very different idea of what SOA is. I realise that it doesn't really mean anything these days but I was wondering what everything thought. So my question is, if I was to write an application and said it used SOA what would expect from it?

    Saturday, October 27, 2007 9:13 AM

All replies

  • I think it would be helpful to have an accurate definition of SOA.  I like the definition provided by Dunelm.

     

    -----

    From Dunelm - Glossery of Terms

     

    Service Oriented Architecture (SoA). A Service-oriented Architecture defines how two or more entities interact in such a way as to enable one entity to perform a unit of work on behalf of another entity. The unit of work is referred to as a service, and the service interactions are defined using a well-defined description language. Each interaction is self-contained and loosely coupled, so that each interaction remains independent of any other interaction. While SOAP-enabled Web Services are the most common implementation of SoA, Web Services are not necessarily required to define a SoA. The protocol independence of SoA means that different consumers can use services by communicating with the service in different ways. Service Orientation is a method of architecting systems of autonomous services. Services are built to last, with good availability and reliability, and systems are built to change, with new service topologies evolving over time.

     

    ----

    With this definition in mind we see that for an application to use SOA, there must be a system maintaining a set of business services as described above.  If you do not have this system set up, or you are not making requests from such a system set up by a third-party, then you are not using SOA.

    Sunday, October 28, 2007 4:16 AM
  • Hmm, I'm not keen of trying to define SOA as I don't believe such a definition exists. If I write a stored procedure to add a name to a table then that qualifies as SOA according to that def', and perhaps that is valid, although I doubt that is what you're suggesting. What I'm asking is what would you *expect* from the application? E.g. Is it good enough to merely publish an FTP site for you to download an xml request to and have that processed, afterall it's providing a service, or would you expect something else? Would you expect request/response pattern, would you expect to be able cherry pick specific services or is one facade service good enough? Perhaps I should present a more concrete example. E.g. I write an expense claim system. Usuall stuff, rules about who has to sign off and at what value they can sign off before going to someone else, eventually the claim is rejected or accepted. Now I could expose a simple SOAP (just to keep things simple) service that is SumbitClaim(Claim) and say my system is using SOA. Would that be what you'd expect from an application claiming to be SOA? I don't want to lead the readers but IMO exposing a few services does not an SOA make. It's more about what (and how) services are used through out the processing of the claim, and how you can configure the application to use different services should the business case arise, i.e. a set of services configured to work together to solve a business problem. WDYT?

     

    Sunday, October 28, 2007 8:44 PM
  • My friend,

     

    In response I will stick primarily to examples of what we are doing in my own company.  I would also like to read of how other companies are approaching this task as we have a lot of room for growth. 

     

    Hmm, I'm not keen of trying to define SOA as I don't believe such a definition exists. If I write a stored procedure to add a name to a table then that qualifies as SOA according to that def', and perhaps that is valid, although I doubt that is what you're suggesting.

     

    You’re right.  I’m not suggesting this sort of example.  SOA, in my opinion, is about providing ease of access to "business" services.  SOA is also about flexibility around those "business" services.  A stored procedure, of this sort especially, has a very technical purpose that does not resolve a specific business issue.

     

    What I'm asking is what would you *expect* from the application?

     

    What I would "expect" from an application that claims to use SOA is the same as I would expect from any other application that displays information in some way.  But, from my experience, which is still being molded, the difference from an application utilizing SOA and an application NOT utilizing SOA is  the SOA.  I agree that the use of SOA is more about how the services are used, but not necessarily what services are used.

     

    Surely, you can implement business services in a stored procedure, or in any other language.  However, the amount of complexity that goes into being able to update or delete a stored procedure to change it as a service for businesses is very high.  Also, a stored procedure is built specifically to exist within database.  Sometimes, depending on the nature of the SQL implementation, the stored procedure is built to interact with a specific database.  This situation can also be seen in righting code for any other specific language.

     

    SOA implementations are not such as this.  SOA implementations do not depend on a particular technology.  In fact, a good SOA implementation should be interchangeable with another SOA implementation.  You should be able to have your SOA set up, torn down and recreated without affecting the client.  If you have a SOA system attached to a particular URL then you should be able to completely replace that SOA system with another SOA system. The client applications should never know the difference.  This would be because you have the new SOA system bound to the same URL and using the same requests and responses as the old SOA system. This is one of the things I would expect from a SOA implementation in terms of flexibility.

     

    E.g. Is it good enough to merely publish an FTP site for you to download an xml request to and have that processed, after all it's providing a service, or would you expect something else?

     

    The answer to this question depends upon the need of the organization.  If the organization has a need to submit a request and recieve a response via FTP to the SOA system, then having an FTP site to provide such an interface is a very good thing.  However, I want to stress that in my own experience the SOA system is not about the FTP interface.  The SOA system and its business processes should work the same regardless of the interface.  If you have a SubmitClaim request you should be able to submit that request via the FTP interface into your SOA system.  You should also be able to submit the same SubmitClaim request through and HTTP interface.  The SOA system that we use allows us to create many different interfaces.  None of these affect the underlying business process(s).

     

    Would you expect request/response pattern, would you expect to be able cherry pick specific services or is one facade service good enough?

     

    In our implementation we do use a request/response pattern.  We don’t have our applications subscribing for updates.  In fact, I’m not entirely convinced subscriptions of this sort can be done.  However, I would like someone to describe how such subscriptions can be done as that would be a very powerful design. 

     

    We do have a SOA system that allows for both the cherry picking of specific business services as well as a façade service.  This design works as follows.  We have a single URL that we can post messages into.  This URL submits messages into a Command Process, which is an implementation of the Command Pattern.  The Command Process examines the message for validity, user authentication and authorization, and intended business service.  Once these things have been determined the Command Process forwards the message on to the intended business service and awaits the response for reply to the client and post processing.

     

    So, in a sense, we have both the ability to cherry pick specific business services and a façade service.  In the message we specify which business service the message is bound for.  Then, the message is posted to the Command Process and the message is routed accordingly.

     

    Please continue to discuss these things with me as I am very interested to know what other developers and architects are doing in this area.

    Monday, October 29, 2007 6:30 PM
  • Thanks for the reply, as I've said I don't believe there is right answer so thanks for sharing your views.  (To be picky though I wouldn't say that an SOA system is at the end of a URL rather a service is at that end-point which is part of an application using SOA). What I got from your answer is that you'd expect;
    1. Transport agnostic end-points for services
    2. Preferably Services using Request/Response
    3. The ability to cherry pick services, preferably without changing the client





    Tuesday, October 30, 2007 7:08 AM
  • The way I see it SOA is an architectural style that puts emphasis on interfaces and autonomous components - however there's a lot of ambiguity around SOA since vendors and others push it in thier directions. Another source of ambiguity is what I call "SOA initiative" which is the business move to build an Enterprise on SOA's principles

    You can read a little more about it both in my blog http://www.rgoarchitects.com/nblog/2007/10/05/WhatIsThatSOAThingyAgain.aspx

    and in the following paper : http://www.rgoarchitects.com/Files/SOADefined.pdf

     

    Arnon

    Thursday, November 1, 2007 10:28 PM
  • Quite so, hence my question...so what would you require from an application reporting to be built on a SOA?
    Friday, November 2, 2007 12:34 PM