Employ established architectural modeling techniques such as generalization, decomposition, and aggregation.
Once you have determined a reasonable candidate service, model the service using a set of techniques, refactoring its definition until you know what kind of service it is, you feel comfortable with its definition and level of granularity, and you’re sure it’s still a service.
To aid in this effort, employ these information modeling techniques:
Analyze your service to determine what it represents conceptually, in general terms. In object-oriented (OO) programming, this is called finding IS-A relationships. You want to find the appropriate level of generalization for your service. You may determine that a Customer is a Person and an Employee is a Person too. This could be a useful degree of generalization within your enterprise. But the fact that a Person is a Homo sapiens may be the wrong degree of generality for your dot com. Perhaps the more common problem is that you do not get general enough in your design, failing to realize what aspects of different components truly align and differentiate them. Designing services at too specific a level can shrink their possibility for reuse, and make for very complicated interfaces and orchestrations, defeating the very purpose of your SOA efforts.
It doesn’t matter what kind of service you’re working with. The Person example shown earlier regards an entity, but it’s the same for a process service.
Analyze your service to determine what other elements it composes. Such analysis can reveal functional or entity services that may be worthy of standing alone in their own right. In some cases, your process will be composed of other independent processes. Note that the finer grained your service is, the better chance of composability and reuse it has. The coarser grained your service is, the more interoperable it is, and the more suitable it is for a client-facing endpoint.
Analyze your service to determine what other elements it may be a part of. These elements may be existing processes, services, or service candidates themselves. In object-oriented programming, this is called finding HAS-A relationships. Employing this technique can help you discover composable services.
These are foundational techniques and will serve you well. But for service modeling, you need to look beyond these basic principles and consider these additional aspects:
This is often considered in object-oriented design, but not to the extent that it must be within a service model. To determine how to write the contract, you need to perform a systems analysis that gives you the best guess on how it will be reused throughout your enterprise. When it’s not certain how the service will be reused, keep it sufficiently generic to promote the possibility of reuse.
This is typically dealt with at the application level for objects, but it must be modeled at the individual service level when you’re creating services. You will have an overall security model for your SOA that might include SAML, a Policy Enforcement point, transport security, digital signatures, Kerberos, or other related measures. These are typically indicated in policies enforced by tools to support the contract.
Java objects only have to work with other Java objects. But services are intended to interoperate. As you model a service, you must consider it from this viewpoint, identifying other platforms you’ll be working with. Adhering to the Basic Profile (discussed later) helps here.
Services, like the systems they wrap, should have defined service-level agreements. The business process your service participates in might need to respond within 100 milliseconds, or a flag should be raised. This is particularly important in an SOA because eventually your well-designed service will be reused by many processes, and analysis at the process level will be important to helping the business understand what it can expect.
Your service will participate in an evolving landscape of many services. Getting the proper level of granularity is key to ensuring that you can reuse a service, that you can expose it successfully to your business partners, and that your security constraints will be appropriate.
Within your model, identify what elements you will need in your overall service contract. Some of these may be direct attributes of the service, and others may serve as metadata that you make available within the context of WS-MetadataExchange. Some elements will be non-functional, and some can be declared and enforced within the sorts of SOA runtime environments offered by commercial vendors.
Process analysis is a discipline all its own, probably unfamiliar to many OO developers. Because business processes can be represented as services, and because business processes will make use of services, it’s important to understand the IT world from this perspective. A real discussion is beyond the scope of this book, but if you have business analysts and Lean or Six Sigma professionals in your organization, they can be a very valuable resource.
Consider these things when you are modeling a new service, in addition to the object-oriented analysis skills you bring to bear.
I only touch on the subject of SOA modeling briefly here. As mentioned earlier, the ideas surrounding SOA, service modeling, process modeling, and so on fill entire books. This chapter is intended to give a grounding in some of the key concepts. If you are interested in SOA modeling, you might check out Michael Bell’s book Service-Oriented Modeling: Service Analysis, Design, and Architecture (Wiley).
Document the service candidates you elicit with an enterprise view. Do this as an iterative process, using a standard format, in order to visualize your service-enabled enterprise. This documentation must ultimately be composable into a larger enterprise service catalog.
Be careful of attempting to model your entire business up-front. Circumstances are likely to change before you complete such an effort. It is reasonable to take a more modular approach here, working with a single business domain, system set, or problem, and model that using an iterative approach. Eventually your models will meet at domain or functional borders.