Service-Oriented Architecture

By Brahma Acharya

Service design considerations for Cloud
In the first part I talked about how SOA and cloud computing converge. SOA does give us the ability to move around services to the cloud. However it might not be sufficient to design services the traditional way. Cloud brings with it a whole new way of doing things. Cloud enabled services should have the following consideration:
 

•  Think Parallel: Design your services such that they can be run in parallel. Distributed processing framework like Hadoop and Map/Reduce have made it possible to run applications concurrently on multiple nodes without much effort. Also, think if the services can be run in a multi-processor environment on parallel threads.

•  Cost implication: A cost benefit analysis is a must before the services are moved to a cloud. Cloud vendors typically charge for bandwidth usage, execution time and storage cost. As such it is important that the service designers and developers keep that in mind. Resources should be sparingly used and released at the earliest possible opportunity. Data transfer between consumers and clouds should be properly analyzed. For ex: If the service needs huge volume of input and output data it might not be a good candidate for Cloud. The overall cost of hosting such a service in the cloud may actually exceed than that of in-house maintenance.

• Design for failure: Cloud platforms are built to handle failures. However there could be downtime and network issues. The application should be designed and deployed in such a way that a failure in the cloud service doesn’t impact mission critical application. For ex: customers of an e-commerce application should be able to shop even though the disks are failing and data centers are down. Amazon’s Dynamo is one such platform which provides such reliability.

• Avoid Vendor lockdown: This is more relevant to the SaaS and PaaS model. Ideally the consumers should be able to move from one cloud provider to another without hassle and avoid any sort of vendor lockdown. This seems a little far-fetched at this point of time. Efforts are on to form an open standard for the Cloud. The opencloudmanifesto is a step in that direction. The Open group has also got into the act of providing an open standard.

• Regulations and laws: In certain cases it might be mandatory as to where the data can be hosted. Some laws like SOX and HIPPA might prohibit enterprise to move certain category of data out of their premises. Services should take these into account.

 Conclusion
Cloud computing is revolutionary in nature. The benefits are too compelling to ignore. As the cloud space heats up, it is important to align your organization properly.  Organizations who have implemented SOA will find it easy to move to a cloud environment. Such applications are not limited by the existing hardware and software. However sufficient due-diligence needs to be done before embarking on a full-fledged cloud exercise.

Posted by Guest Author at 04:20 PM | Permalink | Comments (0) | TrackBacks (0)

By Murteza Salemi

Within SOA space we have seen many definitions for what exactly SOA is, what problem it can solve and how. These varied and diversified definitions have been the main source for the confusion among both the business users and technical architects on what SOA is and how it can help. A group of smart experts and practitioners have acknowledged this issue and came together during 2009 to develop the SOA manifesto. The SOA manifesto consists of a set of core values and principles that can guide the SOA initiatives and programs on their SOA journey to make sure they do not go astray and keep them on the right path.

SOA manifesto clearly demonstrates the shift in the understanding of the SOA world toward business-centric vision of the Service orientation. It is pretty much in sync with OASIS SOA Reference Model and coming Reference Architecture (RA) standards. What significant about this manifesto is that SOA standards and best practices from different standard groups and SOA thought-leaders have started to demonstrate a tendency to merge focuses and recommended directions, which is very important and pleasant fact. The authors of SOA manifesto say that they "value the items on the right" but "value the items on the left more":

• Business value over technical strategy
• Strategic goals over project-specific benefits
• Intrinsic interoperability over custom integration
• Shared services over specific-purpose implementations
• Flexibility over optimization
• Evolutionary refinement over pursuit of initial perfection

Following are some of the guiding principles:

• Respect the social and power structure of the organization.
• Recognize that SOA ultimately demands change on many levels.
• The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.
• Products and standards alone will neither give you SOA nor apply the Service orientation paradigm for you.
• SOA can be realized through a variety of technologies and standards.
• Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.
• Pursue uniformity on the outside while allowing diversity on the inside.
• Identify services through collaboration with business and technology stakeholders.

For a complete list of the principles refer to the SOA manifesto.

Posted by Guest Author at 04:54 AM | Permalink | Comments (0) | TrackBacks (0)

