Application Designing Stages using SOA : SOA in Short
In our recent project, we are following SOA principles. Everyone think of SOA based applications, but they would have their own means applied for it. In this post, I’m too trying to convey my meaning and how we found it is profitable for both, the client and the development teams.
Our SOA is spanned across 6 stages. Every stage has it’s own importance as well as documentation involved. Before we proceed further, we are not just working on the water fall model, but we also follow the Agile Methodologies. It really and clearly mentioned in every methodology that documentation is mandatory. But again, every methodology has it’s own recommendation towards documentation. Instead of talk / debate / write more about the Methodologies (vs) Documentation, let me go into the SOA Phases that worked for our current project.
Stage 1: Service Candidates
At this stage, we identify the business from very high level and understand the candidates that play vital role in serving the business as Services to the outside world. The purpose behind identifying these candidates is to isolate the different commonly usable / reusable services with (or) without authentication.
OUTPUT : The output from this stage includes the Service Candidate diagrams, typically some Visio diagrams. But in our case, we had identified the candidates and recorded them in an excel sheet. That is the wiki for us through out the project.
Stage 2: Service Composition
At this stage, we identified the high level service candidates and represented the in a graphical representation. This is typically some Visio diagram. At the end of this stage, we were in a position to understand the different layers of isolation as well as secure / non-secure zones. This document would also help us to identify the dependencies as well as the invoking process between the planned services
OUTPUT: Service Composition diagrams are the expected output from this stage. We have created Visio diagrams and got approvals from our business architects towards laying out our infrastructure as well as the business workflow.
Stage 3: Service Sequence
From the above composition, it is unfurled the dependency and the interaction between the services. By the time we come to this level, who ever involved in the journey of this project are almost in synch with the business. The team is now started thinking in the same lines of the business and converting the business into technology.
This is a sequence diagram. At this level, the team identifies the different layers that the service would be separated into application projects. The sequence diagram would give the full view of the Service contracts and their echo effect into the different layers in terms of programming logic (or) methods.
OUTPUT: Sequence Diagram
Stage 4: WSDL / Contracts
This stage is now span into 3 more phases. There is a need to write about them individually, so I’m going to write about that separately.
Stage 4.1 RR Schemas – Request / Response
The Request and Response contracts (or) Data contracts are defined in the begin. Which means that the input and output definitions are identified. When you work with Services, the only mechanism that the data can be exchanged is via XML. Thus, the XML data contracts are identified first. Secondly these XML data contracts are serialized into the respective technology. As it is evident that am working with Microsoft technologies, I prefer to develop these contracts as C# classes.
OUTPUT: XML Schemas & C# Classes for Input / Output from services
Stage 4.2 WSDL (or) Service Contracts
This document states all the Service contracts that are present in each service. The RR Schemas that are defined in the above stage is referenced here. Thus, the operations contracts evolved. These Operation Contracts play the vital role in understanding the nature of the service and the behavior. At this stage we also keep in mind that policies and and the access privileges details. The policies define the level of accessibility by the consuming application / the consumer. To cut short the long story, the following are identified and documented
- Data Contracts
- Operation Contracts
- Policy Rules / Access privileges for the consumer (or) consuming application
OUTPUT: Service Contract Definition document.
Reference : For more details about this phase, please read thru this article from MSDN library.
Stage 4.3 Service Specification Document
This is the document that finally talks about the entire definition of the service. Any consumer would always follow this guidelines and design their consuming application (or) program. This document gives very detailed information about the service level agreement provided by exposed service.
OUTPUT: Word document that explains in detail about all the operation contracts as well as the signature of data objects. These foot prints of the entities that were ghosts till this time would become reality for the management. These would also give the clear understanding of the exposed methods
Stage 5 Coding
Everyone love to do this first, instead of understanding the business. During the initial days, it would be meaningful if I recollect my fellow developer that helped me through out my application development, without which I should have not been at this position. Anyhow, keeping the feelings apart, coding is the real pulp of your service. And all the above documents (or) ideas should be implemented and converted to the coding at this stage
OUTPUT : Real coding
Stage 6 Service Registry
It is time now for pooling all the deployed services into one location and expose them to the world. As ours is a small investment and a small developer unit, we only ask our internal BizTalk UDDI to be installed and all the references of the exposed WebServices would be recorded here.
Hope that I’ve covered all the phases of the SOA Development. It is working for us, how about yours?
Comments