While developing an organization’s service model, an architect must define the top level business functions first. Once the business functions are defined, they are further sectioned into services that represent the processes and activities needed to manage the assets of an organization in their various states.
One example is the separation of the business function “Manage Orders” into services such as “Create Order”, “Fulfill Order”, “Ship Order”, “Invoice Order” and “Cancel/Update Order.”
Defining Service description/specification
In order to define the service description or specification. It should consists of:
- A plain and detailed narrative definition supported by a low-level process model. It must be clearly narrated with the information about the service that facilitates service mediation and consistency checking of an enterprise architecture.
- A set of performance indicators that address measures and performance parameters, such as availability (when should members of the organization be able to perform the functions), duration (how long should it take to perform the function), rate (how often will the function be performed over a period of time), etc.
- A link to the organization’s information model showing what information the service owns (creates, reads, updates, and deletes) and which information it references that is owned by other services.
State of Services
Services can be stateless and stateful. Stateless services can be services like data aggregation services. Stateful services are used for executing business logic.
The Service Architecture should be design keeping in mind the below building blocks:
- Service Contract
- Message Processing Logic (mostly used in web-service related architectures)
- Service Component (core service logic)
Service Component Architecture (SCA)
To Understand why SCA? It is first important to know what SCA? Service Component Architecture (SCA) is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture (SOA). SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.
SCA is based on the idea that business function is provided as a series of services, which are assembled together to create solutions that serve a particular business need. These composite applications can contain both new services created specifically for the application and also business function from existing systems and applications, reused as part of the composition. SCA provides a model both for the composition of services and for the creation of service components, including the reuse of existing application function within SCA compositions.
Workflow? Workflow is fundamentally about the organization of work. It is a set of activities that coordinate people and / or software. Communicating this organization to humans and automated processes is the value-add that workflow provides to our solutions. Workflow may consist of other workflows (each of which may consist of aggregated services). The workflow model encourages reuse and agility, leading to more flexible business processes.
While Designing Workflow Architect may use two mode either a Textual or Graphical, it is also known as PDL (Process Definition Language) it is very simple language similar to structure language like English. Workflow can basically be defined by three parameters
- Input description: the information, material and energy required to complete the step
- transformation rules, algorithms, which may be carried out by associated human roles or machines, or a combination
- Output description: the information, material and energy produced by the step and provided as input to downstream steps.
Workflow Lifecycle: An individual business process may have a life cycle ranging from minutes to days (or even months), depending upon its complexity and the duration of the various constituent activities. Such systems may be implemented in A variety of ways, use a wide variety of IT and communications infrastructure and operate in an environment Ranging from small local workgroup to inter-enterprise.
Workflow Reference Model
Building the Messaging Architecture
It is foremost important that the design of Messaging Architecture is such that the messaging framework must be capable of supporting the publish-and-subscribe MEP (Message Exchange Pattern) and associated complex event processing and tracking. One of the problems with the distributed systems built today is that they are fragile. As one part of the system slows down, the effect tends to ripple out and cripple the entire system. One of the primary design goals of ESB should be to eliminate that, the guideline should be available to developers to write code that is robust in production environments. That robustness prevents data loss under failure conditions.
To make effective use of ESB, it is important to understand the distributed systems architecture. If you are designing your system according to the principles as per the pattern it will make your life a lot easier.
The communications pattern that enables robustness is one-way messaging, also known as “fire and forget”. Since the amount of time it can take to communicate with another machine across the network is both unknown and unbounded, communications are based on a store-and-forward model.
Message Exchange Pattern
- Datagram with sessions
- Request-response with sessions
- Duplex with sessions
Messaging pattern is important part of the ESB in the SOA architecture, an enterprise service bus (ESB) being a model used for designing and implementing communication between mutually interacting software applications in a service-oriented architecture (SOA). How the Message?
- How the Monitoring and control routing of message can be exchange between services
- How to resolve contention between communicating service components
- How to control deployment and versioning of services
- How to Marshal use of redundant services
- How to cater for commodity services like event handling, data transformation and mapping, message and event queuing and sequencing, security or exception handling and protocol conversion
- How to enforce proper quality of communication service
The three basic message exchange patterns mostly followed are datagram, request-response, and duplex.