So, what's one of the first and most difficult steps in defining your SOA? It's having a complete semantic and service level understanding of your domain, of course. While the work required is pretty straightforward, the amount of effort and time required is typically huge, and the enabling technology or tools you can employ are complex and emerging. Thus, it pays to spend some time up front planning exactly how So, what’s one of the first and most difficult steps in defining your SOA? It’s having a complete semantic and service level understanding of your domain, of course. While the work required is pretty straightforward, the amount of effort and time required is typically huge, and the enabling technology or tools you can employ are complex and emerging. Thus, it pays to spend some time up front planning exactly how you’re going to do this step, and what tools you may use to make this job easier. Why are we doing this? Let’s face it; you can’t deal with information you don’t understand, including information bound to behavior (services). Thus, it is extremely important for you to identify all application semantics—metadata, if you will—and services that exist in your domain, thus allowing you to properly deal with the data and services that are there, and understand the inner workings as well. Remember, the goal here is to create a service level abstraction of the existing systems, and at this point, we’re merely just figuring out what’s there. The best place to begin with service and data is with the creation of a services directory. As with other directories, this is a repository for gathered information about available services, along with the documentation for each service, including what it does, information passed to a service, information coming from a service, etc.. This directory is used–along with the now-understood application semantics–to define the points of integration within all systems in the domain. While you could certainly do this using Word, Excel, or other small databases, there are a few tools on the market that are beginning to show up to provide you with a repository or registry customized for SOA, typically with other features added in as well. So, what’s the difference between an SOA repository and an SOA registry? An SOA repository is a persistence mechanism that stores information published to an SOA registry. An SOA registry is a resource that enterprises share to publish, discover, and consume Web services. Content such as XML Schemas, Document Type Definitions (DTD) and Web Services Description Language (WSDL) documents can be persisted in an SOA repository, which is then used in an SOA registry. If you get this right, you’re setting a good foundation for your SOA…trust me. Software Development