Logo

Navigation
  • Home
  • Services
    • ERP Solutions
    • Implementation Solutions
    • Support and Maintenance Solutions
    • Custom Solutions
    • Upgrade Solutions
    • Training and Mentoring
    • Web Solutions
    • Production Support
    • Architecture Designing
    • Independent Validation and Testing Services
    • Infrastructure Management
  • Expertise
    • Microsoft Development Expertise
    • Mobile Development
    • SQL Server Database and BI
    • SAP BI, SAP Hana, SAP BO
    • Oracle and BI
    • Oracle RAC
  • Technical Training
    • Learn Data Management
      • Business Intelligence
      • Data Mining
      • Data Modeling
      • Data Warehousing
      • Disaster Recovery
    • Learn Concepts
      • Application Development
      • Client Server
      • Cloud Computing Tutorials
      • Cluster Computing
      • CRM Tutorial
      • EDI Tutorials
      • ERP Tutorials
      • NLP
      • OOPS
      • Concepts
      • SOA Tutorial
      • Supply Chain
      • Technology Trends
      • UML
      • Virtualization
      • Web 2.0
    • Learn Java
      • JavaScript Tutorial
      • JSP Tutorials
      • J2EE
    • Learn Microsoft
      • MSAS
      • ASP.NET
      • ASP.NET 2.0
      • C Sharp
      • MS Project Training
      • Silverlight
      • SQL Server 2005
      • VB.NET 2005
    • Learn Networking
      • Networking
      • Wireless
    • Learn Oracle
      • Oracle 10g
      • PL/SQL
      • Oracle 11g Tutorials
      • Oracle 9i
      • Oracle Apps
    • Learn Programming
      • Ajax Tutorial
      • C Language
      • C++ Tutorials
      • CSS Tutorial
      • CSS3 Tutorial
      • JavaScript Tutorial
      • jQuery Tutorial
      • MainFrame
      • PHP Tutorial
      • VBScript Tutorial
      • XML Tutorial
    • Learn Software Testing
      • Software Testing Types
      • SQA
      • Testing
  • Career Training
    • Career Improvement
      • Career Articles
      • Certification Articles
      • Conflict Management
      • Core Skills
      • Decision Making
      • Entrepreneurship
      • Goal Setting
      • Life Skills
      • Performance Development
      • Personal Excellence
      • Personality Development
      • Problem Solving
      • Relationship Management
      • Self Confidence
      • Self Supervision
      • Social Networking
      • Strategic Planning
      • Time Management
    • Education Help
      • Career Tracks
      • Essay Writing
      • Internship Tips
      • Online Education
      • Scholarships
      • Student Loans
    • Managerial Skills
      • Business Communication
      • Business Networking
      • Facilitator Skills
      • Managing Change
      • Marketing Management
      • Meeting Management
      • Process Management
      • Project Management
      • Project Management Life Cycle
      • Project Management Process
      • Project Risk Management
      • Relationship Management
      • Task Management
      • Team Building
      • Virtual Team Management
    • Essential Life Skills
      • Anger Management
      • Anxiety Management
      • Attitude Development
      • Coaching and Mentoring
      • Emotional Intelligence
      • Stress Management
      • Positive Thinking
    • Communication Skills
      • Conversation Skills
      • Cross Culture Competence
      • English Vocabulary
      • Listening Skills
      • Public Speaking Skills
      • Questioning Skills
    • Soft Skills
      • Assertive Skills
      • Influence Skills
      • Leadership Skills
      • Memory Skills
      • People Skills
      • Presentation Skills
    • Finding a Job
      • Etiquette Tips
      • Group Discussions
      • HR Interviews
      • Interview Notes
      • Job Search Tips
      • Resume Tips
      • Sample Resumes
 

Service Reusability

By Exforsys | on October 20, 2007 |
SOA Tutorial

Service Reusability

One of the most vital principles of Service Oriented Architecture is that of service reusability. And in today’s day and age, it can be said that we have been making a lot of progress towards improving both this central tenet and Service Oriented Architecture in general.

One sign that a significant degree of progress in the field has been made is the fact that more and more questions regarding Service Oriented Architecture these days are aimed at the architecture itself, rather than infrastructure and implementation. One question that has come up in recent years is: Should all services be reusable?

