Architecture, EAI, SOA & BPM

Relationship -1

noreply@blogger.com (tusjain) — Mon, 10 Nov 2008 14:26:00 +0000

In SOA ecosystem Security, Governance, Operations, Quality are closely related. Each face of SOA ecosystem affect other.

Remediation Framework

noreply@blogger.com (tusjain) — Mon, 10 Nov 2008 14:06:00 +0000

Remediation framework plays very important role in any SOA ecosystem. It can be though of extension of Error & Exception Management and Transaction Management frameworks. Remediation framework leverages Error & Exception Management Framework by utilizing logged error & exceptions. It also supplement Transaction Management Framework via helping to implement relaxed ACID where human intervention might be needed. Remediation framework also makes whole of SOA ecosystem robust via utilizing compensatory services.

Exception & Error Management

noreply@blogger.com (tusjain) — Tue, 04 Nov 2008 14:45:00 +0000

Exception & Error Management is consist of
Exception & Error Handling
Exception & Error Logging
Exception & Error Notification
In any enterprise under SOA ecosystem Exception & Error Management poses following challenges:

Exception & Error Handling

No predefined format for passing exception information among participating services
Webservices do not have capability of maintaining stack trace
Lack of common exception vocabulary across enterprise

Exception & Error Logging

Scattered logs across services/applications
Varying formats of logs across services/applications
Toggling logs at run time is service/application dependent

Exception & Error Notification

Every enterprise/LOB has its own unique notification requirement
Toggling Notification at run time is necessity
SLA and exceptions are coupled
To counter these challenges there must be a comprehensive Exception and Error Management framework which can manage at enterprise level and form the foundation for Remediation framework.

On the high level, Exception and Error Management framework’s architecture can be depicted as follows:

Transaction Management

noreply@blogger.com (tusjain) — Mon, 03 Nov 2008 16:35:00 +0000

Transaction Management is one of the most difficult aspects of any enterprise architecture due to varying level of understanding among stakeholders, various technological platforms involvement and spread of transactions – intra & inter enterprise.

In general any enterprise grade transaction framework follows ACID but due to presence of long running business processes and involvement of asynchronous communication traditional ACID becomes irrelevant. To accommodate long running business processes and asynchronous communication relaxed ACID is used which allows violation of ACID but with capability of correcting the violations in reasonable time period and with little business impact.

SOA capable enterprise grade Transaction Framework should have following features:

· Multi level undo/redo
· Coalescing of transactions
· Automatic aggregation of nested transactions
· Supports batching of transactions (Aggregation)
· Rollback of aggregated transactions for error recovery
· Listener support
· Synchronous and Asynchronous Transaction
· Compensatory Service
· Transaction Propagation

Event Management

noreply@blogger.com (tusjain) — Fri, 31 Oct 2008 01:11:00 +0000

To exploit SOA to its full extent event handling plays crucial role. In SOA environment Events can be classified into three categories

1. Generic Event
Event fired/raised in response of event or interaction with other service/s.

2. Time Based Event
Event fired/raised at particular moment of time to perform certain task

3. Heart Beat Event
Event fired/raised by services at regular interval to announce its existence and may be level of throughput it is working.

Generic Event Handling

These are events which fire/raise other events or results due to interaction of services in ecosystem.

1. Event Generator generates events with minimal data set.

2. These events should be formatted as per the event protocol defined in ecosystem, so that theses event are available to entire ecosystem for further processing.

Ø Event Pre-processing: Check that mandatory attributes are present in the incoming events
Ø Event Refinement: Introduce the other system-generated attributes like start time etc.
Ø Situation Refinement: Check the target status on which action would be performed
Ø Impact assessment: Required result assessment after that impact applies on the target

3. Event factory determine the specific type of action, which the given event have.

4. Event listener executes the specific action, which stated at the specific action code. There we have some general action apply to all type of system is present in generic action code and specific to specific action is present in the specific action listener

5. Event listener executes the action and calls the required system to complete it.

6. Some event, which completed their actions, and no further support needed from any other services are terminated

7. Some events which need further processing from some other services or may be generate other event in response of event is send back to the event engine

8. Event in response of event is again run as a new event and again it initiates its processing cycle in the event engine

Time Based Event Handling

Scheduled event delivered to a service at specific time in the future. Event deliveries can be deferred for short periods of time (such as seconds or minutes) or for long stretches of time (for example, hours later for batch processing). Until that delivery time, the Event is essentially invisible until it is delivered, allowing you to schedule work at a particular time in the future.

