"We didn't start the fire ... it was always burning since the world's been turning ..." [Billy Joel 1989]. Is SOA the "Same Old Architecture?" or is it "Simply Over Ambitious?" Let's apply SOA's arsenal:: XML, BPM, Services, SOAP, Web Services - to the real world and find out. Let's put out some fires.

« July 2009 | Main | September 2009 »

August 23, 2009

REST and SOA – the compatible duo

by Goutam Mukherjee

REST has made huge inroads into the Services space in last few years. It has become a very popular style to define how the Service Interfaces are designed and how the Services are accessed. Since SOA is also all about "Services", it is obvious that there will be an inclination to draw some correlation between REST and SOA and rightfully so. Sometimes that does open doors for some confusion and you start asking questions like “Am I not implementing SOA if I adopt REST style?” or “Does REST have inherent support for SOA?” or “Is REST the next level to attain after SOA” or even “Has SOA given way for REST?” and so on. So it does make sense to try to understand these two concepts and try to correlate the two.

Let's now have a quick look at what are the basic SOA principles. SOA comprises of a collection of Services and those Services conform to some basic principles. As Thomas Erl has outlined in http://www.soaprinciples.com, the basic SOA principles are –

  • Standardized Service Contracts
  • Service Loose Coupling
  • Service Abstraction
  • Service Reusability
  • Service Autonomy
  • Service Statelessness
  • Service Discoverability
  • Service Composability

 REST – Representational State Transfer – is an architectural style. The basis of the REST style is that you define the resources for your application and then use the standard HTTP methods to perform the state changes to those resources. Some key features of the REST style are –

  • Unique identifiability of the resources through URIs
  • Uniform interface to access the resources
  • Navigability of the resource representations through hypermedia
  • Statelessness

 Now if we see at the key features of the REST style, each one of them does map to one or more SOA principles. For example, “uniform interface to access the resources” maps to standardized Service Contracts, Service Loose Coupling and Service Abstraction. Except for one SOA principle – Service Discoverability – that is not directly covered by the REST features, all other basic SOA principles are realized by one or more REST features.


So now let us try to correlate the two. As defined in Wikipedia, REST is "a style of software architecture for distributed hypermedia systems such as the World Wide Web". Also we have already seen that the features of REST are very much compatible with the basic SOA principles. So we can draw the correlation that REST is an architectural style that inherently helps to attain some of the basic SOA principles and this is even more a perfect match when you are designing SOA under the constraints of "distributed hypermedia systems”.

 

Posted by Shubhankar Sumar at 05:26 PM | | Comments (2) | TrackBacks (0)

August 09, 2009

My 30 seconds lift speech on when to virtualize SOA solution and when not

by Murteza Salemi

To optimise your SOA benefits take the next step and virtualize. Virtualization is the abstraction of hardware/infrastructure resources (network, disk, memory, etc.).

Virtualize your SOA solution when you want to further:

  • Reduce capital expenditure on hardware and infrastructure
  • Reduce operation expenditure and the number of staff required to operate the enterprise applications.
  • Go green and reduce power reduction
  • Increase high availability and business continuity by reducing downtime and recovering quickly from unplanned outages with the ability to back up and migrate entire virtual environments with no or minimal service interruption.
  • Implement corporate governance through a consolidated hardware and networking infrastructure.
  • Reduce provisioning times for defining hardware configurations based on enterprise requirements and corporate governance.
  • Reduce the need for new hardware and the number of existing hardware
  • Improve the use of existing hardware through, for example, defining a server consolidation strategy.
  • Prevent applications from impacting each other when upgrades or changes are made, for instance, running different versions of an application on the same physical server.
  • A reduction in security risks to the overall computing infrastructure is achieved by isolating externally facing server applications in specific virtual machines.
  • Compliance with the disaster recovery plan and SLAs required for hardware infrastructure and services to be quickly re-configured in the event of a catastrophe.
  • Maximized use of hardware and computing infrastructure simplifies server provisioning and system scaling. For example, new hardware could be rapidly configured to accommodate high peak.

Don’t virtualize your SOA solution when:

  • Requiring high performance (high bandwidth) if the virtual environment not capable of matching the SLA for performance
  • Small number of concurrent users or local limited usage of application
  • Requirements for editing capabilities over the WEB
  • Intensive disk I/O operations, such as dynamic mapping and map caching which perform faster on physical machines than on virtual machines.
  • Some CPU-intensive applications might negatively be affected if the virtual environment capabilities are limited.

 

Posted by Guest Author at 08:28 PM | | Comments (0) | TrackBacks (0)

August 05, 2009

The giant standard bodies say it again “SOA is not about technology but rather about the big “A” in SOA; i.e., Architecture”

by Murteza Salemi

OASIS, OMG, and The Open Group, the three largest standards bodies for SOA and Web services have collaborated on jointly publishing a new white paper called "Navigating the SOA Open Standards Landscape Around Architecture."

The significance about the paper is to reiterate the message that SOA is not about technology but rather the Architecture with big "A". The paper also outlines the agreement on core SOA concepts and terminologies which brings harmony and more or less coordination to these diverse concepts which are very similar in the essence.

 

 There are a number of SOA-related specifications and standards that provide different explanations of the same concepts from different points of view. The white paper discusses main SOA ingredients and core elements such as SOA reference model, SOA reference architecture, maturity model, modeling languages, and governance. It emphasizes SOA as being a framework to be used by architects and SOA practitioners to devise solutions for specific industry and domain. Furthermore it discovers the similarities between the standards and specifications like the ones found between Open Group ontology and OASIS SOA reference model, though the terms used by these standard bodies may represent different architectural views.

The Open Group SOA ontology is similar of OASIS SOA reference model. The ontology defines concepts and vocabularies used in SOA context and elaborate on what they are and how the concepts and vocabularies relate to each other. The main goals are to support understanding of these terms and concepts within SOA setting, and potentially to lay the path for model driven development aka; MDD. The Open Group uses OWL (Web Ontology Language) to represent the Ontology and enable automation through tools that can process OWL. Reasoning applications can use OWL to match a service consumer against a service provider and run an impact analysis.

OASIS reference model is similar to Open Group ontology as it tries to promote a common understanding of SOA by providing an unambiguous and clear vocabulary. The reference model facilitates a conceptual framework that is common enough to be applied systematically and consistently across different SOA development projects. The common semantics remove unambiguities around SOA terms and concepts which help to clearly explain and elaborate on a specific SOA solution.

The paper specifically says: "The Open Group SOA Ontology and the OASIS Reference Model for SOA are very closely aligned, although some terms may represent different architectural views. The difference in expression or naming of concepts does not affect the basic understanding of SOA or the derivative architectures."

We are looking forward to seeing more of these initiatives as it will help us to speak and write in one language, SOA language.

 

Posted by Shubhankar Sumar at 09:36 PM | | Comments (0) | TrackBacks (0)