One of the fundamentals about SOA that every enterprise needs to understand is where they stand today before starting the SOA journey – are they ready to take the plunge? Understanding this would give a quick overview of the organisations readiness and maturity of SOA. Thereby ensuring that the common SOA pitfalls are avoided and right strategy and associated programme/initiatives are identified for starting SOA journey for the organisation.

In this blog, I would quickly touch upon the most common SOA pitfalls. The list looks very common, but on the ground the SOA team tend to more often ignore these common ‘must to do’ things due to the high visibility and demand (to deliver against a tight deadline) of the SOA initiative and excitement to work on the cutting edge technologies.

• Starting too big and starting at the wrong place/time. Before beginning the SOA journey, one needs to ensure that the right initiative is identified to manage the expectation of SOA outcome. For example, achieving SOA as part of a high profile time critical business transformation program would be the wrong place. Another situation could be trying to do SOA as part of a program which is already late in the solution delivery process.
• Isolated technology focus (e.g. Buying the full range of SOA products right at the beginning of SOA journey even though all those are not required at the beginning and without the processes and governance in place)
• Isolated architecture focus (e.g. Focus only on the integration layer/business services, No focus on infrastructure services)
• No formal central governance/competency group (CoE or centralize SOA team) and ownership of services. This creates scenarios like ‘unregulated’ development of services without checking reusability leading to redundancy and duplication of services (violates the core principles of SOA)
• Not adapting (or enabling) the operations and support model to support/leverage SOA (Impact on service management areas: Incident Management, Release Management, Configuration Management etc)
• No systematic Service strategy (Service planning) and design e.g. Service design without proper business modeling
• Strategy to measure the value of SOA and report to the stakeholders is absolute must. Not having a plan to measure would be disaster as the value of the SOA may not be clearly visible without the right data (number of time reused, reduced development time, faster response to business etc.) handy
• Making SOA high visibility and demand sponsorship without demonstrating the value (creating a business case for SOA is always a challenge). Ideal approach sometimes is to do mix of bottom-up and top-down. SOA can be introduced in "stealth" mode (for the business) without creating too much distraction.
• Not articulating the business value/impact of SOA (direct tangible links to business objectives) and presenting it purely for architectural purity. This limits the business sponsorship and funding

 

And at the end ‘Governance’ is KEY to successful SOA. Through an on-going governance process, organisations need to measure how far one is from the SOA goals and what is going good or bad. Having right governance in place, all or most critical pitfalls of SOA could be addressed. Lets define the SOA governance and make it work – you are all set for SOA! 

Posted by Shubhankar Sumar at 10:12 PM | Permalink | Comments (0) | TrackBacks (0)

Posted by Shubhankar Sumar at 08:53 AM | Permalink | Comments (0) | TrackBacks (0)

by Animesh Ghosh

‘SOA Security’– How much is enough? – Good question, but meaningless without the context. It is a must to spend a while researching exiting security architecture to comprehend the context. In majority of the cases, the organization probably already has a pretty robust security system(s). The challenge with SOA is to figure out how to extend those existing security measures to those services that comprise SOA. Many SOA security solutions are designed to interconnect effectively with existing security functionality. At that point, the security risks might begin to look a bit more manageable and you can proceed with your plans.

Posted by Guest Author at 11:45 AM | Permalink | Comments (0) | TrackBacks (0)

by Murteza Salemi, Shubhankar Sumar 

Coming up with service categories seems at first an easy task but when you start thinking about it and discuss it with other architects, you will be dazzled on how many different definitions exist out there. It is not a matter of which one is right and which one is wrong but how we are going to agree on one set of definitions and terminology so we can talk with each other and using the same words (terminology) without having different meaning (unambiguous) for them.

The best approach is that every organisation or business unit identifies and agrees on a glossary of these terminologies and definitions right at the beginning of SOA journey. On the agreed category, create guidelines and characteristics for each category for ready reference. The same is communicated and mandated by the SOA governance team within all the SOA programme within the organisation.

There are quite a few in the list. Here are some examples of service categories:

• Business Services
• Capability Services
• Activity Services
• Information Services/Data Services
• Entity Services
• Application Services
• Presentation Services
• Composite Services
• Technical / Infrastructure Services
• Technology Services
• Utility Services
• Communication Services
• Integration Services
• Bus Services
• Process Services
• Master data services

 