Heart Beat Event Handling

Heartbeats, a common software construct, verify the continual operation of a specific service. With heartbeats, a targeted service continually broadcasts a signal across its environment. System works normally when client services can detect a targeted service's heartbeat signals

There is number of interdependent services in SOA ecosystem such that, if one failed, others will also fail.

Heartbeat generally propagated across SOA ecosystem using publish/subscribe paradigm.

Service Life Cycle Management

noreply@blogger.com (tusjain) — Fri, 31 Oct 2008 01:10:00 +0000

Service Life Cycle Management essentially help in managing service life cycle from its conception to decommission. This is one of the vital component which determine the success of SOA initiative in any enterprise and also its long term viability.

Rule/Policy Repository & Engine

noreply@blogger.com (tusjain) — Fri, 31 Oct 2008 01:09:00 +0000

Rule/Policy Repository contain various Business Rules and Governance & Security Policies. The engine part of the same will help in execution of Rules ans Policies as and when demanded.

Service Directory

noreply@blogger.com (tusjain) — Fri, 31 Oct 2008 01:08:00 +0000

Service directory essentially consists of UDDI which facilitates consolidated listing of services.

Governance

noreply@blogger.com (tusjain) — Tue, 28 Oct 2008 00:29:00 +0000

Governance is one of the burning issue in SOA environment. To discuss SOA Governance's Technical architecture, it is necessary to understand SOA Governance model.

Following figure depicts the SOA Governance Model.

The picture below intend to depict SOA Governance Technical Architecture.

Security

noreply@blogger.com (tusjain) — Sun, 28 Sep 2008 15:17:00 +0000

Security in SOA is one of the biggest concern due to distributed & heterogeneous systems interacting with each other. The security related aspects should be handled at each level of enterprise. In the proposed model security is considered from physical and virtual perspective. It also take into account security from network and application view.

At monitoring front it take care of Technical - For support staff, Process & Managerial - For business process owners & managers and Executive - for top rung of business leadership requirements.

SOA Reference Architecture - v 2

noreply@blogger.com (tusjain) — Tue, 23 Sep 2008 02:57:00 +0000

Integration with Outer World

noreply@blogger.com (tusjain) — Tue, 23 Sep 2008 02:54:00 +0000

Most of the large enterprises also get integrated with external world. This integration is both way - information flow is in both direction. To further complicate the scenario, enterprises increasingly using SAAS. This situation requires special attention and tools. In case of integration with business partners B2B Engine plays major role in conjunction with Partner services. SAAS services may be consumed directly or via B2B engine. In case of Human interaction (CRM - Salesforce.com) B2B Engine should be bypassed but for m/c interaction or substantial data transfer ( Document management for insurance companies) B2B engine should be engaged.

Presentation Services

noreply@blogger.com (tusjain) — Wed, 10 Sep 2008 01:05:00 +0000

These services support various user interfaces ( human or machine centric) and let outer world (intra & inter enterprise) interact with enterprises IT assets. The consumers of presentation services are

Human
      Thin Client

          Browser clients: May be based on traditional HTML based or AJAX based

          Portable devices: May be based on open standards (WAP) or propitiatory ( device or carrier specific)

      Thick Client

          Alway Connected: These clients connect to service providers and consume the services in real time. Traditional think client falls in this category

          Offline Clients: These clients does not connect to service providers in Always On fashion but an actor can work in offline mode and when ever connectivity available, services consumed. Java WebStart and Adobe AIR are two most widely used technologies in this field.

      Voice Based Client
Voice based clients are gaining popularly to reduce load on contact center. To facilitate this type of user interface, IVR plays great role.

Machine
This type of interfaces are not very obvious but very prevent at enterprise level. Application level interaction ( Software to software) and interaction with various devices like RFID tags, Bar code readers, etc ( Hardware to Software or vice versa) are part of this type of interfaces.

Enterprise Service Bus

noreply@blogger.com (tusjain) — Fri, 05 Sep 2008 01:07:00 +0000

ESB provides four functionalities:

Orchestration
Routing
Mediation
Enrichment

Some ESBs may provide one more functionality - Choreography. This functionality is associated with BPM systems and currently none of Commercially available ESB provide the same.

Enrichment may be of two types: Data Transformation and Channel Transformation. Most of the analysts keep Data Transformation & Channel Transformation separate functionality.

