MSDN Utopia : SOA

Design: SOA Taxonomy, an object oriented approach

Salva Patuel — Tue, 02 Sep 2008 14:05:00 GMT

An essential part of the SOA Governance is to properly identify the requirements in order to introduce or upgrade a service within your SOA model, this is commonly known and service and integration planning within the SOA lifecycle. This is all good in theory but the nightmares start when architects are trying to put it in practice.

As an application development consultant here at Microsoft we constantly find chaos in the SOA first attempts, the main reason behind this is the lack of services organization. This not only brings problems to the model that are expensive to change but does not shows business value to the stakeholders, as they cannot see any ROI in the implementation. As a result, the efforts are abandoned and the architectural model remains broken.

How do we help our customers to solve this issue? We usually take them a level higher within the abstraction layer, why do you need SOA? Which are the problems that you usually have? Which are the costs involved in changing your system? We really need to understand our driven forces that lead us to a new architectural paradigm.

But what about designing the services model? This is another area where confusion arises as architects ask themselves where they should start and how. The answer to this is enclosed on the services taxonomy. There are many categorizations and naming around taxonomy but I want to present a recommendation based on the Microsoft services experience.

We define four main categories that really help us to define the high level model. Let me explain each one of them.

· Entities Services: The entities encloses your business entities, these are independent actors within your business model. The entities do not provide business benefit acting alone as they don’t have the expertise around which other entities are around. They should be completely independent and should own the data repository. A good example of an entity service will be customers. Customers are nothing more than what the name says, it has and owns all the information about the entity “customer” but knows nothing about your business.

· Capabilities Services: This is the crucial part of your business; this is what you do to add value to your services. The capabilities know very well the entities and capabilities context where it works, as interacts and consumes services to deliver value. An important thing to understand is that they know about the capability but do not control the entities that consumes, this means that if a capability needs to alter an entity it should use the entity service responsible for that. The capability also owns its own repository and controls all the business logic associated with it. A good example of a capability is an order service. The order service will know everything about placing an order and will need entities in order to generate one, for example, the order will need the customer information that comes from the entity service.

· Application services: These services supports your business model, this means that provides auxiliary services to your entities and capabilities not directly associated with your system. This usually involves wrappers to third party application or bridges to other systems. A good example may be a service wrapper to a Remedy application.

· Bus services: This taxonomy groups all the support and infrastructure services that allow your entities and capabilities to work within the infrastructure policies. For example the security services that validate users can be grouped in this taxonomy.

As you see, with this categorization you can start to add services to your model. Where do you start? The easiest way to do it is asking yourself what your business does, what is the essence of it. Let’s imagine that you are the responsible for designing the SOA model for a large supermarket. The amount of services that you will need is massive but if I ask you about the essence of your business which will be the answer? Believe it or not this sounds easy but architects that are too embedded in the daily duties cannot properly answer the question. My model would be:

Look how simple it is, you just join customers with products and generate orders. Now, if I ask you to add these services in the taxonomy model you now know how to do it.

Remember that upon I have presented orders as the linking service between the entities this does not suggest hierarchy. All the services are at the same level as they can be accessed by an ESB (Enterprise service bus) or ISB (Internet service bus), or even simply your process layer. What is more, what you can do is apply the same model when you enter into the service design scope; this is for example when you design the internal taxonomy of “Orders”. This service will have again a process layer, entities and capabilities, but now only around the orders scope. Does this sound familiar? Well, it may, as it is a common model applied to the object oriented design.

Internally, these new entities and capabilities can be isolated components that are responsible for a solely function, for example, an internal process can be the workflow that triggers a new order and a capability may be altering the order value.

This can show you that applying the SOA governance model around taxonomy can help you and your developers to properly design services and object oriented components properly isolated and encapsulated, as is the same mindset. What is more, the WCF team is working in a “in-process” binding that will allow you to use a WCF communication with objects that today are part of your main process and tomorrow may develop into independent services just changing the configuration file! Isn’t it beautiful?