Remember – you have to get this fixed right at the beginning of the SOA journey. It looks very trivial things but not having the right set of category defined will have long lasting negative impact and creates confusion within the architecture and business community.

Lets go and finalise the Service Category if you have not done so.

Posted by Shubhankar Sumar at 08:50 AM | Permalink | Comments (0) | TrackBacks (0)

Every web service Designer and Developer possibly have come across service naming standards or best practices in one form or the other. While I do not want to dispute the fact that standards are needed for enforcing good practices that goes a long way in software maintainability and manageability, but then trying to follow a standard without completely understanding the philosophy behind it may not produce optimal results. Now, I do not want to get into pros and cons of particular semantics of service naming either, e.g., naming conventions such as using a verb+noun pair for naming a service, using camel case etc. I will pretty much follow those widely used conventions without a debate.  I will rather try to throw some lights on the common-sense and practical factors that may make service naming less creative and more predictable. Comments and debates welcome.

So thinking with a clean slate – here are some thoughts. IMHO, a good service name should have the following classic attributes (I would not blame you for thinking that I was influenced by OO programming principles in more than one ways):

Service Naming is part of Service Design. Hence one should understand the complete context, functionality and the Layer of abstraction that the service belongs to in a Service Oriented Architecture.  Is it a top-level business orchestration service? Or, is it a much lower level service? Or is it a technical service across business domains? After identifying the Layer a service belongs to, it is easy to

• Predict its usage scope
• Identify its potential consumers

And hence the naming can consider making it contextual to the consumers. After all, service discovery is not too far.

Service Name should attempt to portray the functionality of a service in the light of the overall business process context. So one needs to answer questions like what business logic does the service provide? What business processes does it support? If the service name fails to give you flavor of the business context (or, technical context if it is a technical service) then something is missing. Essentially you should use a verb to represent the actual business task carried out by the service with as much context as possible. Additional context may come from using an appropriate Entity name in the service. Let me site a couple of examples; I would prefer a name that provides more contexts. Lets take the example of service provisioning process for a hypothetical teleco. Let us say a service is used by the process to establish is the customer address is serviceable. This process of customer address validation along with few other steps is generally known as service qualification. Hence QualifyServiceAddress is a better name for our service than something like ValidateAddress because it is contextual to business and has describes the service more accurately.

The other important thing is to use only standard entity names in your Service Name. When I say standard entity names, I assume that an organization-wide data model/information model/business information model already exists. So re-use the same vocabulary and adhere to your organizational standards.

Now as a disclaimer, I think no amount of standard is sufficient to ensure good naming. In many cases just following the semantics, without understanding the principles, beats the whole purpose of naming standards. Let me site some hypothetical examples; you might have come across situations where a new service is being designed to expose or replace a legacy application. The name of the service many a times would be influenced by the application names or process names of the legacy application even when the service interface may exposes a miniscule part of the application. In this case, the service name largely misrepresents its functionality offered. Or, how about a very long verbose service name that attempts to specify the entire business context in its name and does very little. The examples can go on.

Posted by Santanu Dey at 08:53 AM | Permalink | Comments (0) | TrackBacks (0)

I was the chair for SOPOSE 2009, the fourth international workshop Service and Process oriented Software Engineering (http://www.dsl.uow.edu.au/sopose/index.php ),  the workshop co-located with SCC 2009. The workshop aimed at addressing software engineering issues related to constructing service oriented architecture and business process management.

The workshop started with a keynote by on Value in Services Systems, by Prof. Joseph Davis, of  Univ of Sydney. This talk focused on the conceptual foundations what has come to be referred to as 'service science' which is concerned with the design, value co-creation (between the service providers and customers), and performance modeling of complex service systems.

There was an interesting discussion on User experience being at core of the final rendering of a service, and how the interactions between consumers, producers is core to the notion of "value". No doubt this is an important area of research from the perspective of justifying investments in IT, in current circumstances.

This was followed by thought provoking presentations including papers on BPM adoption, and software engineering issues related to BPM and SOA, including two innovative papers from Infosys titled "A holistic approach in context of Enterprise BPM adoption" and  

"Challenges and Approaches during requirement gathering phase for multi release BPM engagement" respectively.

More soon.

Posted by Dr. Srinivas Padmanabhuni at 08:15 AM | Permalink | Comments (0) | TrackBacks (0)