Services Layer Contd....

noreply@blogger.com (tusjain) — Fri, 20 Jun 2008 19:52:00 +0000

1. Connectivity services primarily cater to accessing system level functionalities, any adapter & connector services and partner (B2B) integration services.

2. Data services comprises of services which caters to Business, Technical and Meta data related services.

3. Business Activity Services consist of Atomic business/functionalities and any custom business logic developed by combing one or more Data & Connectivity services.

4. Business Process Services primarily consist of Process integration, Machine and Human centric services. These services primarily comprise of Business Activity services.

Services Layer

noreply@blogger.com (tusjain) — Mon, 09 Jun 2008 15:10:00 +0000

This layer is consists of multiple sub layers which encapsulate different class of services. It encompasses Connectivity Services, Data Services, Business Activity Services and Business Process Services. Each layer in turn consists of other sub-types of services.

This layer exposes different aspects of business - functional and infrastructural aspects. Connectivity and Data services are consist of Infrastructural services while Business Activity and Process services exposes functional Services.

These services though in layers but still breach layered architecture to expose these services independent of layers and for better performance. These services can also be exposed to multiple ESBs if situation warrants.

Service Providers

noreply@blogger.com (tusjain) — Mon, 26 May 2008 00:27:00 +0000

This Layer consists of different business applications. These applications may be packaged (e.g. SAP, Reteck, etc) or may be custom developed in various technologies (e.g. Java, .Net, etc). Again application in this layer may be service enabled or legacy once, which do not expose their functionalities as service.

At this layer EAI exist. Some may argue that SOA is one form of integration then how EAI can exist at this layer. I will discuss this argument in one of my future posting but not now.

Data Persistent Layer

noreply@blogger.com (tusjain) — Tue, 20 May 2008 16:11:00 +0000

Data Persistent Layer is primarily consists of Enterprise Data - Master, Transaction and Meta. It may also include Datamart and Data driven reporting infrastructure.

In most of the large enterprises Data Persistent Layer consists of relational (RDBMS), hierarchical (LDAP, IMS), unstructured ( Emails, chat sessions, file systems, etc) and any other type. This variation in data characteristics warrant unique data handling and treatment technologies.

SOA Reference Architecture

noreply@blogger.com (tusjain) — Mon, 19 May 2008 16:52:00 +0000

SOA Reference Architecture

noreply@blogger.com (tusjain) — Fri, 16 May 2008 01:49:00 +0000

Here I propose SOA Enterprise Reference Architecture. I will discuss the details of this reference architecture in detail with my subsequent posts.

Reference Architecture is independent of platforms offered by various vendors. It is also possible that none of the vendors in market provide complete solution to realize this reference architecture.

eGovernment SOA

noreply@blogger.com (tusjain) — Wed, 14 May 2008 04:08:00 +0000

Definition:

Service can be defined as system or organization that provides stakeholders with some thing that they need/ask for or and consequence of execution of it.

Stakeholders involved may be people, organizations or systems.

Stakeholders:

Client

Citizen
Business
Public Administration Organization

Service Organization

Service Provider
Evidence Verifier
Evidence Provider

i. Primary

ii. Auxiliary

Consequence (Auxiliary Outputs) Receiver
Primary Output Receiver

Service Broker

Service Repository
Interoperability Agent

Service Interaction:

The Client contacts a Service Provider (Public Administration Organization) and asks for a service that requires for its execution input from organizations located in national/states/municipalities across India. The Service Provider, after gathering from these countries all evidences needed for Service execution, executes the Service based on predefined Rules and provides Client with an output (Primary Output) and all organizations with the consequences (Auxiliary Outputs) of the Service.

Preconditions:

A client identifies service organization and ensures that potential service exists. Client provides minimum set of evidences (primary inputs) needed for initiating the service identification. Client may also supply Auxiliary inputs ( in form of evidences and references to evidences) as required by service contract.

Post conditions:

Client receives the Output (primary output) of service execution and participatory organizations receive consequences (Auxiliary Outputs).

Interaction Model:

Description:

Participating Roles

Client

Primary Output Receiver

Service Provider

Broker (Service Repository, Interoperability Agent)

Evidence Provider

Evidence Verifier

Consequence Receiver

Description of Steps

Step 1. A client requests for service. He/she supplies some evidences and some references to evidences. Evidence supplied by client may be categorized as:

1. Evidence required for identification purpose

2. Evidences needed to fetch more evidences from evidence providers

