Principles of SOA

There is a common set of principles most associated with service orientation.

As a result of research the author performed for SOA Systems (during which service orientation, as a design paradigm, was studied within the context of all major vendor platforms and existing frameworks and blueprints) this set of common service-orientation principles has been identified and defined. 

Below are brief descriptions of each. 

Services are autonomous — The logic governed by a service resides within an explicit boundary. The service has control within this boundary, and is not dependent on other services for it to execute its governance. 

Services share a formal contract — In order for services to interact, they need not share anything but a collection of published metadata that describes each service and defines the terms of information exchange. 

Services are loosely coupled — Dependencies between the underlying logic of a service and its consumers are limited to conformance of the service contract. 

Services abstract underlying logic — Underlying logic, beyond what is expressed in the service contract metadata, is invisible to the outside world. 

Services are composable — Services may compose others, allowing logic to be represented at different levels of granularity. This promotes reusability and the creation of service abstraction layers. 

Services are reusable — Regardless of whether immediate reuse opportunities exist, services are designed to support potential reuse. 

Services are stateless — Services should be designed to maximize statelessness even if that means deferring state management elsewhere. 

Services are discoverable — Services should allow their descriptions to be discovered and understood by humans and service requestors that may be able to make use of their logic. 

Of these eight, autonomy, loose coupling, abstraction, and the need for a formal contract can be considered the core principles that form the baseline foundation for SOA, directly supporting the realization of others (as well as each other).

What is SOA - Service Oriented Architecture ?

"Separation of concerns" is an established software engineering theory based on the notion that it is beneficial to break down a large problem into a series of individual concerns. 

This allows the logic required to solve the problem to be decomposed into a collection of smaller, related pieces. Each piece of logic addresses a specific concern.

This theory has been implemented in different ways with different development platforms. Object-oriented programming and component-based programming approaches, for example, achieve a separation of concerns through the use of objects, classes, and components. 

Service orientation can be viewed as a distinct manner in which to realize a separation of concerns. The principles of service orientation provide a means of supporting this theory while achieving a foundation paradigm upon which many contemporary SOA characteristics can be built.

Difference between SOAP over HTTP and SOAP over JMS?

Reason for choosing JMS in most cases is reliability. But there are other things that come in mind whether to choose JMS or HTTP.

Reasons to go with HTTP:
  • Firewall friendly (web services exposed over internet)
  • Supported on all platforms (easiest connectivity in b2b scenario)
  • Clients can be simple and lightweight
Reasons to go with JMS:
  • Assured delivery and/or only once delivery
  • Asynchronous support
  • Publish/subscribe
  • Queuing if better for achieving larger scalability and reliability
  • Better handles temporary high load
  • Large volume of messages (EDA)
  • Better support in middleware software
  • Transaction boundary
In SOA architecture best practice is to use JMS internally (for clients/providers that can easily connect to ESB) and HTTP for connecting to outside partners (over internet).

Using SOAP over JMS gives  some advantages compared to HTTP, 

specially related to reliability as you may use the persistence and acknowledgment features built in the standard. 

The same applies if you need to establish asynchronous communication or need to use the load balancing features provided by JMS servers.

We can achieve this using http but the implementation would be much more complicated.

If we do SOAP over JMS, in fact we can do load balancing..  where as with SOAP over HTTP requires additional hardware like IP Sprayers.

BW Engine Properties of Deployed Projects

We can set the custom properties (BW engine Properties) in deployed projects by fallowing steps.

Step1: Go to the location  "C:\tibco\bw\5.6\lib\com\tibco\deployment".

Step2: Open the file "bwengine.xml".

Step3: We can add new property as per the template mentioned in this file or can set to new values in this file.

Step4: After changing the bwengine.xml file , save EAR file in TIBCO Designer and re-load them into any deployment configurations created in TIBCO Administrator.

Step5: These properties will be displayed in Advanced tab of the deployment configuration in TIBCO Administrator.

  © Blogger templates The Professional Template by Ourblogtemplates.com 2008

Back to TOP