Welcome!

Log Management Authors: Dana Gardner, Pat Romanski, Elizabeth White, David H Deans, Carmen Gonzalez

Related Topics: Microservices Expo, IBM Cloud, Microsoft Cloud, Recurring Revenue, Artificial Intelligence, Log Management, Server Monitoring

Microservices Expo: Article

The Concrete Abstraction of the Business Service

Even in the SOA context, the word "Service" has multiple meanings

It may come as a surprise to our long-term readers that even after seven years of talking about Web Services and Service-Oriented Architecture (SOA), ZapThink still has something novel and interesting to say about what a Service truly is. But in fact, although we define the term repeatedly for business, technical, and mixed audiences, there are still some subtleties to the definition that underscore the fundamental nature of the Service abstraction, and they also underscore the connection between that abstraction and some of the infrastructure choices Service-oriented architects must make. So, without fear of tripping up on the oxymoron of a concrete abstraction, let's delve into what ZapThink really means by a Service.

Implementations, Interfaces, and Abstractions
As we discussed in our Subtleties of Service Convergence ZapFlash, the term "Service" is overloaded even within the IT context. But while that ZapFlash differentiated between the Services we speak about in the context of SOA from other IT services, this ZapFlash focuses only on the subtleties of the definition within the SOA context entirely. Even within this relatively narrow context, however, people still often get confused about the level of abstraction of a Service. Basically, there are three levels of abstraction we work on in the context of SOA:

  1. Service implementation -- at this level of abstraction we're talking about software. A Service implementation is made up of running code. This is where the Service Component Architecture (SCA) lives, as it deals with Service components, which are implementations can consume or provide Services (in the sense of #2 below).
  2. Service interface -- Web Services live at this level, as a Web Services Description Language (WSDL) file provides a contract for the interface, but says nothing about the underlying implementation. Web Services, however, are not the only kind of Service interface, because Service contracts are not always WSDL files. Sometimes Service interfaces are loosely coupled, but many times they're not.
  3. Abstracted Service -- A representation of a business capability or data that the organization can compose with other such Services to implement business processes. An abstracted Service is typically a business Service, but not necessarily, as there is a role for abstracted IT Services as well. However, all business Services should be abstracted Services. Such business Services are the sorts of Services ZapThink focuses on, as they are the core abstraction that underlies SOA. Abstracted Services should always be loosely coupled, although the specific coupling requirements can vary. Building loosely coupled abstracted Services thus becomes the core technical challenge of implementing SOA.

So far so good -- but the real question here is how we make an abstracted Service actually work, when the tools at our disposal are the Service implementations and interfaces and all the infrastructure that goes along with them. It's one thing to talk about "representations of business capabilities," and quite another to string your ones and zeroes together into something that actually runs.

Service Contracts, SOA Infrastructure, and Loose Coupling
The first critical point to understanding abstracted Services is to understand that there is typically a many-to-many relationship between Services and Service contracts, as ZapThink explained in our Understanding the Relationships among Services, Contracts, and Policies ZapFlash. Clearly, a Service implementation may support multiple contracts, each of which could correspond to a particular Service interface, for, say, a particular type of consumer. Similarly, there might be several implementations that support a single contract, and hence a single Service interface, for the purposes of scalability or fault tolerance, for instance.

With abstracted Services, however, the relationship becomes what we might call "many-to-many-to-many": a particular abstracted Service might have several contracts that represent relationships with various consumers, while also representing multiple Service interfaces that themselves might each have one or more Service implementations. This approach might sound overly complex, but it's the key to loosely coupling the abstracted Service. To illustrate this point, let's work though an example.

Let's say we have a Customer Information Service that different lines of business in a large enterprise can consume and compose to provide or update any information about their customers that the lines of business might need. From the business perspective, this is a single business Service that any line of business can use as per the policies set out for that Service. From the IT perspective, however, it makes sense to implement the Customer Information Service as a set of Service interfaces with different Service contracts in order to support the somewhat different needs for customer information that the various lines of business might have. Furthermore, each Service interface may represent several Service implementations that the SOA management infrastructure can leverage as necessary to meet the service levels set out in the contracts for both the abstracted Service as well as the Service interfaces, in addition to the policies that may apply to these Services as well as other Services in production.

In this example, the complexity beneath the Service abstraction is necessary to support the loose coupling of the abstracted Service. For example, the line of business consumers may need different formats for the customer information, or may require different data as part of the response from the Service. To loosely couple such consumers, an intermediary (or set of intermediaries) may perform a transformation that can take the output from any of the Service interfaces and put it into the format the particular consumer requires, as per the contract in place that governs the relationship between that particular consumer and the abstracted Service. Then, either the management infrastructure (or possibly the integration infrastructure) may offer content-based routing of the requests from particular Service interfaces to the underlying implementations, based upon runtime policies in effect at the time.

Furthermore, a Service interface may support several contracts, for example, when one Service interface has multiple bindings. In the case of a Web Service, each WSDL file specifies a binding, so to support more than one, there should be multiple Service contracts for the Service interface. Each binding may then correspond to its own Service implementation, or in the more general case, multiple implementations may support each binding, or one implementation may support multiple bindings.

In any case, loose coupling means more than being able to support different consumers with different needs. It also means building for change. Because we have a governance and management infrastructure in place that enables this many-to-many-to-many relationship among abstracted Services, Service interfaces, and Service implementations, we are able to respond to those changes in a loosely coupled manner as requirements evolve -- in other words, without breaking anything.

