Guidelines for Designing Service-Oriented Classes

Here are some guide lines to design Service-Oriented Classes. It will be helpful if you are required to use UML class notations to model services.

Implement Class Interfaces

Classes which are to be designed for Services should always implement Interfaces so that it has a public contract which is exposed but the implementation details are hidden. This helps with the Service Principles like Standardized Service Contract, Service Loose Coupling and Service Abstraction Principle.


Limit Class Access to Interfaces

This enables the Contract Centralization Pattern in Service Design and ensures a loose coupling between the Consumers to Contract relationship.  This helps in protecting the implement logic of the underlying class.


Do Not Define Public Attributes in Interfaces

To enable the Service Statelessness principle which encourages services to exist as solution units capable of reverting to a stateless condition whenever possible. Not having public attributes in interface makes sure all communication happens through methods and thus places the control of how state is managed within the service.


Use Inheritance with Care

Inter-service inheritance is not encouraged in Service-Orientation Design.

Intra-service inheritance i.e the application of inheritance to classes encapsulated within a service can be applied as required.


Avoid Cross-Service “has-a” Relationships

Service compositions require the freedom to allow composition members to act independently from the parent control Service. Services cannot be determined to an ownership hierarchy. If at all required you can use the “uses-a” relationship instead of “has-a” relationship like composition or aggregation


Use Abstract Classes for Modeling, Not Design

Use of abstract classes in Service-Orientation is not required.  No formal relationships are defined or needed for other services to be designed.


Use Façade Classes

In Service Design Façade classes are an important technique for structuring components as standalone services or as part of service-oriented Web services.

Read More

SOA Interview Questions

Here are some Interview Questions on SOA (Service Oriented Architecture)
1. What is SOA (Service Oriented Architecture)?
2. What are benefits of SOA
3. What are the dis-advantages of SOA
4. What are the challenges to SOA adoption in a Corporate Environment
5. What is SOA Governance?
6. What are some of the SOA Design Principles?
7. Difference between OOP and SOA?
8. What is a Service Repository?
9. What is reusability of a Service?
10. Explain loose-coupling in SOA?
11. Explain State management in SOA?
12. What are the challenges of integrating legacy applications with SOA?
13. What is Service Composition?
14. What are the pitfalls of SOA?
15. What are the types of Services in SOA?
16. How does Web-Service fit in SOA?
17. What are the main obstacles of SOA?
18. What are the characteristics of a SOA Service?

Read More

Overview of Windows Azure – Video

Windows Azure

Here I have embedded some videos to give an overview of what Windows Azure is. Hope you find it useful. Enjoy exploring Windows Azure.

Windows Azure is a cloud services operating system that serves as the development, service hosting and service management environment for the Windows Azure platform. Windows Azure provides developers with on-demand compute and storage to host, scale, and manage web applications on the internet through Microsoft datacenters.

Windows Azure is a flexible platform that supports multiple languages and integrates with your existing on-premises environment. To build applications and services on Windows Azure, developers can use their existing Microsoft Visual Studio expertise. In addition, Windows Azure supports popular standards, protocols and languages including SOAP, REST, XML, Java, PHP and Ruby. Windows Azure is now commercially available in 40 countries.]

Overview of Windows Azure Services for Windows Server

Windows Azure Overview

Introduction to Windows Azure Infrastructure as a Service (IaaS)

Read More

Microsoft Cloud Services – Taking Any App to the Cloud – Video

Cloud computing may be the most disruptive, transformative technology shift since the Internet, and migrating business to the cloud isn’t just a trend anymore but rather a fundamental business requirement. Cloud computing has already proven worthy of attention from established enterprises and start-ups alike. Most businesses are looking at cloud computing with more than just idle curiosity and research suggests that most enterprise IT managers have enough resources to adopt cloud computing in combination with on-premises IT capabilities.

Here is a video discussion on Microsoft Cloud Services, How to build Applications quick for the Cloud.

Read More

Service Oriented Design Principles

Here is an introduction to some of the design principles associated with Service Oriented Solution.

Standardized Service Contract

Services expose their capabilities and functions through a service contract. The Standardized Service Contract emphasizes on the things to consider when you design the Services public technical interface and monitoring the quantity and nature of content that will be exposed as the service’s contract.

