Architectural Specializations And Other Roles

Product Architect: The product architect is responsible for the delivery of a software product. He is responsible for the various releases of the product.

Domain Architect: Domain architect focuses on a particular domain e.g. business architecture, data architecture, network architecture.

Solution Architect: The solution architect specifically takes a broad, high-level view of the entire solution.

Enterprise Architect: The enterprise architect is responsible for the cross-system information systems architecture of the whole enterprise, including sales and marketing, client-facing systems, products and services, purchasing and accounts, the supply chain, human resources, etc.

Business Analysts: A business analyst is responsible for capturing and documenting detailed business requirements.

Project Managers: A project manager is responsible for ensuring delivery of the product or system and meeting deadlines.

Design Authorities: A design authority is responsible for the quality of the internal element designs for the system.

Technology Specialists: A technology specialist provides detailed expertise in one specific area. The technology specialist provides depth in the specific area.

Developers: They are responsible for the software code.

Orchestration And Choregraphy

Web services can be used for implementing business processes and collaborations within and across organizations.

Two languages for web service composition available are-
1. Business Process Execution Language (WS-BPEL)
2. Choreography Description Language (WS-CDL)

Orchestration refers to composing web services for business processes. It is used for defining composite services and internal processes. It describes the private process model i.e. describes a specific business process that a web service executes. The orchestration approach assumes a single, central point of control over the entire scope of process execution.

Choreography refers to composing web services for business collaborations. It is used for defining how multiple parties collaborate in peer-to-peer manner as part of some larger business transaction. It describes the public process model i.e. describes the interaction in terms of the public (visible) message exchanges that occur between the web services. The choreography approach assumes execution control is shared, potentially across multiple business process engines or various technologies.

There are two reasons for separating the public and private aspects of the business process.

1. The internal processes and data can be hidden from the clients invoking the web services.

2. The implementation details of the the internal process can be changed without affecting the public business protocol.

Synchronous And Asynchronous Services

A client's interaction with a web service can be synchronous or asynchronous.

Synchronous services - With synchronous services, clients invoke a request on a service and then suspend their processing while they wait for a response. e.g.


Synchronous services are best suited when applications require a more immediate response to a request. Web services that rely on synchronous communication are usually RPC-oriented.

Asynchronous services - With asynchronous services (also dubbed document-style web services), clients initiate a request to a service and then resume their processing without waiting for a response. The service handles the client request and returns a response at some later point, at which time the client retrieves the response and proceeds with its processing.

A document-oriented approach is used for asynchronous class of services. Services which process documents tend to use an asynchronous architecture. A document-oriented Web service receives a document as a service request. The document content determines the processing workflow for the Web service. There can be a number of processing steps required to fulfill the request.


There are two ways to obtain the response -

• The client that invoked the service periodically checks the status of the request using the ID that was provided at the time the request was submitted. (This is also known as polling.)

• Or, The web service can then respond, at some later time, by making a call back to the client with the response.Therefore, a client of a web service that contains a callback operation is special in that the client itself must provide an endpoint. We call this the callback endpoint and define an endpoint as a unique address identified by a URI to which SOAP request messages can be sent.

Web service callbacks refer to scenarios that involve the web service provider sending a SOAP message back to its clients. The Web Services Description Language (WSDL) specifications define such operations as being of the type “solicit/response.” Clients of web services that support callback operations must have a web service endpoint themselves, which the web service can use for sending callback requests at any point in time, or, in other words, asynchronously.
The first approach is non-intrusive and an independent polling module can be developed that is responsible for getting the results.

The second approach requires an implementation of event-listener.

Best practices suggest that you should support both polling and callbacks when implementing an asynchronous web service. Supporting both approaches will make your service accessible to the widest audience of clients.

10 principles of SOA

• Explicit Boundaries - Everything needed by the service to provide its functionality should be passed to it when it's invoked. All access to service should be via its publicly exposed interface. Service invocations should be modeled as stateless. A service invocation isn't a remote procedure call.

• Shared Contract and Schema, not Class - Data is exchanged as XML documents validatable against one or more schemas.
  