This question has a deceptively simple answer. Since it is one of the tenets of Service Oriented Architecture to build services that are reusable, then indeed all of them should be, right?

Upon further examination, finding an answer to this question may require greater demands of subtlety – as well as deeper thinking in architectural terms. In this essay, we will explore the correct answer to this question, while also examining the notion of deep architectural thinking.

Top Down Service Oriented Architecture Thinking

When asking whether or not all services should be reusable, we are led to ask two more questions. Depending on which question you choose to ask, you will be able to determine whether you are thinking about architecture in a bottom up or top down manner.

The top down approach to Service Oriented Architecture thinking begins with a picture of all Business processes that exist in a Business. The thinking then turns to the decomposition of such processes with an eye towards the identification of redundant areas that may indicate good candidates for services.

As such a top down method focuses mostly on meeting the objectives of a Business while increasing efficiency through a reduction of redundancy and a subsequent increase in reusability, the main question architects should ask themselves is whether or not a maximization of reusability is the smartest practice, or whether other priorities should also be taken in to consideration.

The fact is that while reusability may indeed be one of the most important aspects for determining what services are to be built, there are other aspects that must be taken in to consideration by the architect in order to go about meeting the ever-changing requirements of the organization via Service Oriented Architecture abstraction. To be precise, services’ evolvability is something that every architect should take in to consideration.

While some services might have more than one application, they might nevertheless experience several requirement changes as time wears on. There are in fact situations in which agility instead of reusability will be the driving force behind the design of a service.

A certain service might have only one consuming application; this being the case, what should dictate the design of the service is the fact that it is subject to constantly changing requirements — not its reusability. In such instances, it will be a lot more cost effective to put the necessary overhead in place as a means of ensuring the loose coupling that is required for such services, even though they might only have one consumer.

There is yet another example whereby reusability may not be the service design’s top priority. That is in those instances where loose coupling owing to the contracted nature of the interface becomes the top priority – particularly in Business-to-Business environments.

Two Businesses that are attempting to improve their automated interactions may very well struggle with limitations that are specific to implementation, such as getting a Java based application at one organization to interact with a mainframe based application at the other organization.

In these instances, the building of services with contracted interfaces that abstract the underlying implementation can ease the process faced by such interactions, even though such services will really only be valuable for that precise, point to point interaction.

Bottom Up Service Oriented Architecture Thinking

The bottom up approach to Service Oriented Architecture thinking takes the opposite tack to the top down method. It begins by taking a look at existing Information Technology capabilities in the enterprise as a departure point for the development of services that expose the existing functionality that a Business is already largely dependent on.

One of the primary challenges that is posed to architects in such a scenario is the amount of existing functionality should be exposed in the form of services – and at what granularity level. If, for instance, reusability has emerged as the primary driver for the identification of areas within a service enablement, then it naturally follows that some existing Information Technology functionality might never end up in the form of a service.

The challenge then becomes to determine what functionality should be exposed in the form of a service, as well as prioritizing existing functionality’s service enablement.

One approach to the solving of such a challenge is the leveraging of this general rule of thumb – twenty percent of any system’s existing functionality should be utilized eighty percent of the time. The functionality’s remaining eighty percent should handle exceptions, special cases, as well as other low use scenarios.

Keep in mind that the greatest use does not necessarily employ the greatest reuse. At the same time, service enabling that twenty percent is likely to lead to the greatest level of reuse as a rule of thumb.

Obviously, if an architect is capable of identifying the twenty percent of an existing Information Technology system with the heaviest usage, service enabling those portions of the functionality is going to provide the organization with its biggest bang for the buck.

It accomplishes this by easing access to the functionality, but also through an enabling of the broader reuse of such functionality. There may indeed be reasons to service enable other Information Technology assets. But it is a lot less likely that reusability will be the primary driver behind the follow up enablement.

Architecture Building for Proper Granularity

Of course, most architects are aware of the fact that neither of the approaches to thinking up above is adequate on their own. While the top down approach is likely to identify services that are not cost effective to construct, the bottom up method risks producing ungoverned, redundant services.