Emphasis is place on the aspects of contract design, including how data types and data models are defined and policies are asserted.

There is also a focus on making sure the service contracts are optimized, granular enough and standardized to guarantee that the endpoints exposed are consistent, reliable and maintainable.

Service Reusability

Reuse is an extremely important principle in Service-Orientation. It’s so important that it becomes the core part of the typical service analysis and design processes and also forms the basis for service models.

This principle of Service Reusability emphasizes the positioning of services as an enterprise resources with agnostic functional contexts. Many design considerations are applied to make sure that individual service capabilities are designed in relation to an agnostic service context and to ensure they can promote the necessary reuse requirement.

Service Loose Coupling

Coupling is a connection or relationship between two entities. Coupling depends on the level of dependency between entities or components.  This principles emphasizes on the creation of specific type of relationship within and outside of service boundaries, with main emphasis on reducing dependencies between Service contract, its implementation and the Service consumers.

Service Loose Coupling design principle promotes independent design and development of service log and implementation while still maintaining its interoperability with consumer that rely on the service capabilities.

There are numerous types of coupling in the design of Service, each of which can influence the content and granularity of its contract.

Service Abstraction

Service Abstraction principle emphasizes the need to hide the details of the service. Hiding the details enables and promotes loosely coupled relationships.

When considering different abstraction levels various forms of meta data comes into picture. The extent to which the Service Abstraction principle is applied can affect the granularity of the Service Contract and can also influence the cost of manageability of the service.


Service Autonomy

For services to be able to function consistently and reliably, their solution logic needs to have good control over its environment and resources.

The Service Autonomy principle supports the extent to which other design principles can be effectively realized in real world production environments by promoting design characteristics that maximizes a service’s reliability and predictability.

This principle refers to various problems that relates to the design of service logic and the service’s actual implementation environment. Isolation levels and service normalization considerations are considered to achieve optimum level of autonomy, especially for reusable services.


Service Discoverability

For services to be used as IT assets they should be easily identifiable and understood and a reusable need occurs.  The service design needs to take the communications quality and its individual capabilities into account.


Service Statelessness

Excessive state information can compromise the availability of a service and reduce its scalability potential. Services should be ideally designed to be stateful only when required.

Applying the principle of Service Statelessness requires that the means of attainable statelessness be analyzed, based on the ability of the environments technology architecture to provide state management delegation.


Service Composability

The ability of effectively compose services is critically important to achieve the fundamental goals of service oriented computing. Services are expected to be able to participate as effective composition members, regardless of whether they need to be immediately added to the composition. The principle of Service Composability takes care of this ensuring that a variety of considerations are taken into account.



SOA: Principles of Service Design –by Thomas Erl

Read More

Benefits of Service Oriented Architecture (SOA)

If an Enterprise decides to go and adopt the Service Oriented Architecture and implement the change, it has to sure analyze and understand the Benefits of SOA and if it is really essential.

Here are some of the benefits or advantages of Service Oriented Architecture.

  1. Increased Intrinsic Interoperability
  2. Increased Federation
  3. Increased ROI
  4. Increased Organizational Agility
  5. Increased Vendor Diversification Options
  6. Reduced IT Burden


Increased Intrinsic Interoperability

Interoperability applies to sharing of data between the applications. The more interoperable they are, easier it is for them to exchange information. Applications that run in silo need to be integrated. Integration is a process that causes Interoperability

The goal of SOA is to have the interoperability built into the service thus eliminating the need for integration.  Interoperability can be attained by decidedly applying the design principles and standards.


Increased Federation

Federated IT Environment refers to one where applications and resources and combined and united but also their individual autonomy and self-governance is maintained.  SOA strives to increase the federated aspect of the Enterprise environment. It does it by creating standardized and composable services, which creates a natural harmony across the enterprise between the applications and services.

Increased ROI

Measuring the ROI of an enterprise solution can be difficult but it can be obvious when looked at from a long term perspective.

Traditional silo applications tend to grow over time and create complex environment which can be a very difficult to maintain and enhance.

SOA proposes creation of agnostic solution logic that can be used for multiple purposes, thus it has the benefit of re-usability. Re-usability of solution logic in services can increased ROI in long term

Increased Organizational Agility

