Client Integration Mini-Checklist for Services

May 27, 2012

Working with clients who are consuming your services? Here is a mini-checklist of questions to ask:

  1. While executing request/reply on the service interface is there a timeout value set on the call?
  2. Is there code/logic to handle SOAP Faults /system exceptions when invoking the service?
  3. Is building service header separated from the payload? This will facilitate reuse across services that share common header parameters
  4. If there are certain error codes that the calling code can handle, is there logic for each of them?
  5. Is the physical end point information (URL string for HTTP, Queue connection and name for MQ/EMS) stored in an external configuration file?
  6. Is UTF-8 encoding used while sending XML requests to the service i.e. by making use of platform-specific UTF encoding objects?
  7. If using form-encoding are unsafe characters such as ‘&’, ‘+’, ‘@’ escaped using appropriate %xx (hexadecimal) values?
  8. While processing the service response is the logic for parsing/processing SOAP and service-specific headers decoupled from processing the business data elements?
  9. Is the entire request/reply operation – invocation and response handling logic – encapsulated into its own class or method call?
  10. While performing testing, is the appropriate testing environment URL/queue manager being used?
  11. Is a valid correlation id being used in the service request? This is very essential for aynchronous request/reply over JMS (JMS Header) or HTTP (callback handler)

Every Project Is An Opportunity

May 26, 2012

Succeed with systematic reuse by pursuing opportunities across every project. Every single project. Explore synergies across projects to not only identify new reusable components but also update existing ones. Here are a few common areas that yield reusable components:

  • Data access and updates – is there a single suite of APIs for managing core data? are there redundant implementations, overlapping calls, across projects?
  • Domain rules – are domain rules organized in a clear and well maintainable manner? or are they split across layers and implemented using multiple technologies/strategies?
  • Processing templates – are there a common set of steps of relevance in your domain? are these steps always executed in a consistent manner? is there an opportunity to Templatize the steps?
  • Config management – how are applications managing configuration properties? how do they enable properties for a particular environment? how does an application get only properties that it is entitled to?

The above isn’t exhaustive but gives you a flavor for the kinds of questions that will drive opportunities for systematic reuse


Have a Reuse Strategy for Business Process Integrations

January 29, 2012

When implementing process automation initiatives, it is important to have a reuse strategy – why? Because, the process flows are a rich minefield for reusing services and common interfaces across a variety of use cases. It can also act as a service provider for other teams to invoke/integrate a common set of processing flows.

Host business process definitions and instances

  • Provide a modeling and execution environment for designing and implementing business processes
  • Implement a generic data structure for manipulating & orchestrating workflow state
  • Provide the ability to reuse a workflow patterns across business processes. E.g. enable reuse via sub-processes, process extension points, etc.
  • Provide the ability to access and orchestrate activities requiring interaction with data services and business rules, and legacy services

Act as services consumer & provider

  • Host process orchestrations, while consuming persistence, validation, and security services
  • Abstract legacy capabilities and reduce tight coupling between internal systems
  • Publish and consume business events to reduce application to application coupling

 

Evolve a reusable asset catalog

  • Ensure technology components and APIs have domain relevance – data, events, and relationships are fundamental abstractions need to be brought together
  • Reduce learning curve for application developers to identify, evaluate, and integrate process definitions and services from a library of reusable assets

Governance Enables Service Reuse – New Podcast Episode

December 27, 2011
Want to listen using iTunes?

Got iTunes?

podcast

New episode added to the Software Reuse Podcast Series on service governance covering design, implementation, testing, and provisioning and how they enable reuse.

Like this post? Subscribe to RSS feed or get blog updates via email.


Systematic Reuse Mythbuster #1 – Reusable Doesn’t Mean Perfection

December 26, 2011

One common criticism against systematic software reuse is the myth that it implies perfection – creating a reusable asset automatically conjures up visions of a perfect design, something that is done once and done right.  Many developers and managers confuse reusability with design purity. However, reusability is a quality attribute like maintainability, scalability, or availability in a software solution. It isn’t necessary or advisable to pursue a generic design approach or what one believes is highly reusable without the right context.

The key is to go back to the basics of good design: identify what varies and encapsulate it.

The myth that you can somehow create this masterpiece that is infinitely reusable and should never be touched is just that – it is a myth and is divorced from reality. Reusable doesn’t imply:

  • that you invest a lot in big up front design effort
  • you account for everything that will vary in the design – the critical factor is to understand the domain – well enough, deep enough, so you can identify the sub-set of variability that truly matters

In the same vein, reusablility strives for separating concerns that should be kept distinct. Ask repeatedly:

  • Are there multiple integration points accessing the core domain logic?
  • Is there a requirement to support more than one client and if so, how will multiple clients use the same interface?
  • What interfaces do your consumers need? is there a need to support more than one?
  • What are the common input parameters and what are those that vary across the consumer base?