A core Service Oriented Architecture best practice is thus to take an iterative approach that employs both methods of thinking, thus improving the architecture as well as the services that exist within each iteration.

In the following, we will explore an example of Service Oriented Architecture that is iterative. Let us say we have already defined Services A and Service B which are compositions of original services, as may be illustrated below:

Utilizing the top down method, one will notice that services A and B both share the composition of fine-grained services 2, 3, and 4. In the iteration that follows, the coarser grained Service C may be defined as

This enables you to re-design A and B as follows:

The familiar agile principle of refactoring out redundancy has been followed. Now an easier definition has emerged for the first two services. The question that remains, however, is whether or not the third service is more or less reusable than services 2, 3, and 4.

The fact is, the third service will generally be a lot less reusable than services 2, 3, and 4, owing to the fact that finer grained services are reusable in the broader set of situations than Service C, which is coarser grained.

This is because of the fact that 2, 3, and 4 can be consumed separate from one another, while Service C consumers will be expected 2, 3, and 4 to be used together.

Despite all this, it will make sense to leverage the third service in this fashion, as the third service is a lot more Business oriented than 2, 3, and 4 taken separately. Coarser grained services tend to be a lot more likely to be oriented towards Business than the finer grained ones.

Service C has a clearer Business value than 2, 3, and 4. This alone is sufficient motivating for wanting to build the third service. Services 2, 3, and 4 will still around, so if someone needs to build them in the future, they are also reusable.

But owing to the fact that Service C is a lot more Business oriented and coarser grained, it is a lot more composable than the servers marked 2, 3, and 4.

One should also keep in mind that the third service is reusable – just not as reusable as other services might be. One is not simply intending to architect for today’s services, however – the Business will need to recompose services in order to meet the requirements of the future as well. Thus, the main architectural principle that should be kept in mind is that coarse granularity is more vital than reusability when the granularity level is able to improve the service’s composability.

« « Standardized Service Contract
Service Oriented Infrastructure » »

Author Description

Avatar

Editorial Team at Exforsys is a team of IT Consulting and Training team led by Chandra Vennapoosa.

Free Training

RSSSubscribe 0 Followers
  • Popular
  • Recent
  • Service Loose Coupling

    October 17, 2007 - 0 Comment
  • Service Autonomy

    November 9, 2007 - 0 Comment
  • SOA for Developers

    October 5, 2007 - 0 Comment
  • Service Discoverability

    October 20, 2007 - 0 Comment
  • SOA Disadvantages

    September 25, 2007 - 0 Comment
  • SOA Job Opportunities

    October 7, 2007 - 0 Comment
  • Standardized Service Contract

    October 20, 2007 - 0 Comment
  • SOA Standards

    September 25, 2007 - 0 Comment
  • SOA and Web Services

    October 8, 2007 - 0 Comment
  • Service Oriented Infrastructure

    October 21, 2007 - 0 Comment
  • Service Autonomy

    November 9, 2007 - 0 Comment
  • Service Oriented Infrastructure

    October 21, 2007 - 0 Comment
  • Standardized Service Contract

    October 20, 2007 - 0 Comment
  • Service Discoverability

    October 20, 2007 - 0 Comment
  • Service Loose Coupling

    October 17, 2007 - 0 Comment
  • Service Encapsulation

    October 17, 2007 - 0 Comment
  • Service Abstraction

    October 15, 2007 - 0 Comment
  • Service Composability

    October 15, 2007 - 0 Comment
  • Service Orientation and Interoperability

    October 11, 2007 - 0 Comment
  • SOA and Business Architecture

    October 11, 2007 - 0 Comment

Exforsys e-Newsletter

ebook
 

Related Articles

  • Service Autonomy
  • Service Oriented Infrastructure
  • Standardized Service Contract
  • Service Discoverability
  • Service Loose Coupling

Latest Articles

  • Project Management Techniques
  • Product Development Best Practices
  • Importance of Quality Data Management
  • How to Maximize Quality Assurance
  • Utilizing Effective Quality Assurance Strategies
  • Sitemap
  • Privacy Policy
  • DMCA
  • Trademark Information
  • Contact Us
© 2023. All Rights Reserved.IT Training and Consulting
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptReject Read More
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT