From the IBM WebSphere Developer Technical Journal.

Group hug

SOA happens. And when it does, it happens to the whole enterprise, not just the IT department.

Different organizations within the enterprise -- which may have operated fairly independently up to now -- are suddenly being asked to reuse each other's services and sponsor the creation of shared services. There may be some misgivings about this new "shared fate" arrangement. For example, organization A had created critical service X to support one of their solutions. They don't want to expose the service for other organizations' applications to invoke because they don't control the other applications and are concerned that the other applications might break it. Plus, if organization B's applications break the service, it will cause an outage to organization A's solution too. It sounds like everyone is putting their eggs in the same basket, so to speak.

This concern is well founded and in fact must be addressed through diligent assessment of the required quality of service that needs to be associated with a given shared service. Different organizations may depend on different qualities of service for the same shared service, and if they differ enough, it may make financial, if not administrative, sense to deploy the service twice.

Now, before organizations start to quibble over the optimal quality of service for a share service, they might want to agree on what the interface to the shared service needs to look like. If organization A and organization B have both created similar services in the past, there will no doubt be some discussion around what combination of the interface exposed by A's service and that of B's service ought to constitute the interface for the shared service. Such discussions are invariably passionate, with both organizations keenly aware of the effort required to accommodate changes in the interface to the service on which they have come to depend. Deploying facade services that translate between the previously existing services and the new shared service can ease the transition.

There will most likely also be some business entity passed between the service invoker and provider. Who ought to define how that entity is represented? Well, indirectly, "the business" ought to. A business glossary should be developed that textually describes business concepts like "vendor" and "item" and so forth. It should also capture some of the dynamic aspects of each concept, like how it is created and consumed within the business. From the glossary, a logical business information model is derived by "the business" in collaboration with data architects. From the logical business information model, you can derive both a persistence model (which can be expressed in DDL) and a service information model (which can be expressed in XSD).

As you can see, not only do IT staffers from different organizations have to start meeting with each other, but their corresponding business staffers need to do likewise. Like the IT folks, these are busy people and might require some convincing that they have a role to play, albeit indirect, in defining the service interfaces, but until this type of agreement can be reached at a business level, IT is just guessing at requirements.

Back to top

Coupling and decoupling: Dealing with new relationships

Okay, so now everyone's talking to everyone else and we've all played our role so that the dang shared service can be created, right? Well, technically, yes... but since each organization is currently funding its own IT spending, who's going to fund the shared service? Will the shared service be hosted in the IT department of one or other of the dependent organizations, or will some shared services organization be created and somehow funded? If it is hosted in one of the existing organizations, will the other one(s) contribute to scaling the service implementation so that it can support all dependent organizations' needs? If the service is hosted by some shared service organization, will that organization be funded centrally, or from the budgets of the organizations who depend on the shared services? Speaking of funding, what's the cost model for shared services? If a new technology such as IBM® WebSphere® Process Server is needed for a given service, and it's the first service to drive the need for the new technology, is the entire cost of that new technology (staffing, training, ancillary monitoring, management, maintenance costs, and so on) attributed to the new service, or is it somehow amortized over the next services to leverage the new technology?

There are many different ways these realities can be addressed, and while the "correct" solution will vary from organization to organization, it's important that the need to resolve this aspect be recognized and planned for. This organizational coupling, introduced by the desire to reuse services and better align IT with the business, might benefit from facilitation by experts in organizational change, such as is available through IBM's Global Business Services unit.

Having looked at an area where SOA techniques increase coupling, let's now turn our attention to an area where coupling is decreased between organizations. This time, both organizations are subsections of IT. I'm referring to the application development teams and the data (or information) management team.

One technique that, in my opinion, may not be receiving sufficient attention is that of "information as a service" or IaaS. The principle is simple enough: to technically and organizationally decouple applications from information, a proxy service is introduced between applications and the information they consume. The application domain is owned by an application development organization, and data management (or information) is owned by the data team. The application team accesses information in canonical form (remember the service information model?) through canonically derived interfaces and has no interest in how it is produced. The data management team decides how the information is stored and where it is persisted.

When changes are made in either domain, they need not affect the other. For example, a common situation in established firms is for information to exist in multiple locations in the data center. Accounting and buying departments may have their own semi-autonomous databases with their own variations of definitions of "vendor," along with a mostly overlapping -- but not identical -- set of vendors represented. At some point, the business might agree on a canonical definition of "vendor." Vendors are accessed (created, read, updated, deleted and searched for; hence CRUDS) via an information service using a service information model derived from the business information model. All new applications should use the canonical form and when possible; any updated applications should adopt it as well. To minimize "object model impedance" (the run time and maintenance overhead of translating between object models), applications should internalize the vendor service information model. This is facilitated by tooling that readily generates application technology representations of elements expressed in service interfaces. For example, if the IaaS service interface is expressed in WSDL and the application technology is Java™, there is wide tooling support to generate Java classes from WSDL interface definitions. Naturally, the application may need to extend the generated class by either derivation or encapsulation for its own purposes.