3. Evidences needed to execute service

Less evidences supplied by client to Service Provider, transparent is the service. Of course number and type of evidences required are service specific.

Step 2. Service provider supplies the evidences/credentials of client Broker that in turn passes the same to Evidence Verifier. Evidence Verifier verifies credentials of Client and accordingly supplies the results to Service provider via Broker. Now Client has an Identity.

Step 3. Service Provider looks up for more evidences on the based of identity established for client and references provided by client with the help of Evidence Providers via Broker.

Step 4. Evidences collected from Client, Evidence Suppliers are passed to Evidence Verifiers via Broker.

Step 5. On positive out come of Evidence Verifiers, Service is executed. The outcomes of service are passed to Primary and Auxiliary Output Receivers.

Class Model:

The interaction model can be depicted in class model in two parts

1. The Operational (Transactional) Part

2. The Knowledge (Planning) Part

Service Versioning

noreply@blogger.com (tusjain) — Mon, 12 May 2008 15:57:00 +0000

Versioning assumes simultaneous existence of multiple (different) implementation of an artifact (code, document, etc). In the case of SOA, service versioning equates to coexistence of multiple versions of the same service, which allows each consumer to use the version that it is designed and tested for.

Multiple coexisting versions of the same service in the system allows for the independent life cycles of services and their consumers and minimizes the overall impact of the introduction of changes.

The basic idea of service versioning is fairly simple and straightforward, but its implementation requires definition of the following:

1. Units of versioning

2. Version Definition

3. Version Deployment/Access Approaches

Units of Versioning: Assuming WebService is implementation technology, Service as whole is versioned or individual methods in a service. Both approaches have their own drawbacks and benefits. The first approach is consistent with current Object Oriented and Component Based development paradigm but poses challenges when the service contain various methods and various users while change affects only few methods. The second approach has following advantages:

It allows for immutable services. The service can provide additional methods (versions of methods), some of which can be deprecated over time, but the service itself, its name and classification, seldom changes. This scheme resembles versioning approaches in popular programming languages, such as Java or C#, where methods on classes are added and deprecated quite often while existing classes that are widely used rarely change.

It minimizes the impact of the service changes to consumers. Only consumers using a particular method are affected by a change, instead of all service consumers.

It minimizes the overall amount of deployed code. Only methods with a new version get redeployed in the process of introduction of the new version. The code implementing methods that have not changed remains unchanged.

The disadvantages are:

It calls for deploying each method independently with its own endpoint address (es). (Although such a deployment approach is not mainstream today, it has some advantages, such as providing different service-level agreements (SLA) for different methods within the same service.)

It requires a different, slightly more complex, service invocation-addressing schema. Instead of specifying a service that it needs to invoke, the service consumer, in this case, needs to explicitly specify the service, the operation, and the version of the operation that it requires.

Version Definition: The major components of a service are interface and message. All changes in interface and message definitions does not constitute a newer version, only those result in changes in consumer are marked as candidate for new version.

Service-Interface Changes: The service's method signature (interface) in case of semantic messaging is:

           serviceMethod(XML in, XML out)

Due to very definition of interface, it never changes, so no question of version. If each method is deployed and addressed individually, so new methods introduced will not impact existing consumers. If a method is deprecated, some sort of warning can be incorporated in returned message. In case of elimination, major impact in consumer and may require revamp of consumer.

Service-Message Changes: Message change will be covered by XML schema versioning technique. The changes in XML schema can categorized under three categories:

Revisions: It represents schema changes, which have no semantic meaning e.g. comments, formatting, white spaces, etc. So, no versioning effect.

In addition of this, initial incremental development of schema before publishing can be considered as revision.

             Minor Changes: It represents backward compatible changes. e.g.

a.      Changing optionality of a local element or element reference      from required to optional

b.      Adding a global element or type

c.       Adding optional elements to the existing type

d.      Changing type of a global or local element to the new type, derived from the original by adding/restricting optional elements.

Major Changes: It represents non-backward-compatible changes to the document schema. e.g.

a.    Changing the type of a local or global element to the new type,  derived from the original by adding/restricting optional elements

b.    Changing the optionality of a local element or element reference from   optional to required

c.     Adding or removing an enumeration value

d.    Removing or renaming a global type or element.

Only major change in XML schema will constitute the versioning in service.