For example, if one consumer changed its required data format, we could introduce a new contract which might require a new transformation on the intermediary between the Service interface and the abstracted Service, but wouldn't impact the Service interface directly or any of the Service implementations. Another example might be the need to upgrade or add a new data source to support the Service. Such a change might require a new implementation of one or more Service interfaces. But if the contracts for those interfaces don't change, then the abstracted Service is unaffected, and neither are the consumers. A third example would be a policy update that would change the content-based routing behavior between the Service interfaces and their implementations. In fact, we see this application of content-based routing as more of a management challenge than an integration task because of this need to support runtime policy changes.

The ZapThink Take
There's an interesting side-effect of taking this Service-oriented approach to implementing abstracted Services: it becomes difficult to count how many Services you have. Sure, in this example, you have one Customer Information Service from the business perspective, but it actually might have several Service contracts, each of which have several interfaces -- and those interfaces may change in number over time. How you count your Services may impact your SOA maturity model, for example, or even your software licensing costs, so this question may be more important than it seems.

But in the final analysis, the most important thing to remember is that the Customer Information abstracted Service is but a single example. In the general case, the architect must select from a variety of SOA infrastructure patterns depending on the specifics of the problem at hand, as we explained in our recent SOA Infrastructure Patterns and the Intermediary Approach ZapFlash. The bottom line is that loose coupling presents architectural challenges that are at the heart of planning and implementing the SOA infrastructure. Building the Service abstraction presents a simplified representation to the business but requires additional efforts under the covers to make that abstraction a concrete reality. This is the work of SOA: implementing and maintaining loosely coupled business Services that are at the core of any successful SOA implementation. Learn more at one of our upcoming Licensed ZapThink Architect Bootcamps or SOA & Cloud Governance courses.

More Stories By Jason Bloomberg

Jason Bloomberg is a leading IT industry analyst, Forbes contributor, keynote speaker, and globally recognized expert on multiple disruptive trends in enterprise technology and digital transformation. He is ranked #5 on Onalytica’s list of top Digital Transformation influencers for 2018 and #15 on Jax’s list of top DevOps influencers for 2017, the only person to appear on both lists.

As founder and president of Agile Digital Transformation analyst firm Intellyx, he advises, writes, and speaks on a diverse set of topics, including digital transformation, artificial intelligence, cloud computing, devops, big data/analytics, cybersecurity, blockchain/bitcoin/cryptocurrency, no-code/low-code platforms and tools, organizational transformation, internet of things, enterprise architecture, SD-WAN/SDX, mainframes, hybrid IT, and legacy transformation, among other topics.

Mr. Bloomberg’s articles in Forbes are often viewed by more than 100,000 readers. During his career, he has published over 1,200 articles (over 200 for Forbes alone), spoken at over 400 conferences and webinars, and he has been quoted in the press and blogosphere over 2,000 times.

Mr. Bloomberg is the author or coauthor of four books: The Agile Architecture Revolution (Wiley, 2013), Service Orient or Be Doomed! How Service Orientation Will Change Your Business (Wiley, 2006), XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996). His next book, Agile Digital Transformation, is due within the next year.

At SOA-focused industry analyst firm ZapThink from 2001 to 2013, Mr. Bloomberg created and delivered the Licensed ZapThink Architect (LZA) Service-Oriented Architecture (SOA) course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, which was acquired by Dovel Technologies in 2011.

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting), and several software and web development positions.

IoT & Smart Cities Stories
Apps and devices shouldn't stop working when there's limited or no network connectivity. Learn how to bring data stored in a cloud database to the edge of the network (and back again) whenever an Internet connection is available. In his session at 17th Cloud Expo, Ben Perlmutter, a Sales Engineer with IBM Cloudant, demonstrated techniques for replicating cloud databases with devices in order to build offline-first mobile or Internet of Things (IoT) apps that can provide a better, faster user e...
In his keynote at 19th Cloud Expo, Sheng Liang, co-founder and CEO of Rancher Labs, discussed the technological advances and new business opportunities created by the rapid adoption of containers. With the success of Amazon Web Services (AWS) and various open source technologies used to build private clouds, cloud computing has become an essential component of IT strategy. However, users continue to face challenges in implementing clouds, as older technologies evolve and newer ones like Docker c...
Disruption, Innovation, Artificial Intelligence and Machine Learning, Leadership and Management hear these words all day every day... lofty goals but how do we make it real? Add to that, that simply put, people don't like change. But what if we could implement and utilize these enterprise tools in a fast and "Non-Disruptive" way, enabling us to glean insights about our business, identify and reduce exposure, risk and liability, and secure business continuity?
The Founder of NostaLab and a member of the Google Health Advisory Board, John is a unique combination of strategic thinker, marketer and entrepreneur. His career was built on the "science of advertising" combining strategy, creativity and marketing for industry-leading results. Combined with his ability to communicate complicated scientific concepts in a way that consumers and scientists alike can appreciate, John is a sought-after speaker for conferences on the forefront of healthcare science,...
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
"The Striim platform is a full end-to-end streaming integration and analytics platform that is middleware that covers a lot of different use cases," explained Steve Wilkes, Founder and CTO at Striim, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
"MobiDev is a Ukraine-based software development company. We do mobile development, and we're specialists in that. But we do full stack software development for entrepreneurs, for emerging companies, and for enterprise ventures," explained Alan Winters, U.S. Head of Business Development at MobiDev, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...