Welcome!

SOA & WOA Authors: David Deans, Salvatore Genovese, Yeshim Deniz, Christopher Keene, Dave Haynes

Related Topics: SOA & WOA, XML

SOA & WOA: Article

The Art of SOA - More Than Optimal Is Ineffective

SOA refers to an architectural solution that creates an environment in which services and service consumers coexist

Services
Services are any functionality provided by a provider to a consumer following classical definitions. It's usual practice to realize these services using either software assets (or code) or business processes. It's also possible for these services to be leaf-level (atomic services) or composite (or aggregate or group of leaf-level services).

Some of the important points in this regard are as follows:

  • How many services have to be automated?
  • How many services are necessarily manual (due either to the difficulty of automation or the complexity involved in automating them or due to leaving them manual since they aren't "in focus" or key services)?
  • How many services are expected to be called from outside (B2B services) and have to be registered on external registries like UDDI?
  • How many services are expected to be called from the intranet and have to be registered in the internal or corporate registry?
  • How many services don't have to be reusable or are legacy, and are meant only for internal consumption. These services can be made directly invocable without a complete registry lookup optimizing performance.
  • How many services have to be developed using code and how many using business processes?
  • What are the service discovery mechanisms? Is it necessary to support only registry lookup or is it also necessary to support advertising and use the protocol for service discovery? Use advertising and acceptance only with external services.
  • Use consequential services or time-bound services where possible. This reduces the load on the registry and improves performance.
Registry/Repository
  • Is it necessary to support an internal registry?
  • Is it necessary to include interfaces in the external registry?
  • What is the structure of the metadata? By identifying the basic information structure operated together, it's possible to arrive at a suitable granularity for the metadata. For example, if it's necessary to operate on the customer as an entity with all the associated attributes, it's possible to increase performance, but it would impact granularity.
  • A registry typically stores all the information relevant to the SOA implementation - from basic interface contract definitions to more sophisticated meta-service templates. The following provide some decision points in this process:
    > The first step is identifying the data that has to be stored in the repository.
    > Which interface contracts have to be global and so go into the global repository and which interface contracts have to be local and go into the local store?
    > Does the interface contract comply with any standards?
    > Does the interface contract support advertising and accepting? For example, if a specific provider provides an "advertising" mechanism for service discovery, does the interface contract support the scheme? Are the advertising and accepting mechanisms validated for "clear requirements" or is it possible to use direct invocation for such services as well?
Broker
  • Do we need a broker? How much metadata has to be stored and accessed from the broker? If there are only a few services, it may be a good idea to use a homegrown broker or a simple register-lookup broker. However, if there are lots of services, it may be necessary to use a standard broker. The sophistication of the broker depends on the number of services, among other things.

    Integration Media

    • What is the integration media? Do we really need a sophisticated ESB? Can we make do with simple Open Source middleware or can we use simple homegrown middleware? These are some of the questions that help in identifying the level of sophistication required in the integration media.
    • What is the level of security to be supported?
    Even if we use http over LAN, we can still comply with SOA principles, it's just a matter of business requirement. SOA doesn't mandate any specific integration media.

    Maturity of an Organization versus SOA
    The maturity of an organization is usually measured in its performance against a specific set of goals. These goals are business drivers that help in defining the scope of the organizational focus, which is always on meeting business goals and includes, among the other things, increasing profits and reducing risks.

    So, to comply with the maturity models existing in the industry, it's necessary for an organization to meet some or all of the SOA principles in such a way as to maximize its applicability to the business.

    As we can see in Figure 2, the SOA solution consists of multiple components - an infrastructure layer, a set of applications, a set of business processes, and best practices. Though expertise in SOA architecture is the foundation of the overall solution, the other components, namely the business process expertise and applications expertise, are absolutely required to arrive at an end-to-end solution to the problem at hand.

    As we can see, the maturity of an organization is reflected in the effectiveness with which it meets its goals, and so increases its profits and reduces its risks. Maturity can't be inferred by activity per se, but it can be inferred in the way an activity is done. However, it's necessary to keep in mind that the set of activities needed to meet business goals are always specific to the organization and specific to every enterprise. Once an organization has stated its goals, plans, and activities, maturity is the measure of how well these activities are done.

    In this context, we have to keep in mind that every business has to align its business goals with its IT capabilities. Even a small teashop has to do business-IT alignment, and even a huge organization does the same business-IT alignment. However, a small organization can use manual processes (that may or may not be documented/standardized) and a huge corporation can use a lot of automated processes. To decide which company is more mature, it's necessary to weigh the execution of the business activities to meet the goals in the context of the size of the business. A good maturity study may conclude that a small company with a few employees is better aligned to SOA than a huge corporation with lots of employees.

    One must also keep in mind that every huge corporation is the result of a sustained existence in business, improving on itself year after year. A big modern corporation was once a small company. Hence the rules for SOA maturity should be interpreted in the light of the size of the organization, the documented business goals or practices, and expected future plans.

    Summary
    In today's context, it's good to understand clearly what SOA can do and what it is. And it's more important to understand how much SOA is enough for a given organization. In other words, the optimum application of SOA can result in enormous savings and return for an organization. Beyond the optimum point, any SOA application would only bring limited results. We attempted to throw some light on some of the important factors to be considered in making this decision.

  • More Stories By Raghu Anantharangachar

    Raghu Anantharangachar is a solution architect with the Hewlett Packard Global Delivery India Centre, Bangalore. He has over 15 years of experience and has worked on porting, network management, and system integration projects in the past. He has a Bachelor's degree in Computer Science and Engineering from Bangalore University and a Master's degree in Industrial Management from the Indian Institute of Science, Bangalore.

    Comments (2) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    SOA Web Services Journal News 06/13/06 10:41:46 AM EDT

    Service Oriented Architecture (SOA) refers to an architectural solution that creates an environment in which services, service consumers, and service producers co-exist yet have no dependence on each other. SOA enables an enterprise to increase the loose coupling and the reuse of frequently used software assets. These software assets together with the functionality that they provide are called services in SOA terminology. By nature SOAs are typically applied to solutions with highly volatile requirements.

    SOA Web Services Journal News 06/13/06 10:19:40 AM EDT

    Service Oriented Architecture (SOA) refers to an architectural solution that creates an environment in which services, service consumers, and service producers co-exist yet have no dependence on each other. SOA enables an enterprise to increase the loose coupling and the reuse of frequently used software assets. These software assets together with the functionality that they provide are called services in SOA terminology. By nature SOAs are typically applied to solutions with highly volatile requirements.