@CloudExpo Authors: Pat Romanski, Yeshim Deniz, Liz McMillan, Elizabeth White, Zakia Bouachraoui

Related Topics: Microservices Expo

Microservices Expo: Article

Is SOA Non-Trivial?

Exploring key service characteristics

For services to be of use to anyone they must be discoverable. Discoverability is usually taken to refer to the ability of consumers to find a relevant service by attributes (tags) at runtime via a service registry. In other words, consumers go to a service "yellow pages" and find, at runtime, services that best meet their needs.

In my humble opinion, this sort of runtime discoverability has not yet taken off despite all the hype. Service contracts are complex beasts that include non-trivial functional interfaces and runtime policies such as security and operational service-level agreements. Then there are the capacity management and funding considerations involved in service adoption. Such runtime discoverability is more suited to a market place were variation and competition thrive, than to internal corporate landscapes where reuse and lower total cost of ownership is a key driver.

However, services very much need to be discoverable in the sense that they are well publicized to the consumer community. Services will not be reused if they are not known about. Service registries must contain everything the consumer will want to know about the service, e.g., name, description, functional interface, locations, owner, operational and performance criteria, security model, invocation mechanism, cost, etc. but must equally importantly include tags that will make searches possible.

Having such a service registry is not enough though. Governance is required to ensure that development communities using the registry; governance not just in the stick sense, i.e., thou shalt use the registry or else, but also in the carrot sense - here's why it benefits you and here's how easy it is to do. It is important to capture the hearts and minds of both development and business communities. Reuse is like recycling: fine in principle, with everyone keen to do it, until it becomes inconvenient.

A service is said to be stateless if the consumer of that service can make use of any operating instance of that service. This is achieved by services not storing any internal data (state) that would be required if the consumer happened to invoke another instance of that service.

In general this goal is achieved by ensuring that all service data (including state) is kept in an external store common to all instances of that service.

However, for performance reasons, service implementers are often inclined to cache back-end system query results or consumer session data. The reason for this is that the back-end systems and data stores that are accessed by services often become points of contention and a source of bottlenecks, so avoiding the need to query those systems through caching at the service tier is attractive.

Service-tier caching requires that cached data is available at all service instances, and that these instances are kept in sync both with each other and the underlying data store. Achieving this requires fairly sophisticated cache management software with cache refresh, propagation and invalidation mechanisms, as well as volatility analysis of the data being cached - the less volatile data is, the more suitable it will be for caching.

JEE applications servers such as WebLogic and JBoss offer HTTP and stateful EJB session state caching that can be replicated across a cluster and persisted to a variety of data stores for failover purposes. In addition, consumer connections to servers can be made "sticky" so that a given consumer will always return to the same server and only be redirected to another server in a failover scenario. This is fine as long as either the state is replicated or the consumer is happy to lose some conversational state in the rare instance that a server becomes unavailable. It is also possible to store consumer state on the client, either via client cookies or via URL rewriting. WebLogic, for example, can be configured to use either depending on whether client browser cookies are enabled or not. Note that session state replication limits the linear horizontal scaleability of clusters.

A viable and arguable simpler alternative to all of the above (where network latency between service and data tiers is not an issue) is to perform caching in the data tier using, for example, a DBMS feature such as Oracle RAC, which provides a cluster of processes with data caches to improve performance and resilience.

Statelessness is a key characteristic of services, which is essential for a scalable and fault-tolerant SOA. State may be introduced if required but only after careful consideration as it will require complex and potentially less fault tolerant cache management facilities.

Services should be distributable, that is they need not and indeed should not run in the same process as the consumer. Services that run in the same process offer no possibility of runtime reuse to other consumers.

In order to achieve this goal, you minimally need two things: a remoting framework and location transparency.

1. Remoting Framework
A remoting framework is the mechanism whereby consumers are able to locate and invoke remote services. Typically for SOA this means web services, though less interoperable protocols such as JEE and .NET may also be used, for example, where performance is a critical criterion. However, such decisions should not be taken lightly - the ability to interoperate is key to achieving reuse across the enterprise.

2. Location Transparency
Location transparency refers to the ability of a consumer to use a service without knowing where that service is running. This may be achieved to a degree through the use of DNS names hiding IP addresses, or creating server clusters fronted by an IP load balancer virtual service address. However, both of these still bind the consumer to a logical instance of the service. In contrast, a service registry provides additional decoupling in that consumers are searched for by attribute (e.g., name and version number) rather than being bound by name.

Location transparency is also required of the service implementation. Services should not be tied to any particular location, both for capacity planning reasons where it may be required to move services between servers to support load, but also for portability reasons. Achieving environment independence is achieved by running services in a container such as JEE or Spring that insulates the services from the underlying infrastructure, as well as ensuring that services are stateless.

For a service to be manageable, the operating organization and infrastructure need to be capable of managing services. I won't repeat what I wrote previously in my article on applying ITIL to Service Management (http://soa.sys-con.com/node/702159), but I will say that in terms of runtime manageability it is important that services perform consistent, traceable, and monitorable error and audit logging, and can be monitored in terms of SLA adherence.

For those of you who are still awake, well done and thank you. Hopefully you have a better appreciation of the complexity involved in achieving some of these "little" service characteristics that are so often quoted.

SOA is non-trivial, and anyone who tells you otherwise is trying to sell you something.

More Stories By Robert Morschel

Robert Morschel is chief architect at Neptune Software Plc and has extensive experience in distributed software development for companies such as British Telecom, Nomura and Fidelity Investments. He blogs on SOA at soaprobe.blogspot.com.

Comments (0)

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.

CloudEXPO Stories
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by FTC, CUI/DFARS, EU-GDPR and the underlying National Cybersecurity Framework suggest the need for a ground-up re-thinking of security strategies and compliance actions. This session offers actionable advice based on case studies to demonstrate the impact of security and privacy attributes for the cloud-backed IoT and AI ecosystem.
Sanjeev Sharma Joins November 11-13, 2018 @DevOpsSummit at @CloudEXPO New York Faculty. Sanjeev Sharma is an internationally known DevOps and Cloud Transformation thought leader, technology executive, and author. Sanjeev's industry experience includes tenures as CTO, Technical Sales leader, and Cloud Architect leader. As an IBM Distinguished Engineer, Sanjeev is recognized at the highest levels of IBM's core of technical leaders.
DXWorldEXPO LLC announced today that ICOHOLDER named "Media Sponsor" of Miami Blockchain Event by FinTechEXPO. ICOHOLDER gives detailed information and help the community to invest in the trusty projects. Miami Blockchain Event by FinTechEXPO has opened its Call for Papers. The two-day event will present 20 top Blockchain experts. All speaking inquiries which covers the following information can be submitted by email to [email protected] Miami Blockchain Event by FinTechEXPOalso offers sponsorship and exhibit opportunities.
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on organizations of all sizes and in every line of business. Fintech is a constant battleground for this technology expanding trend and the lessons learned here can be applied anywhere. Digital transformation isn't going to go away and the need for greater understanding and skills around managing, guiding, and understanding the greater landscape of change is required for effective transformations.
Digital transformation is about embracing digital technologies into a company's culture to better connect with its customers, automate processes, create better tools, enter new markets, etc. Such a transformation requires continuous orchestration across teams and an environment based on open collaboration and daily experiments. In his session at 21st Cloud Expo, Alex Casalboni, Technical (Cloud) Evangelist at Cloud Academy, explored and discussed the most urgent unsolved challenges to achieve full cloud literacy in the enterprise world.