none
Is SOA merely becoming WebService based integration? RRS feed

  • Question

  • Here is what wikipedia's definition on SOA...

     

    SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. The aim is a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. SOA separates functions into distinct units, or services, which are made accessible over a network in order that they can be combined and reused in the production of business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA concepts are often seen as built upon, and evolving from older concepts of distributed computing and modular programming

     

    It resembles mostly to what other definitions of SOA.

     

    But, in the recent years, the companies that I am working or worked before, SOA tends to become more of a webservice based integration.  Dont know if it is good or bad.  But what to poll the community and find out what you guys have seen in your SOA implementation experience.  Is it moving beyond webservices (WSDL and REST)?

     

    A recent note from Microsoft Burley Kawasaki [Director of Product Management, Microsoft Connected Systems Division], full note at TechTarget

     Microsoft wrote:

    Our approach has certainly drawn both attention and criticism. The critics generally assert that the Microsoft SOA strategy revolves around Web services and lacks sophistication. In part, that is correct. We are driving Web services because they are as useful as they are ubiquitous. Regarding sophistication, we rarely meet customers (even those in the Fortune 100) that ask for additional complexity. They want us to do what we do best – make hard problems simple through productive tools and run times.

    A note from Zapthink that is slaming microsoft calling it as inadequate at TechTarget.

     Zapthink wrote:

    Microsoft misunderstands a key technology trend and therefore is ill-equipped to take advantage of it. It would be one thing if Microsoft was still struggling to understand SOA in 2002, when we were still in the nascent years of SOA definition. But this is now 2008. SOA is now well developed as a concept. To continue to tie SOA to the concept of "connections" is immature, inadequate, incorrect, and misguided. Microsoft needs to pioneer and take advantage of the true opportunities that SOA offers by shifting the conversation past Web services and focusing on enabling location, technology, and process neutral composition of services in an environment of continuous change—the vision of SOA.

     

    So, what is your take on this?  I have to agree with Zapthink that Microsoft's short-coming of SOA shows here, although real world implementations have been targetted towards webservice.

Wednesday, July 9, 2008 6:06 PM

Answers

  • Gartner report in 2007 still puts microsoft in niche/challenger rather than leader/visionary...  Here is what they had to say about MS "cons"

     

     

    Microsoft's overall SOA message is weak and well behind its competitors. Despite some high profile partnerships with SOA governance technology partners, the Microsoft SOA governance "story" is still unclear.  MS is heavily relying on WCF to enable SOA.  There hasnt been widespread use of WCF and the plan b (BizTalk in conjuction with SOA Software) doesnt connote MS overall SOA governance strategy.
    Thursday, July 17, 2008 4:26 AM
  • Again I agree with much of the last posts.. Just because you use REST or choose to expose *a* service via REST doesn't preclude you from being considered for use in an SOA. Now if that service itself uses SOA, then great, if it doens't then oh well. Doesn't prevent you from using it just that you have to consider the implications of how you might expand that service in the future. For me this is one of the SOA gotcha's in that it's a set of ideas not a prescribed list of features or technologies. But for many it has becomes such as list.

    Wednesday, August 20, 2008 12:37 PM