Back to the vendor service now. The data team owns the responsibility for producing the vendor service and there is some tooling support for this in products like IBM Information Server. The service may be a thin facade over familiar data access techniques, like embedded SQL or Hibernate or, preferably, it could be an off-the-shelf package providing federation, cleansing, and transformation capability. This latter approach will facilitate gathering the different representations of vendor from across the enterprise and re-exposing them in canonical form. In addition, there is a real opportunity to optimize some data governance aspects through the integration of the tooling used to capture the business glossary, derive the business information model, manage the information services, and create cleansing and transformation rules.

On a side note, I bumped into a company the other day wherein the application development team was concerning themselves with object to relational mapping (ORM) techniques. Having the application development team concerned with ORM is the antithesis of encapsulation and decoupling. ORM might (and I'm not promoting it) have a role to play in the implementation of the service, which as we agreed (you did agree, didn't you?) that was the domain of the data team. I strongly recommend using frameworks or tooling to avoid this problematic aspect of managing data.

Back to top

Business and IT alignment

Let's turn our attention to another aspect of SOA that introduces the requirement for coupling, or as we might refer to it in marketing materials: alignment. I state the objective as alignment of points of variability in business and IT. Variants in the business domain should not be implemented as invariants in the IT domain. Why I'm talking about this issue in a discussion of SOA is that we sometimes run into this problem with respect to service interface definitions, which are invariants to IT people.

Here's an example I saw recently: A company wanted to make consistent business decisions across the enterprise and channels. It sensibly extracted the business logic into a business rules engine and provided access to the business logic via a Web service. Suppose the service was a "getEligibleProducts" service and the business rules used known facts about a customer to deliver a list of products offered by the company that might be interesting to the customer. On Day One, when IT sat down with the business to determine what the interface to the service might look like, the business expressed an interest in using customer weight, height, and postal code in the business rules to calculate eligible products. After the service had been created and deployed and consumed by at least one solution, the business team mentioned in passing that they just wanted to add a rule that took into account the customer age as well. The service interface expects weight, height, and postal code specifically, not age. The IT team estimated that it would take at least a month, possibly two, to make the changes to the service provider and consumers and perform the necessary testing. The business team, predictably, gets upset that "this whole SOA thing was supposed to make IT more agile, but it's making it worse."

In the particular case I saw, IT had responded to this issue by passing every known fact about the customer (some 800 elements) to the service, which then made use of a very small percentage of them (about 5 elements). The idea was that whatever facts the business wanted to incorporate in the rules, they'd be available to the service. Well, there is a non-zero processing overhead for XML which increases with complexity and cardinality of elements and, depending on the usage pattern for the service, this solution could introduce performance issues. Academically speaking, it only defers the problem it aims to fix anyway, because when more facts are gathered about customers at some point in the future, the interface will need to change. There are many variants on alternative solutions but they all boil down to not realizing a variable business concept in an invariant concept in the IT domain. One proposed solution was to make the clients more sophisticated to accommodate the variation in required parameters. The service interface would expose a container of attributes, which would comfortably contain more or fewer attributes in accordance with a business whim. The client would look for information in the service registry to indicate which facts were required for the service and include them in the container. Naturally, this approach removes some of the development type safety aspects of specifying the exact parameters in the service interface, thus introducing the need for some more error handling in the service, but you gotta do what you gotta do.

These are but a few examples of how SOA can affect coupling, relationships, and interactions between organizations that either previously didn't interact or may have done so less formally. It can be a challenge and it can be fun rolling out your SOAs, so let me know how it's working for you.

Resources

Learn

• Defining SOA as an architectural style
  
  
• IBM Information Server, IBM's product for delivering information as a service
  
  
• IBM developerWorks SOA and Web services zone
  
  
• New to SOA and Web services
  
  
• IBM Service-Oriented Architecture
  
  
• IBM developerWorks WebSphere
  
  

Discuss

• Best Practices for SOA and Web Services
  
  
• The perils of Object Relational mapping
  
  

About the author

Tony Cowan is a senior consultant with the IBM Software Services for WebSphere (ISSW) team in IBM. He has been consulting in distributed system development for over 11 years and has lead IBM teams on many projects with Fortune 1000 companies. Tony currently focuses on teaching Web services and Web services security to IBM consultants and customers. A frequent speaker at technical events, one of Tony's primary objectives at IBM is to bring real customer requirements to the IBM development teams to assist in aligning IBM products with real world needs. You can contact Tony at ttcowan@us.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Group hug
• Coupling and decoupling: Dealing with new relationships
• Business and IT alignment
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers