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
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:
- 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).
- 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
- 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!
- 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.
- 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
- 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.
- Services are not reusing business object definitions and introduce redundant definitions instead
- 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.
- 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
- 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?