These are the key questions that will lead the designer to anticipate the appropriate places where reuse is likely to happen.  Finally, it is important that we don’t build for unknown needs in the future – so the asset is likely to solve a particular problem, solve it well, solve it for more than one or two consumers, and finally has potential to be used beyond the original intent. At each step there are design decisions made, discarded, continuous refactoring, refinements to the domain model – if not re-definition altogether.

Don’t set out trying to get to the end state or you will run the risk of adding needless complexity and significant schedule risk.


Track Service Reuse Metrics

December 24, 2011

Service driven systematic reuse takes conscious design decisions, governance, and disciplined execution – project after project. In order to sustain long running efforts such as service orientation, it is critical to track, report, and get buy-in from senior management in the organization. So what metrics are useful? Here are a few:

  • Total number of service operations reused in a time period
  • Total effort saved due to systematic reuse in a time period
  • Number of new service consumers in a time period
  • Number of new consumer integrations in a time period (this includes integrations from both new and existing consumer
  • Service integrations across transports/interface points (for instance, the service operation could be accessed SOAP over HTTP, or as SOAP over JMS, or REST, etc.)

What metrics do your teams track?


5 Service Governance Practices for Effective Reuse

December 24, 2011

Pursuing service based systematic reuse or business process development? Then, these five practices will help your teams achieve increased level of service reuse.

  1. Manage a common set of domain objects that are leveraged across service capabilities. This could be a library of objects (e.g. Plain Old Java Objects) or XML Schema definitions or both. Depending on the number of service consumers and the complexity in the domain, there will be need for supporting multiple concurrent versions of these objects.
  2. Provide common utilities for not only service development but WSDL generation, integration and performance testing, and ensure interoperability issues are addressed
  3. Appropriate functional experts are driving the service’s requirements and common capabilities across business processes are identified early in the software development lifecycle
  4. Governance model guidelines are clearly documented and communicated  – for example, there are a class of changes that can be made to a public interface such as a WSDL that don’t impact existing service clients and there are some that do.
  5. Performance testing needs to be done not only during development but during service provisioning – i.e. integrating a new service consumer. If your teams aren’t careful, one heavy volume consumer, can overwhelm a service impacting both new and existing consumers. Execute performance testing in an automated fashion – every time you integrate with a new client to reduce risks of breaching required SLAs

What additional practices do your teams follow?


Reusable Capabilities When Hosting Business Processes

November 7, 2011

Many teams are pursuing BPM and SOA based initiatives to automate, streamline, and standardize business processes. As more solutions start to embark on BPM-based solutions, there is a need for a common set of software components that aid in hosting and managing business processes. The following are capabilities that need to be present in such a solution:

  • Common messaging architecture & utilities for facilitating the development and maintenance of stateful business processes & stateless services.
  • Support business process orchestrations that join across multiple services (data services, business services, legacy services, etc.). This is essential for orchestrating complex 
  • Handle workflow and system business process events via a configuration driven Event Handler Service, enabling reuse of event handler processes
  • Provide  ability to reuse sub-processes across larger business processes.
  • Runtime metrics including reporting and the ability to perform diagnostic troubleshooting
  • Reusable schemas for request dispatching, event handling, generic transport listeners, metrics, and error handling
  • Supports synchronous and asynchronous request/reply & fire/forget message exchange patterns
  • Provides the ability to create reusable components for assembling new business processes
  • Standard client interfaces across multiple transports such as HTTP and EMS
  • Ability to query various data sources, rules engine, as well as write custom java code to integrate with existing functionality
  • Provides interface for executing administrative functions
  • Provides developer tools for WSDL generation, unit testing, deployment, & viewing metrics

10 Signs Services Are Accumulating Technical Debt

November 6, 2011

Your teams are busy building services and service enabled processes – great! – how do you know if these services are built at the appropriate level of quality? Here are ten signs that your services might be accumulating technical debt:

  1. Service contracts are modeled for a specific consumer, and/or exposes technical implementation details (e.g. service interfaces that force the client to set ‘default’ values on legacy system attributes).
  2. New clients are integrated to services without doing performance testing – this increases the likelihood of sudden spike in volume and consequently the risk of breaching SLAs
  3. Each service is implemented using an ad-hoc set of technologies, design patterns, and idioms – if you are starting to see the same functionality over and over being implemented across modules that’s a sure sign!
  4. Service dependencies are not captured and managed – each service uses a rat’s nest of dependencies causing classpath conflicts and maintenance burden when updating versions.
  5. Deployments are manual – binaries and configurations are assembled and made available via manual steps – automated deployment scripts either don’t exist or they are out of date
  6. Exceptions are not handled consistently – depending on the nature of the exception your service might need manual support intervention, adjustment to resources, and/or targeted alerts.
  7. Services are not reusing business object definitions and introduce redundant definitions instead
  8. WSDLs don’t import schemas and instead define them in-line – this might be easier to implement to start with but will cause a maintenance burden over time.
  9. Context information is not shared when implementing service to service interactions – as more reuse happens across services, it becomes essential to share context data among them. It will make authorization, logging, and integration much simpler
  10. Service business logic is in end point classes and not encapsulated well – if your service endpoints contain any logic beyond data transformation, question it to make sure that it really belongs there. Don’t implement validation rules, defaulting logic, or complex domain rules in them

In the upcoming post, I will elaborate on each of these above to provide concrete examples. Are there other signs you can think of?


Guest Post: Succeeding With Reuse In The Enterprise

March 18, 2011

Who doesn’t like the idea of reuse? It’d be like saying you don’t like mom, apple pie and puppies (or kittens if you’re a cat person). We can all say that we like the concept – but putting a successful reuse program into action has been a challenge.

To help increase the chances of success in running a reuse effort, we can embrace two ideas – having a target and leveraging the use of patterns.

Let’s start with the idea of having a target. In thinking about adopting reuse within an organization, a quote that I like is: “If you don’t know where you are going, any road will get you there.”[1] To help guide us in figuring out where we want our reuse program to take us, we can refer to a maturity model. A maturity model provides a summarized view\framework that incorporates industry experience, research and guidance. It’s a first step in reuse – reuse the experiences of others in setting up your reuse effort.

A maturity model can help us figure out where we are: What are our strengths? What are our weaknesses? There are a number of different models out there – but the important thing is to find a model that works for our situation. An example, the Reuse Maturity Framework[2] is shown on the right.

Reuse Maturity Model

We could quibble about a few of the aspects and characteristics – but it certainly gives us a great starting point in figuring out where we are today and where we want our reuse program to go. Each of the columns represents a stage in the maturity of the reuse effort. Moving from left to right shows an increase in reuse maturity. Each row maps to a characteristic\aspect of the reuse effort – highlighting that such an effort has multiple facets. Some of the key things that we can glean from this framework include:

  • Recognition that culture is a major component and we need to get past just incentivizing and make reuse a part of the organizational culture
  • Planning for reuse is part of the strategic effort within an organization
  • Assets that are acquired\created need to be managed and classified. If assets cannot be found easily and quickly – mapping to the needs of the moment – then they provide no value.
  • We need to consider the capabilities of the tools that we use and how they support reuse.
  • And related to tooling – not only do we need to capture metrics – but we strive to find ways to automate the collection of data and analysis of results.
  • Recognition that in most organizations it is the breadth of reuse that drives the need for greater structure and tooling, so that the cost of reuse is minimized while the value\return is maximized.

Moving on from the maturity model, we can now look at the use of patterns. As you may recall, patterns provide a proven best practice solution to a known, recurring problem. Patterns provide a concrete and tangible way for people to experience reuse. Which all sounds great – but the success of using patterns is limited when we take an ad hoc, inconsistent approach to using them and fail to measure and consider the impact that they deliver.

So we need to go beyond the simple statement of “use patterns” and look for an approach that provides more support. More specifically, we should follow Patterns-Based Engineering (PBE) – a systematic, disciplined and quantifiable approach to using both written and automated patterns in delivering software solutions. With PBE we look at how to improve how we identify, produce, manage and consume patterns. Recognizing that not only will we work with patterns provided by others – but we will also look at identifying and creating our own patterns. PBE help us to get started with reuse AND it helps us to reach higher levels on the maturity framework.

Those that have adopted PBE, have found it a great way to get started with reuse. It has helped them improve the quality of their solutions, deliver solutions more quickly, and better leverage skilled resources. To find out more about PBE, including a detailed case study, a development practice and a set of PBE patterns and guidelines – I encourage you to visit patternsbasedengineering.net.

About the author

Lee Ackerman, a Distinguished IT Specialist at IBM, has extensive experience with patterns, model-driven development, XML, data, and SOA. He has spent the past few years helping IBM build its Patterns-Based Engineering approach and offerings and has written and presented extensively on these topics.

You can follow Lee on Twitter or via his personal blog. Lee can be contacted via lee@patternsbasedengineering.net.


[1] Lewis Carroll

[2] Image is sourced from: DeCarlo, J., et al. 2008. Strategic Reuse with Asset-Based Development. IBM Redbook. www.redbooks.ibm.com/abstracts/sg247529.html which is based on work done by Koltun and Hudson as discussed in Lim, W. 1998. Managing Software Reuse: A Comprehensive Guide to Strategically Reengineering the Organization for Reusable Components. Upper Saddle River, NJ:Prentice Hall.


Follow

Get every new post delivered to your Inbox.