All replies

  • For me Microsoft has taken the, "we'll give you the plumbing and the tools" approach which I think is pretty good. Others provide specific tools such as ESBs but again that isn't SOA that's "just" another tool you may choose to use.

    Thursday, July 10, 2008 7:32 PM
  •  

    It's my own view that microsoft has indeed provided the plumbing, but the trail goes cold after this.

     

    I have spent some time looking for implemented .Net SOA examples, but they are a bit thin on the ground, outside of the promises made by numerous book authors. Any other examples have ben so simplistic that I struggle to see the SOA relevance at all.

     

    It surprises me that Microsoft does not have more official guidance on joining up the dots it provides into a complete SOA implementation, at all levels from simple proof of concept through to full enterprise systems.

     

    Cheers,

    Steve

    Tuesday, July 15, 2008 1:05 PM
  • SDM, I kinda' agree and disagree. One of the big problems with MS is they in their haste to give us a lot of information you end up with a flood of resources and you can easily miss the interesting ones or even the core message they're originally attempting. For me their concept (one that is now very hidden) is whatever you write should "scale". I.e. whatever you write should be able to participate in a SOA. WCF & WF help with this approach. So taking something very simple such as getting the size of a string. You can write this as service using fast binary protocols therefore allowing it to be used pretty much like any utility function you'd write in a non-service way. However, by changing the protocol you alter the visibility. By using WF to glue processes\services togethers you can create a whole bigger than its parts. Obviously this is pretty vague and still requires a lot of work to make this happen in practice but that's my take on the core SOA message. Sure there are lots of others issues but the tools that are out there (or soon to be) are making inroads to helping. Even technologies not directly associated with SOA help, e.g. LINQ helps to bring disparate data together. Companies such as Oracle tend to offer an almost pre-canned SOA solution which is fine. Whereas MS offer a more flexible mechanism but more of the responsiblity is on the development. Now is that by design or not I'm not sure!

     

    Tuesday, July 15, 2008 1:21 PM
  • MS have given us some very productive developer tools and a basic framework that allows us to go and build pretty much whatever we want.

     

    I guess that I would like to see what the MS vision for coupling its huge array of technology together is, within the SOA arena, and what developers would be expected to code versus off-the-shelf components, such as BizTalk, UDDI services etc.

    Tuesday, July 15, 2008 1:36 PM
  • This is where I worry about MS offerings. Is it going to be Biztalk in some cloud guise (such as the ISB) because it's a good idea or because they're still flogging the Biztalk horse?

    Tuesday, July 15, 2008 1:40 PM
  •  

    BizTalk is not cheap. What about the little guy? In MS-world, are the SMEs expected to roll their own framework services before they can begin to think about SOA or will they end up developing some kind of half-way house that never achieves the original aims of SOA?

     

    This is the stage I am at: Trying to decide how to best implement a .Net MS-world SOA architecture without the expense of  heavyweight MS components, such as BizTalk.

     

    Going back to the OP, I don't think SOA is becomming WebService based integration. I do not think that the inter-process connectivity is the issue, it's all the ancillary copmponents for service discovery, versioning plus the patterns & practices to support SOA principles such as autonomy etc. It's my personal opinion that these are the issues facing the .Net SOA community at the moment.

    Tuesday, July 15, 2008 2:08 PM
  •  pkr2000 wrote:

    Companies such as Oracle tend to offer an almost pre-canned SOA solution which is fine. Whereas MS offer a more flexible mechanism but more of the responsiblity is on the development. Now is that by design or not I'm not sure!

     

     

    Oracle or other players in the market provide out of the box tools and also different development mechanisms.  They are more strong on the toolset.  Agreed.  But why MS is admitting SOA to be just glorified WebService based EAI...  WebService is a subset of the toolset to achieve SOA. 

     

    For example,

    what if there is a large volume of data like 10000 rows needs to be exchanged between two loosely coupled system, would we use Webservice based endpoint to exchange the data?

    what if we need to expose a mainframe CICS transaction participate in a transaction between loosely coupled system...  even though we have 3270 based bridge available, it is not typical to use it for a webservice based integration or I would say it is not mature yet...

     

    If webservice is the way to go, then we could call it as WEAI (WebService based Enterprise Application Integration).  SOA comprises of EAI but not another name for EAI...

    Wednesday, July 16, 2008 2:07 AM
  • I'm not sure where the 'admits it's web service' comes from. As I mentioned I believe the strategy is about end-points but where MS, IMO, is far better than Oracle is that WCF allows the transport to be configured. In my previous example I talked about been able to move from fast binary transport to web service via configuration. So in your mainframe example you can configure the end-points to use a fast transport. WCF does not require a web service.

    PS. I saw a nice quote about SOA, now I bet I'll muck it up but it went something like, "SOA defines the how, EDI defines the when".

    NB. I should say that it's been over a year since I last looked at Oracles offering so I might be doing them a disservice.

    Wednesday, July 16, 2008 7:15 PM
  • "is far better than Oracle is that WCF allows the transport to be configured"

     

    ESB products can do the same what WCF does out of the box...  hide the implementation behind the esb and allow different endpoints...

    Thursday, July 17, 2008 2:40 AM
  • Gartner report in 2007 still puts microsoft in niche/challenger rather than leader/visionary...  Here is what they had to say about MS "cons"

     

     

    Microsoft's overall SOA message is weak and well behind its competitors. Despite some high profile partnerships with SOA governance technology partners, the Microsoft SOA governance "story" is still unclear.  MS is heavily relying on WCF to enable SOA.  There hasnt been widespread use of WCF and the plan b (BizTalk in conjuction with SOA Software) doesnt connote MS overall SOA governance strategy.
    Thursday, July 17, 2008 4:26 AM
  •  GajaKannan wrote:

    "is far better than Oracle is that WCF allows the transport to be configured"

     

    ESB products can do the same what WCF does out of the box...  hide the implementation behind the esb and allow different endpoints...



    In theory yes, but when I attended Oracle ESB seminar last year they couldn't change the underlying protocol, you had to implement versions of the service for each protocol you wanted (crazy and I told them so).

    re: Gartner, well apart from I take their reports with a fistful of salt, so what's the problem with WCF? What is SOA? The ability to construct a better business process by cherry picking and orchestration of previously disparate services? So does writing a Service that can play in SOA require the service to implement orchestration mechanisms - I'd so no. What I'm trying to say, is that even if you require an ESB to be SOA organisation + even if you ignore MS (and it's partners) ESB offerings then you can still use anyone else's platform to orchestrate services written on a MS platform - surely the services will be implemented by many vendors too? OK so I'm defending MS here, an truthfully I do think they need a better ESB out-of-the-box than Biztalk but I think we have to be careful not to define SOA by the presence (or not) of an ESB.

    As a slight aside have a quick read (again) of Connect Enterprise Apps With Hosted BizTalk Services which perhaps indicates MS' roadmap including attempting to address the crazy costs of Biztalk.



    Thursday, July 17, 2008 6:57 AM
  • Very interesting discussion folks. Thanks..

     

    Saturday, July 19, 2008 4:35 PM
  • Since, I started this thread, should keep it alive when ever I stumble across new information right... Smile  So here is something new from InformationWeek.com/ August 11 edition that compares SOA as a Sport Utility Vehcile and WOA as small compact car,

    http://www.informationweek.com/news/software/soa/showArticle.jhtml?articleID=209904293

     

    In may be just that, MS is making their bets on the right way...  Are they working on something similar to XML Gateway appliance?  That would help MS make their message clear to the community and analysts...
    Monday, August 18, 2008 6:03 PM
  • I'm not sure I buy the WOA vs SOA thing at all. I don't see that REST et al are non-SOA, perhaps it's just me? Sure you can argue about all the "red-tape" that you've missed out but if you expose a service then I think you've a strong argument for saying you've got a SOA. WDYT?


    Tuesday, August 19, 2008 7:40 PM
  •  pkr2000 wrote:
    but if you expose a service then I think you've a strong argument for saying you've got a SOA. WDYT?


    not really though.  exposing a service does not make it SOA...  It is one way of achieving SOA...

    Wednesday, August 20, 2008 2:50 AM
  • I agree that you've not implemented all the red-tape/goodness you'd expect but there is nothing stopping you using those techniques in a SOA. If was to arch' an SOA in a agile way then unless someone wanted something like a configurable way to change the services then I wouldn't supply it. Doesn't preclude me from adding it later neither would it make my Arch less SOA?

    Wednesday, August 20, 2008 11:17 AM
  • I thought that SOA is also about how systems are aligned to business areas, hence the focus on services.

     

    It seems to me that technologies like biztalk, web services, Rest, http et al, support the soa approach but a system that utilizes any of these technologies isn't necessarily SOA.

     

    An analogy is object oriented programming languages;  It takes more than simply using C# to claim a system is object oriented because I can easily produce procedural code with this tool.

     

    So isn't there more to soa than just the tools and technologies that enable and support this approach? 

    Am I mistaken about the business alignment of soa?

     

    Wednesday, August 20, 2008 12:29 PM
  • Again I agree with much of the last posts.. Just because you use REST or choose to expose *a* service via REST doesn't preclude you from being considered for use in an SOA. Now if that service itself uses SOA, then great, if it doens't then oh well. Doesn't prevent you from using it just that you have to consider the implications of how you might expand that service in the future. For me this is one of the SOA gotcha's in that it's a set of ideas not a prescribed list of features or technologies. But for many it has becomes such as list.

    Wednesday, August 20, 2008 12:37 PM
  • Since REST uses an xml document you can publizise the interface and hence you are a service oriented architecture however it is not a WS_ compliant architecture. So the end result is you benefit from the architecture but not the easy sharing of information .

     

    Agree on the list but im glad its not a list ,if we HAD to support UDDI /WS-Eventing/WS-Policy etc it would leave very little scope for inovation such as the use of REST with WCF2/3.x soap over tcp and udp etc.

    Friday, January 9, 2009 11:58 AM