If your organization is facing these problems and you want Microsoft to support you and help you around your SOA initiative don’t hesitate the contact the “Application Development Consultant team” in Microsoft (http://www.microsoft.com/uk/adc)

Architect: SOA services lifecycle

Salva Patuel — Fri, 13 Jul 2007 16:11:00 GMT

Beyond the natural MSF lifecycle where all software development should fit in, there is a higher level of process lifecycle abstraction that relates to the service. Services are one of the most important backbones of a SOA model, where the business capabilities and activities interact with the entities to provide the solution response.

From the architectural point of view, services born, live and die. In order to use a common definition we are going to divide it in three states: expose, compose and consume. The architect is responsible to govern and manage this lifecycle with a clear visibility of the current status of each individual service. This will help to empower reusability and to have a better control when change occurs, what is more, is the recommended path to migrate architectures that contain legacy monolitic systems in order to reach the dynamic level on the application platform optimization model.

Expose: This first step consist in analysing the business drivers (processes) that are going to be addressed. This helps to indentify the necessary services that will solve the process requirement. With the services indentified the reuse (or new green field) services are exposed.

Compose: In this stage the serivces are composed depending on the type of process, if this requires an orchestration of many services this is the place to do it. This stage will incorporate the necessary knowledge to use the business services.

Consume: The client applications are able to discover and use the services based on the processes that govern them.

The lifecycle granularity can be further exploded into specific activities that will categorize the service in a specific domain. This domain has specific implications and the architect will need to embark into the different tasks and responsibilities that each step brings. This is not a fixed model; organizations can tailor it to fit their structure but is a good starting point to avoid missing the plot and rushing services into the model.

The picture shows how the architect is involved in both areas, the solution framework and the operations framework. This approach has worked quite well in many implementations here at Microsoft. If the architect only stays aware on the solution section it will miss the global view, how the services are performing and which ones are candidates for decommission or replacement. When a new service request arrives, the taxonomy of the model should help to identify which services are available; this is part of the analysis step. At this stage we can review the current entities, capabilities and activities and their functional domain. Is the request pushing for a completely new concept that the current services can not supply? This is the question to answer.

Once the service has been scoped and designed following the MSF guideline the building of the service is triggered as well as the testing and provisioning. I always like it to have a list with all my service listed, organized in a domain based ontology that gives me the full picture of what is going on. A graphical representation is always useful to visualize the services used by the different processes, I know that is hard to keep it up to date, but trust me, it really worth it.

Design: How good SOA can help you dealing with multi-cores

Salva Patuel — Mon, 09 Jul 2007 17:59:00 GMT

Unless you have been living under a rock for the last 5 years you should know about the multi-core architecture that the new processors bring to our world. Well, processors hardly can go any faster with the current technology therefore we need to start to have parallel thoughts...

Well, you are about to design a solution and you are facing the challenge “How I can take the most of the multi-core processor that my server has” Sometimes is not easy to take advantage of this extra horse due the lack of parallel design skills, I have seen many attempts to achieve this with more headaches than solutions.

After working on several projects where we were trying to improve the performance of certain components I came across multiple solutions but there is one tendency to solve this problem that comes within the SOA shadow. Thinking about services can help you to divide the pieces of functionality that can be parallelized; this will provide a natural processor optimization with the incorporation of different processes to get the maximum output from the multi-core environment.

I have seen many times a SOA model that includes a service multi layer derived from an ontology model, where the hierarchy drives to the conclusion that some services must be componentized within a single service to reduce complexity. The problem of this merge is that sometimes the developers fail to divide the components (adding dependencies) or they limit the multi threading capabilities of the hardware layer.

In the figure above we can see the service hierarchy that encapsulates service C1 and C2, when they are implemented in a single process the services needs to properly handle the threading model and the communication model, using memory synchronization patterns. This adds locking and latency problems that reduce the performance and scalability when the service is scaled in.

If we decide to divide our services in different process and use the common contract as communication layer we can solve the problem reducing complexity and isolating the threads. This helps you to reduce the component coupling and scales in better and cheaper. There is no need for synchronizating shared resources as the process isolation will dela with the individual heaps.

What is more, the model can have processor affinity to control the load on the hardware, this can became more common in a 4x4 architecture where 16 processors can give you not only the service isolation, also the hardware. As software architects need to deal with teams without the proper parallelism skills, this type of approach can help you reducing project risk and delivers a proper set of services to the business processes that allows you more flexibility if a new process needs the C1 service directly.