Implementation Changes: In Utopian world change in implementation of service will not constitute version but we are not. In reality, adherence to the interface does not constitute replace-ability of implementations. Replace-ability is not defined by interface alone, but instead by the contract—which includes interface, pre- and post-conditions, Quality of Service and certain SLAs—on which the service consumer relies. e.g.

a. New service implementation supports exactly the same interface (functionality), but changes timing (SLA). If a service consumer is invoking this service (method) synchronously, such change can significantly impact service consumer execution. As a result, service versioning might be required. (Interestingly enough, even redeployment of existing service, with changes to its implementation, can lead to the same results).

b. New service implementation supports the same interface, but changes incoming parameters validations (preconditions). In this case, some requests that had been processed successfully will now be rejected, requiring introduction of a new service.

c. New service implementation introduces a new security implementation (precondition), which often is not reflected in service interface, but done through the configuration settings. In this case, existing consumers will require sending security credentials; implementation change and creation of the new version is required.

3. Version Deployment/Access Approaches: There are two approaches for deploying versions of a service.

a. Covenant or Version Parameter: "if-then-else" like agreement where a single endpoint address for all versions of service (methods) but based on context based routing, incoming request is routed to appropriate version depending upon message embedded version information. This approach simplifies the addressing challenge but packaging multiple versions of same service in same packet is a challenge in itself. This approach is further abstracted using Mediator pattern where an external mediator will rout the incoming message as per embedded version information in message. The version details can be embedded either in namespace or as parameter in message.

Namespace example (Followed by Amazon):

Pros: Takes advantage of XML namespaces, works well with backwards incompatible schema changes.

Cons: Doesn't take advantage of XML schema extensibility.

Old Version

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >

  < soap:Body>

    <  xmlns="urn:company:service:v1" > 3.333333 < /Price >

  < /soap:Body >

< /soap:Envelope >

New Version

< soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >

  < soap:Body >

    < Price xmlns="urn:company:service:v2" > 3.33 < /Price >

  < /soap:Body >

< /soap:Envelope >

Parameter example (in Header) --> Followed by eBay:

Pros: Uses XML schema extensibility.

Cons: Does not work well with incompatabile schema changes, doesn't take advantage of XML namespaces, requires users to pass the parameter in ever request.

< soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >

   < soap:Header >

    < Version xmlns="urn:company:service" > 340 < /Version >

  < /soap:Header >

  < soap:Body >

    ....

  < /soap:Body >

< /soap:Envelope >

Parameter example (in Body):

< soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >

  < soap:Body >

    < SomeRequest xmlns="urn:company:service" >

      < Version > 340 < /Version >

      ....

    < /SomeRequest >

  < /soap:Body >

< /soap:Envelope >

a. Multiple End-point addresses: Every version is deployed separately and exposed to potential customer at different URI and port. This approach assumes that consumers will resolve the address of provider with help of some registry service (UDDI). This approach completely separate each version from each other and provide better scalability but requires complex addressing paradigm, and creates n number of services.

Example:

http://example.com/service/v1

http://example.com/service/v2

Services following this pattern: JIRA

Pros: Uses XML schema extensibility.

Cons: Requires users to update their invocation url each you update versions, Does not work well with incompatible schema changes, doesn't take advantage of XML namespaces.

As services get versioned, so the underlying infrastructure. It constitutes:

Ø Transport changes — e.g., switching transport from HTTP to HTTPS

Ø Message encoding changes — e.g., upgrading proprietary enveloping with SOAP.

Ø Changes in addressing schema— e.g., introduction of the WS-Addressing for reply-address specification

It is desirable to maintain backward compatibility but it might be technically not feasible or expensive. Facade pattern is one of the possible solutions.

Version Identification Strategies

Defining a schema is as good as defining a language for a special purpose. Version identification is done with a dot (.) separating major and minor versions ( major.minor). Traditionally major version refer to "incompatible" change while minor refers to "compatible" change. This is idealistic approach, in real life you will find several examples which are not in sync with this approach.

There are numerous variety of version identification strategy but following are few of the popular one.

A. All components in new namespace(s) for each version : version 1.0 consists of name space "a" and version 1.1 is of "b".

B. All new components in new namespace(s) for each compatible version : version 1.0 consists of namespaces "a " & "b"; version 1.1 consists of namespaces "a", "b" & "c"; version 2.0 consists of "d" & "e".

C. All new components in existing or new namespace(s) for each compatible version : version 1.0 consists of namespace(s) "a"; version 1.1 consists of namespaces "a"; version 2.0 and 2.1 consists of namespace "b".

