SDA India is an online resource for Software, Development,IT, Architecture, Open Source, Mobile, Security, Databases, Delphi, C, OS, Asp, .Net, Php, Xml, Java
Planet SDA-India
Conceptually, I like both Service Oriented Architecture (aka SOA) and Software as a Service (aka SaaS). However, I think we've done the industry a disservice by overloading the term "service".
I read a blog post last week that brought up a simple question - What is a service (in SOA terms)? I have faced a huge amount of confusion over this question throughout the last two or three years, so I decided now was the time to get the answer down in writing! The answer, of course, is that SOA services are BUSINESS services, representing individual business operations. They are not web services. They are not IT programs. In fact, if only we could get the nomenclature straight the confusion probably wouldn't have arisen. My view is to call IT objects such as programs or transactions 'components'. SOA services are made up of components orchestrated together to deliver the particular business function. On top of this, SOA composite services can orchestrate together a mixture of components and SOA services.
The retro-encabulator (aka turboencabulator). Via Deal Architect. Absolutely hilarious. How did this guy memorize his lines? Here's a little of the amazing history of this spoof.
SCA/SDO goes to OASIS, could be to SOA what Java EE was to n-tier ...
Haleh Mahbod
| Link to this blogBlog by Haleh Mahbod
First, SOA does need a common user interface. One of things that are difficult when explaining the value of SOA is that there is no standard way to externalize the value of services, we instead do so using many eclectic ways depending ...
Some recommended reading (more to come). An Overview of Service-Oriented Architecture in Retail http://msdn2.microsoft.com/en-us/library/bb264584.aspx Building Composite Applications Using the Microsoft Platform ...
As I highlighted recently on ZDNet, 48% of CIOs will be looking to actually start using their SOAs to connect to external partners this year. Unfortunately, we've been building landscapes of Web services for quite a few years now and for many, the tipping point for SOA adoption seems as elusive as ever. While trying to understand why this is, one common explanation I offer is that the A in SOA is often missing. When you ask server-side developers in a given organization what they are developing, they usually say Web services. When you talk to architects in the same organization, they usually say they are building SOAs.
