Principles of SOA, and how to incorporate business analysis

Discussions

News: Principles of SOA, and how to incorporate business analysis

  1. SOA author and trainer Thomas Erl has put together two SOA tips series for SearchWebServices.com. One is on the principles of SOA. It lays out the groundwork for how to structure services and how to organize an SOA, delving into service contracts, loose coupling, service abstraction, reuse, service discoverability, statelessness and service layers. The business analysis and SOA series digs into business service models, entity-centric business services, process-centric services, the SOA delivery lifecycle, agile service delivery and service modeling. It covers how to tie service creation to business processes. He has also included a list of the five greatest pitfalls to SOA adoption. Have you been building your apps differently (e.g. more loosely coupled) over the past year or so? Do you think agile service delivery and working more closely with business analysts stand to improve development or will it just create more roadblocks

    Threaded Messages (8)

  2. Entity-centric business services? Separated Invoice and Customer services? Is software engineering back in 60's again? http://www.enterpriseware.pl
  3. Pitfalls of SOA[ Go to top ]

    The author had a list of the top five pitfalls of SOA but I have some of my own ideas. First and foremost is that SOA (via SOAP which seems to be the defacto standard) is painfully, painfully slow. In production environments I find people often using hardware to handle parsing and validating in order to make systems functional. Given that we were successfully doing RPC in the 80s and the machines and networks we have are two orders of magnitude faster, this seems alarming. Second, SOAP/XML is supposed to be easy. People talk about how great it is that XML is so simple and easy to read. CORBA was much too complex they say. Anyone holding this belief has never had to deal with XML namespaces and versioning SOAP services. The resulting mess might as well be binary. And once you add all of the stuff you need for a 'real' system like transactions, security, etc. you end up with a slow version of CORBA, RMI, or DCOM. Third, did I mention that SOAP was slow? Fourth, SOAP is so immature that it's hardly even usable for a hard core production system. The specs for transactions and security are immature and largely unsupported. Fifth, the tools are not good. It seems like every time I try to generate objects/stubs from a WSDL using something like AXIS it can't seem to parse the file. Look at any of the user groups for these SOAP tools and you'll see thousands of messages complaining about this. Tools like RAD handle this well but are $$$.
  4. Re: Pitfalls of SOA[ Go to top ]

    <In production environments I find people often using hardware to handle parsing and validating in order to make systems functional. Given that we were successfully doing RPC in the 80s and the machines and networks we have are two orders of magnitude faster, this seems alarming.</blockquote> SOA is intended to be used for loosely coupled services. If someone finds that two software components exchange MBs of XML messages per second maybe it is about time to ask the question: are those components REALLY loosely coupled?
  5. SOAP web services a pain[ Go to top ]

    I haven't had a good experience using SOAP web services either. Consuming them isn't too bad using wsdl2java but as far as deploying them goes, it's been a nightmare for me. I don't really see much value in them and I believe they're simply over-hyped. I'm a much bigger fan of REST web services. They're simple and intuitive and get the job done. http://developer.yahoo.com/search/rest.html http://www.flickr.com/services/api/request.rest.html Powerful doesn't have to mean complex.
  6. Re: Pitfalls of SOA[ Go to top ]

    SOA is intended to be used for loosely coupled services.
    Lets spell out “S”service “O”riented “A”rchitecture. Are you saying that tightly coupled services are abomination? I do not thing so. Service orientation is very solid and mature architectural and implementation concept that is applicable at low level as well as very high level. Unfortunately at this moment SOA is synonymous with crippled and impaired XML based implementations which piggybacks Service Orientation concept and compromises it. Thomas Erl’s book “Searvice Oriented Architecture” is a good book, especially if read carefully, it is scary! Because it gives pragmatic advices like this one (with warnings of course): in some cases you might need to create custom XML parser and XSLT processor. Wow! That is hones piece of advice (kudos Thomas) but that seems too much for a ‘mature’ stack of technologies that is based on premise of ‘shared and common XML parser that nobody needs to reinvent’. Other honest advices in Thomas book show that it is very common to misuse and abuse XML therefore XML does not look as very attractive platform for IT foundation. Scattered throughout the book reminders that services have to be stateless and if there is need to maintain state it has to be done some place else. Hmm, looking at the software around me I would say that in many cases it is very advantageous to be statefull: just look at the hurdles every web framework goes through to maintain state of conversation. True SOA should explicitly support statefullness (see ICE and CORBA for reference implementations). How about explicit versioning support? Again the problem is NIMBAY (no in my backyard) – XML based frameworks shift the burden to the developers. ICE at least attempts to solve that http://www.zeroc.com/iceVsCorba.html JINI has its ways too ( See this years JavaONE presentation by Brian Pontarelli http://brian.pontarelli.com/2006/06/29/my-javaone-session-review/ What I want to say is this: please please please do not confuse SOA with XML impaired implementations of the concept. There are some sound alternatives well worth exploring: - Jini as in GigaSpaces ; - ORACLE Fusion initiative (inclusive: Grid (Data and Computing) based with BPEL XML add-on); - Gemstone Grid based SOA: http://www.gemstone.com/solutions/soa.php
  7. First and foremost is that SOA (via SOAP which seems to be the defacto standard) is painfully, painfully slow."
    i've seen it be slow, but you must be doing something wrong if it's *that* slow. i worked on a project that used java and soap way before "soa" became a hot topic to replace and existing system that was written in c and basically soaked up all the cpu on a 16 cpu mainframe machine. we reduced it to about 50% cpu across 2 cpus and the business finally managed to process all their data during peak loads (which they never could with their c based system). anyway, we had zero problems with speed with soap. and that's not to mention that soa also incorporates web services, with "web" being the operative word there. web = slow. people don't expect it to be super fast (thought that expectation is changing gradually).
    Second, SOAP/XML is supposed to be easy. People talk about how great it is that XML is so simple and easy to read. CORBA was much too complex they say. Anyone holding this belief has never had to deal with XML namespaces and versioning SOAP services.
    it really isn't that difficult! and if you're really struggling to edit your xml in notepad then you should get yourself a nice gui. there's plenty out there for free and of course with commercial cost.
    Third, did I mention that SOAP was slow?"
    see above
    Fourth, SOAP is so immature that it's hardly even usable for a hard core production system. The specs for transactions and security are immature and largely unsupported.
    that's an incredible thing to say given that soap has been around for years and is used all over the place.
    Fifth, the tools are not good. It seems like every time I try to generate objects/stubs from a WSDL using something like AXIS it can't seem to parse the file. Look at any of the user groups for these SOAP tools and you'll see thousands of messages complaining about this. Tools like RAD handle this well but are $$$.
    i've always said, you get what you pay for. i've never had any problems with axis myself (the project mentioned above used it), but i can understand that some people might struggle. if you paying for a tool, you expect it to work, if you're not then you have to muddle on as best you can with whatever documentation/support is available. now don't get me wrong, i'm not a huge fan of soa, it just sounds as though you must have had some tainted experiences with it (and the technologies involved) in the past.
  8. that's an incredible thing to say given that soap has been around for years and is used all over the place.
    It depends on what you call maturity. Perhaps you call Entity Beans 3 to be mature technology. I do not despite they are around for many years. SOAP has very good name and it lives up to it: soap frameworks are still not quite interoperable http://www.w3.org/2002/ws/addr/testsuite/report/ As a level of immaturity we can point at the speed of changes in the area, all the WS* ‘standards’ which change on daily basis and still IMO do not address needs of developers in the area.
    existing system that was written in c and basically soaked up all the cpu on a 16 cpu mainframe machine. we reduced it to about 50% cpu across 2 cpus and the business finally managed to process all their data during peak loads (which they never could with their c based system). anyway, we had zero problems with speed with soap
    Hmm, you had extremely badly written system so what? Anything more decent will be a relief. It does not mean however that that replacement is ‘good’ on the grand scale. For example: if someone replaces steam engine powered car with Ford model T that surely will feel good (in comparison). But that does not mean that Ford T is comparable to Toyota Prius or Jeep Wrangler.
  9. Thomas Erl's principles are concise and easy to follow which is a plus and I find them to be generally sound principles for distributed computing. I would expand on the principal of contracts and describe this as a service description where a service description encompasses service reachability, service functionality, policies, contracts, information model, and a behavior model. I would distinguish a policy from a contract, policies tend to be permission oriented and contracts tend to be obligation oriented. This puts the term contract in compliance with the way contracts are typically applied in the legal world. Security and trust models also become an important aspect of interoperability of SOA services in a majority of SOA environments, so security (confidentiality, integrity, authentication, authorization, non-repudiation) would be an additional prinicpal I would add to the mix. Danny http://www.soamodeling.org