D. All new components in existing or new namespaces(s) for each version and a version identifier : version 1.0 consists of namespace "a" and version attribute "x"; version 1.1 consists of namespace "b" and version attribute "y".

While deciding version strategy pay attention to:

Supporting compatible evolution;
Namespaces for identifying compatible components. Changing namespace names is typically is very invasive change;
Tool limitation;
Future direction.

Support for versioning in XML Schema

The simplest way of denoting versions in XML Schema is usage of an (optional) attribute at the xs:schema element - version. The content model permits Dewey notation of major.minor version numbers.

Since XML parsers are not required to validate instances using version, it is possible to implement custom representation of version, enabling the parser to include it in the validation process. This technique typically requires introduction of a versioning attribute as a fixed, required value for identifying a specific schema version. However, this approach for schema versioning is not very practical. There are several disadvantages:

An XML instance will be unable to use multiple versions of a schema representation because versioning occurs at the schema's root.

XML schema validation tools are not required to validate instances using the version attribute; the attribute is provided purely for documentation purposes and is not enforceable by XML parsers.

Because XML parsers are not required to validate using the version attribute, additional custom processing (over and above parsing and validation) is required to ensure that the expected schema version(s) are being referenced by the instance.

Marshaling/unmarshaling of XML document is very rarely done using direct manipulation of the DOM tree. The prevalent approach to marshaling is generation of the classes, supporting "automatic" marshaling, using tools like WSDL2Java, Castor, EMF, SDO, XSD, XSDObjectGenerator, and so on. In this case, classes are generated in the packages in Java or namespaces in C#, based on the schema namespaces, not the schema version.

Another option for denoting schema version is usage of XML Namespaces. In this approach, a new XML Namespace is used for all major version releases. This approach is well aligned with generation of marshaling/unmarshaling code by allowing generating code in different packages (namespaces), thus enabling a single service consumer to work with several major releases of schema simultaneously.

Yet another option is to keep XML Namespace values constant and add a special element for grouping custom extensions. This approach wraps extensions to the underlying vocabulary within a special extension element. Several industry-standard schemas favor this technique. For example, the Open Application Group's Business Object Documents (OAG BODs) include a element defining custom information that may not be part of the base vocabulary. This approach maximizes the extensibility of the schema constructs (schemas can be both forward- and backward-compatible) without introduction of new namespaces. There are two disadvantages to this approach:

It introduces significantly higher levels of complexity into the schema.

It does not allow implementation of multiple extensions across different portions of the XML instance, because all extensions must be grouped within the extension "wrapper."

The most scalable approach to versioning of schemas is as follows:

Componentization of the overall schema in logical partitions using multiple namespaces, thus containing changes.

Defining a new namespace (reflecting the major version information) for every major version of each schema.

Denoting every minor version as a schema version in a major version namespace. Because minor versions are backward compatible, generated marshaling/unmarshaling code also will be backward compatible.

Advantages of SOA

noreply@blogger.com (tusjain) — Fri, 09 May 2008 04:15:00 +0000

There are only two advantages of SOA:

1. Re usability
2. Agility
2.1 Business
2.2 Technical

All other advantages can be derived from these two.

When to say no to SOA

noreply@blogger.com (tusjain) — Fri, 09 May 2008 04:12:00 +0000

Every is shouting for SOA. But there must be some scenarios when not to use SOA. I have listed few:

1. In Homogeneous IT environment
2. When real time performance is critical
3. When Business and IT environment is static
4. When tight coupling is advantageous not a con.
5. When huge amount of data transfer is happening.
6. When data sharing is in batch mode.

Service Contract

noreply@blogger.com (tusjain) — Thu, 08 May 2008 00:47:00 +0000

Service contract is a contract, which must be understood by calling service and service repository, so appropriate decisions can be made at their end. But what should be the content of such contract?

1. Functional Requirements

   1.1. Service Operations

   1.2. Infrastructure

   1.3. URI & Port

2. Non Functional Requirements

   2.1. Security

   2.2. Quality of Service (QoS)

        2.2.1. Reliability

        2.2.2. Availability

        2.2.3. Synchronicity - Synchronous/Asynchronous

   2.3. Transactions

   2.4. Business Rule

   2.5. Semantics

   2.6. Context

   2.7. Metering

   2.8. Protocol (TCP, UDP, HTTP/HTTPS, SMTP, SOAP, RMI, IIOP, etc)