• Policy-driven - The provider's functionality, syntax, and semantics must fit the consumer's requirements. The technical capabilities and needs must match.
  

• Autonomous - It must be possible to change a service's runtime environment, without affecting its consumers. Services can be changed and deployed , versioned, and managed independently of each other. A service provider can't rely on the ability of its consumers to adapt to a new version of the service quickly; some of them might not be able, or willing , to adapt to a new version of the service interface all.
  

• Wire Formats, not Programming Language APIs - Services are exposed using a specific wire format that has to be supported. A service must be accessible from any platform that supports the exchange of messages adhering to the service interface as long as the interaction conforms to the policy defined for the service.
  

• Document-oriented - To interact with services, data is passed as documents. It should be self-descriptive. It should be explicitly modeled. e.g. a customer ID might be included along with the customer's address information (although the customer ID would be enough). This redundancy is explicitly accepted since it serves to isolate the service interface from the underlying data model of both service consumer and service provider. When a document-oriented pattern is applied, service invocations become meaningful exchanges of business messages instead of context-free RPC calls. When messages are sent in a Distributed Objects or RPC infrastructure, client and server can rely on a set of proxy classes (stubs and skeletons) generated from the interface description document.
  

• Loosely coupled - There are multiple dimensions in which a system can be loosely or tightly coupled. Dimensions include -
  

• Time - When participants are loosely coupled in time, they don't have to be up and running at the same time to communicate. This requires some way of buffering/queuing in between them. When one participant sends a message to the other one, it doesn't rely on an immediate answer to continue processing.
  

• Location - If participants query for the address of other participants they intend to communicate with, the location can change without having to reprogram, reconfigure, or even restart the communication partners. This implies some sort of lookup process using a directory or address that stores service endpoint addresses.

• Type - A participant can either rely on all or parts of a document structure to do its work.

• Version - Service providers should be implemented to accept as many different versions as possible, and thus be liberal in what they accept, while service consumers should do their best to conform to exact grammars and document types.
  

• Cardinality - There may be a 1:1 relationship between service consumers and service providers especially in cases where a request/response interaction takes place or an explicit message queue is used.

• Lookup - A participant that intends to invoke a service can either rely on a name of a service provider to communicate with, or it can do a lookup operation first using a description of a set of capabilities instead. This implies a registry and/or repository that can match the consumer's needs to a provider's capabilities.
  

• Standards-compliant - Standards exist for technical aspects such as data formats, metadata, transport, and transfer protocols, as well as for business-level artifacts such as document types. Reliance should be on standards instead of proprietary APIs.
  

• Vendor-independent - It's unavoidable to decide on specific products, both commercial and free/open source software. None of these decisions must have implications on an architectural level. A participant can be built using any technology that supports the appropriate standards and not be restricted by any vendor roadmap.

• Metadata-driven - All of the metadata artifacts in the overall SOA need to be stored in a way that enables them to be discovered, retrieved, and interpreted at both design time and runtime.
  

REST

REST is called Representational State Transfer. It is a software architecture style. The World Wide Web (www) is the best example of REST.

1. Interfaces are limited to HTTP (REST is as good as stateless HTTP).

- HTTP GET is used for obtaining a representation of a resource.

- HTTP DELETE is used for removing representations of a resource.

- HTTP POST is used for updating or creating the representations of a resource.

- HTTP PUT is used for creating representations of a resource.

2. REST is used to describe interfaces that transmits domain-specific data over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies.

3.a. A resource is any item of interest. e.g. user. Clients may access this resource with this url "http://example.com/users/{user}" (one for each user).

3.b. A representation of the resource is returned. e.g. 001.html. The representation places the client application in a state. The client traverses further and another resource is accessed. The new representation places the client application in yet another state. Thus the client application state is transfered with each resource representation. Therefore Representational State Transfer.

4. REST lays emphasis on the diversity of resources - what we call nouns. The resources could be potentially very large.

5. RPC lays emphasis on the diversity of protocols and specialized operations - what we call verbs.

6. An RPC client application must know about an object's identity and data type to locate it and communicate with it.

7. A REST application provides addresses for every useful data object and uses those objects as the targets of operations.