Agility on the organizational level refers to its ability to quickly respond to a change.  SOA is very much seeking to improve organizational agility.

When SOA principles are applied across the enterprise, it results in implementation of services which are standardized and reusable and agnostic to one particular business process and application environment. As these number of services increases, and request for new change can be easily met by reusing the existing services and developing on them as required. This results in quicker project delivery and quicker adaptation to changes.

Increased Vendor Diversification Options

By designing a Service Oriented Architecture in alignment with but neutral to major vendor SOA platforms and by positioning service contracts as standard endpoints across the enterprise, proprietary service implementation details can be abstracted. This enables the organization to have more options to diversify their enterprises as required.


Reduced IT Burden

Successfully applying the Service Oriented principles and designs results in an enterprise with reduced redundancy, reduced size and operational cost and reduced overhead. This can benefit the organization through dramatic increase in efficiency and reduction in cost.

Those are some of the benefits of Service Oriented Architecture.


SOA: Principles of Service Design –by Thomas Erl

Read More


IBM Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) has several core ideas that should be addressed in your organization’s SOA journey:

A set of services that a business wants to provide to their customers, partners, or other areas of an organization

An architectural style that requires a service provider, mediation, and service requestor with a service description

A set of architectural principles, patterns and criteria that address characteristics such as modularity, encapsulation, loose coupling, separation of concerns, reuse and composability

A programming model complete with standards, tools and technologies that supports web services, REST services or other kinds of services

A middleware solution optimized for service assembly, orchestration, monitoring, and management

via IBM Service Oriented Architecture (SOA).

Read More

Chapter 3: Architectural Patterns and Styles

What Is An Architectural Style?

An architectural style, sometimes called an architectural pattern, is a set of principles—a coarse grained pattern that provides an abstract framework for a family of systems. An architectural style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems. You can think of architecture styles and patterns as sets of principles that shape an application. Garlan and Shaw define an architectural style as:

“&#2026a; family of systems in terms of a pattern of structural organization. More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined. These can include topological constraints on architectural descriptions (e.g., no cycles). Other constraints—say, having to do with execution semantics—might also be part of the style definition.”

[David Garlan and Mary Shaw, January 1994, CMU-CS-94-166, see “An Introduction to Software Architecture” at]

An understanding of architectural styles provides several benefits. The most important benefit is that they provide a common language. They also provide opportunities for conversations that are technology agnostic. This facilitates a higher level of conversation that is inclusive of patterns and principles, without getting into specifics. For example, by using architecture styles, you can talk about client/server versus n-tier. Architectural styles can be organized by their key focus area. The following table lists the major areas of focus and the corresponding architectural styles.

via Chapter 3: Architectural Patterns and Styles.

Read More

Chapter 1: Service Oriented Architecture (SOA)

Introduction to SOA

The SOA Elephant

SOA has become a well-known and somewhat divisive acronym. If one asks two people to define SOA one is likely to receive two very different, possibly conflicting, answers. Some describe SOA as an IT infrastructure for business enablement while others look to SOA for increasing the efficiency of IT. In many ways SOA is a bit like John Godfrey Saxe’s poem about the blind men and the elephant. Six blind men from Indostan encounter an elephant – each of the men then describes the elephant a bit differently because they are influenced by their individual experiences:

The man touching the trunk believes it to be a snake

The man touching the tusk believes it to be a spear

The man touching the ear believes it to be a fan

The man touching the elephant’s side believes it to be a wall

The man touching the tail believes it to be a rope

The man touching the legs believes they are trees.

Figure 1. Saxe’s Elephant

The blind men then engage in a series of debates about what they believe are facing them:

“…And so these men of Indostan

Disputed loud and long,

Each in his own opinion

Exceeding stiff and strong,

Though each was partly in the right,

And all were in the wrong!”

In many ways Mr. Saxe’s poem has become a prophecy for SOA. Industry analysts, pundits, bloggers and reporters engage each other in an ongoing, never-ending debate about what is or isn’t SOA. Like Mr. Saxe’s blind men, people have correctly identified many of the capabilities of SOA but largely fail to communicate the concept as a whole. The challenge of defining SOA has become so important that various vendor consortia and standards organizations have launched initiatives to try and answer the question “What is SOA?”

via Chapter 1: Service Oriented Architecture (SOA).

Read More