8. SOAP and XML-RPC are both designed to operate from a single URI with methods being invoked from within the request payload.

9. REST uses HTTP as it was designed, if you want to get some data you use a HTTP GET request, if you want to delete a record from a database you use a HTTP DELETE request, etc.

10. RPC says, "define some methods that do something" whereas REST says, "define some resources and they will have these methods".

Advantages of REST

• It uses well documented, well established, well used technology and methodology.
• It's already here today; in fact it's been here for the last 12 years!
• Resource centric rather than method centric.
• Given a URI anyone already knows how to access it.
• It's not another protocol on top of another protocol on top of another protocol on top of...
• The response payload can be of any format (some may call this a disadvantage, however the Web copes with it, it's just a case of defining the application grammar).
• Uses the inherent HTTP security model, certain methods to certain URIs can easily be restricted by firewall configuration, unlike other XML over HTTP messaging formats.
• REST makes sense, use what we already have; it is the next logical extension of the web.

Views of a system

4 + 1 views of a System

The 4 + 1 notation represents four distinct views of a system and one overview of how everything fits together.

The four views are:

Design view (Logical):
1. The design view captures the classes, interfaces, and patterns that describe the representation of the problem domain and how the software will be built to address it.

2. The design view uses class, object, composite structure, activity and sequence diagrams to convey the design of the system. The design view doesn't address how the system will be implemented or executed.

3. It addresses end users, developers and represents the functional requirements and maps them onto classes in a platform independent manner.

Deployment view (physical view):
1. The deployment view captures how a system is configured, installed and executed.

2. It consists of component, deployment and interaction diagrams. The deployment view captures the physical layout.

3. It addresses system engineers and non-functional requirements.

Implementation view (development view):
1. The implementation view focuses on the configuration management of a system; what components depend on what, what source files implement what classes, etc.

2. It consists of component, interaction, statechart, composite structure diagrams.

3. Layered pattern could be used to describe the implementation view.

Process view:
1. The process view of a system is intended to capture concurrency, performance and scalability information. It consists of activity, interaction diagrams.

2. It addresses the concerns of system integrators.

The four distinct views of a system are brought together with the final view:

Use case view (scenarios) -
1. The use case view captures the functionality required by the end users.

2. The use case view is often broken down into collaborations that link a use case with one or more of the four basic views.

3. The use case view includes use case diagrams and typically uses several interaction diagrams to show use case details.

What is loose coupling?

The loose coupling concept has multiple dimensions. For instance -

1. Integration between two applications may be loosely coupled in time using message-oriented middleware - meaning the availability of one system does not affect the other.
2. Integration may be loosely coupled in format using middleware to perform data transformation - meaning differences in data models do not prevent integration.
3. The service interface is independent of the implementation - meaning applications can be built by composing one or more services without knowing the services' underlying implementation.
   

What is a service?

Services are software chunks, or components, constructed so that they can easily linked with other software components. Services/software components carry out business processes.

• Services have well defined interfaces.
• Services are the interfaces to the business logic.
• A service is the endpoint of connection.
• Services are connected to each other with loosely coupled connections.
• Services are coarse grained, meaning the service can perform its logic and return the result in a single call.
• Services do not contain presentation logic, so they may be reused across diverse applications.

The important thing over here is technology should be expressed in chunks that business people can understand rather than as an application like ERP, CRM, etc. I will come back with more technical details regarding services later. I just need to elaborate more on loose coupling.

What is SOA?

I am not interested in abstract definitions. I prefer the details. Here I am going to give my collated understanding of various definitions that exist on the Internet and pointers for more information on this topic.

SOA is not the same as web services. SOA is a concept not bound to any specific technology.

SOA is an evolution of distributed computing based on the request/response design paradigm for synchronous and asynchronous applications.

SOA is essentially a collection of services. These services communicate with each other. So far okay - rest seems to be all jargon. However, lots of information available on what is a service.

Service Oriented Architecture

This blog has been created to capture my thoughts, knowledge regarding SOA. This is part of my professional work responsibilities and therefore this space and your comments are important to me.