There are hundreds of SOA definitions can be found on the internet. Unfortunately, most of them try to equate SOA to some of the existing technologies such as Web Services. This is really a big misunderstanding without any doubt.
We should understand that SOA is everywhere just like Object Oriented Programming (OOP) paradigm. Let’s remember, how was the OOP born? We had tried to relate our real life problems to the computer world. In real life, our entire environment is full of objects and we interact with them. So we had decided to put objects to our programming languages and we adapted encapsulation, polymorphism and inheritance to our digital world. SOA is also adapted from real life with a similar fashion. To live, we provide and consume several different services. We search in which market we can buy the best food by lowest prize. We buy gasoline for our car from gas stations. We work and add value to our companies. Our companies sell products to its customers and so on. So just examine carefully your daily life. You can easily realize that services are everywhere in our life. Good services make our life better. Bad services make our life worse. So, our enterprise applications, infrastructures and systems need to be in the world of services too. They must provide some services. To supply those services they must search and consume some other services. This is the world we called SOA. OOP and SOA both map real world problems to our digital world. But unlike OOP paradigms, where the focus is on packaging data with operations, the central focus of SOA is the task or business function – getting something done.
Now let’s discuss about more technical details. Service Oriented Architecture, as you see from its name, it is an architectural concept. It is not a single technology. It is a way of developing the architecture of distributed software applications. You must develop your core business functions into independent services (loosely coupled). How can we say that an application is SOA compatible or not? Does it make sense? No, we cannot say something like that. It is a way of architecting your distributed enterprise application. However there are some simple rules you have to do for a well suited SOA. Here is the oldest SOA picture:
SOA encompasses service creation, interaction, presentation, and integration infrastructure capabilities to build software at a more abstract level based on reusable components. SOA, as a set of development patterns, focuses on service design, reuse, and accessibility to build highly flexible and agile software systems. SOA is an architectural approach that can be implemented in many different ways. Key elements in the SOA model are the service provider, service consumer and service registry as you see in the picture.
Service provider publishes its service description to the service registry and consumer seeks the service it needs. You can find several different SOA pictures. Some of them may have registry some of them may not have but they all must have providers and consumers. Your goal for SOA here is to pack your core business functionality as interoperable and independent services.
We cannot say an application is SOA compatible or not, but we can discuss the properties of the services. OASIS helps us here. They published a reference model for SOA. Let’s first read their SOA definition first:
“Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”
It is also stated in the reference model that SOA is not itself a solution to domain problems but rather an organizing and delivery paradigm that enables one to get more value from use both of capabilities which are locally “owned” and those under the control of others. SOA does not provide any domain elements of a solution that do not exist without SOA.
Here are the axioms for being a service within a SOA:
To build our enterprise applications there are some architectural, design and technological decisions we must agree on. Now we know what SOA is. So we have to decide which approaches our SOA will have? Process centric and Information centric are some of the choices. There is a great article comparing these approaches by Johan Den Haan here:
http://www.theenterprisearchitect.eu/archive/2010/01/13/the-process-centric-vs-information-centric-approach-to-soa
Here is a paragraph from his conclusion section:
“I think the information centric approach to SOA is unavoidable in the long term. It is needed to mirror the complexity of real life, to deliver the flexibility dynamic organizations need nowadays.”
I prefer to say “data centric” which seems more technical to me rather than “information centric” and i point pub/sub messaging style with "data centric". It is so much clear that loosely coupling can be best achieved by a data centric approach. I do not see a reason to discuss it at all. You can find several articles about data centric approaches. I suggest you to read articles about OMG’s Data Distribution Service (DDS) standard. Just note that in client/server technologies the level of coupling relies on “Who, Where, What, When” coupling. On the other hand in data-centric approach there exists only “What” coupling. It is because you only share the data, nothing else.
However there are several people who equate the SOA with the Web Services. If you do not have a service bus or a similar approach in your web service environment then your approach is not data centric. So you can see people complaining that data-centric approaches are not SOA (because they believe that Web Services = SOA). It is a big mistake. We have to remember that SOA is not a technology. And also you can have data centricity via web services too. What you need is a proper design pattern, that’s all.
There is a great article here about data centric approach which has a title of “Five Phases to Support the Data-Centric SOA”.
http://www.information-management.com/issues/2007_50/10001748-1.html?pg=1
There are also beliefs that Event-Driven Architecture (EDA) and SOA are different worlds. I believe this is a big mistake too. If you say “EDA vs. SOA” you miss your architectural goals. You should treat event handling as part of SOA.
Remember that SOA is an architecture that enables loosely coupled services. Now to exchange data between these services or to communicate with these services you need to decide your messaging middleware. Deciding your messaging middleware is tied to a messaging style. Keep in mind that the architecture is not tied to a specific technology. Applications that conform to SOA may be implemented using a wide range of standard messaging interfaces/protocols including JMS (Java messaging service), .Net Remoting, DDS (Data Distribution Service), CORBA (Common Object Request Broker Architecture), and Web Services (HTTP, WSDL, SOAP), just to name a few. The messaging styles can be request/response, fire and forget, events, publish/subscribe, and synchronous and asynchronous etc.
Data – centric approaches messaging style is usually preferred as publish/subscribe. If you have real time requirements (so much common for tactical military domain) a DDS implementation or CORBA may be the best fit. If you are not in a real time domain, Web Services is the most preferred technology.
DDS has a publish/subscribe messaging style while CORBA has a request/response messaging style. There are always attempts to make the technologies which have request/response messaging style (CORBA, Web Services etc.) more data centric by implementing some design patterns like supplier/consumer patterns. Service bus maybe an example of this too. However, attempting to have request/response messaging style in DDS implementations is completely meaningless. I do not know any example of it because it’s against the nature of the data centric approach.
Deciding the technologies, messaging middleware, messaging styles, set of design patterns is ok but still you do not have SOA. The real focus is the architecture of the services. You must have architectural diagrams describing your services and components. Just remember your architecture is the way for the SOA. Not the technologies you choose. Building web services never means that you have achieved SOA.
We should understand that SOA is everywhere just like Object Oriented Programming (OOP) paradigm. Let’s remember, how was the OOP born? We had tried to relate our real life problems to the computer world. In real life, our entire environment is full of objects and we interact with them. So we had decided to put objects to our programming languages and we adapted encapsulation, polymorphism and inheritance to our digital world. SOA is also adapted from real life with a similar fashion. To live, we provide and consume several different services. We search in which market we can buy the best food by lowest prize. We buy gasoline for our car from gas stations. We work and add value to our companies. Our companies sell products to its customers and so on. So just examine carefully your daily life. You can easily realize that services are everywhere in our life. Good services make our life better. Bad services make our life worse. So, our enterprise applications, infrastructures and systems need to be in the world of services too. They must provide some services. To supply those services they must search and consume some other services. This is the world we called SOA. OOP and SOA both map real world problems to our digital world. But unlike OOP paradigms, where the focus is on packaging data with operations, the central focus of SOA is the task or business function – getting something done.
Now let’s discuss about more technical details. Service Oriented Architecture, as you see from its name, it is an architectural concept. It is not a single technology. It is a way of developing the architecture of distributed software applications. You must develop your core business functions into independent services (loosely coupled). How can we say that an application is SOA compatible or not? Does it make sense? No, we cannot say something like that. It is a way of architecting your distributed enterprise application. However there are some simple rules you have to do for a well suited SOA. Here is the oldest SOA picture:
Service provider publishes its service description to the service registry and consumer seeks the service it needs. You can find several different SOA pictures. Some of them may have registry some of them may not have but they all must have providers and consumers. Your goal for SOA here is to pack your core business functionality as interoperable and independent services.
We cannot say an application is SOA compatible or not, but we can discuss the properties of the services. OASIS helps us here. They published a reference model for SOA. Let’s first read their SOA definition first:
“Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”
It is also stated in the reference model that SOA is not itself a solution to domain problems but rather an organizing and delivery paradigm that enables one to get more value from use both of capabilities which are locally “owned” and those under the control of others. SOA does not provide any domain elements of a solution that do not exist without SOA.
Here are the axioms for being a service within a SOA:
- A Service is a set of functionality provided by one entity for the use of others.
- Services are conceptually autonomous (self sufficient) and opaque (independent of underlying technology) in nature.
- There is no need to make architectural distinctions between services that are consumed as part of a process vs. ones that are not.
- There is not always a one to one correlation between “on the wire” requests to invoke a service and service responses being consumed.
- Each logical Service has exactly one canonical Service Description.
- A Service Description is comprised of three logical parts
- Data Model - The logical expression of a set of information items associated with the consumption of a service or services;
- Policy - Assertions and obligations that service consumers and/or providers must adhere to or provide; and
- Contract (and/or offer thereof) - the syntactic, semantic and logical constraints governing on the use of a service.
- A security policy is a specialized type of the Service Description policy noted above.
- Service Policy may mandate security requirements to be met, and if they are not, interaction (with the service) may be refused.
- A null security policy is still logically considered a policy.
- A Service Description is advertised to consumers on a fabric to make it discoverable.
- Discovery does not constitute authorization to execute against the service.
::Messaging Middleware and Messaging Styles::
http://www.theenterprisearchitect.eu/archive/2010/01/13/the-process-centric-vs-information-centric-approach-to-soa
Here is a paragraph from his conclusion section:
“I think the information centric approach to SOA is unavoidable in the long term. It is needed to mirror the complexity of real life, to deliver the flexibility dynamic organizations need nowadays.”
I prefer to say “data centric” which seems more technical to me rather than “information centric” and i point pub/sub messaging style with "data centric". It is so much clear that loosely coupling can be best achieved by a data centric approach. I do not see a reason to discuss it at all. You can find several articles about data centric approaches. I suggest you to read articles about OMG’s Data Distribution Service (DDS) standard. Just note that in client/server technologies the level of coupling relies on “Who, Where, What, When” coupling. On the other hand in data-centric approach there exists only “What” coupling. It is because you only share the data, nothing else.
However there are several people who equate the SOA with the Web Services. If you do not have a service bus or a similar approach in your web service environment then your approach is not data centric. So you can see people complaining that data-centric approaches are not SOA (because they believe that Web Services = SOA). It is a big mistake. We have to remember that SOA is not a technology. And also you can have data centricity via web services too. What you need is a proper design pattern, that’s all.
There is a great article here about data centric approach which has a title of “Five Phases to Support the Data-Centric SOA”.
http://www.information-management.com/issues/2007_50/10001748-1.html?pg=1
There are also beliefs that Event-Driven Architecture (EDA) and SOA are different worlds. I believe this is a big mistake too. If you say “EDA vs. SOA” you miss your architectural goals. You should treat event handling as part of SOA.
Remember that SOA is an architecture that enables loosely coupled services. Now to exchange data between these services or to communicate with these services you need to decide your messaging middleware. Deciding your messaging middleware is tied to a messaging style. Keep in mind that the architecture is not tied to a specific technology. Applications that conform to SOA may be implemented using a wide range of standard messaging interfaces/protocols including JMS (Java messaging service), .Net Remoting, DDS (Data Distribution Service), CORBA (Common Object Request Broker Architecture), and Web Services (HTTP, WSDL, SOAP), just to name a few. The messaging styles can be request/response, fire and forget, events, publish/subscribe, and synchronous and asynchronous etc.
Data – centric approaches messaging style is usually preferred as publish/subscribe. If you have real time requirements (so much common for tactical military domain) a DDS implementation or CORBA may be the best fit. If you are not in a real time domain, Web Services is the most preferred technology.
DDS has a publish/subscribe messaging style while CORBA has a request/response messaging style. There are always attempts to make the technologies which have request/response messaging style (CORBA, Web Services etc.) more data centric by implementing some design patterns like supplier/consumer patterns. Service bus maybe an example of this too. However, attempting to have request/response messaging style in DDS implementations is completely meaningless. I do not know any example of it because it’s against the nature of the data centric approach.
Deciding the technologies, messaging middleware, messaging styles, set of design patterns is ok but still you do not have SOA. The real focus is the architecture of the services. You must have architectural diagrams describing your services and components. Just remember your architecture is the way for the SOA. Not the technologies you choose. Building web services never means that you have achieved SOA.
::References::
http://blog.objectmentor.com/articles/2007/04/11/what-is-soa-reall
http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html
http://www.information-management.com/issues/2007_50/10001748-1.html
http://www.javadev.org/files/Enterprise%20Service%20Bus.pdf
http://www.theenterprisearchitect.eu/archive/2010/01/13/the-process-centric-vs-information-centric-approach-to-soa
Wang Y.H., Yang S.H., Grigg A., Johnson J. “A DDS Based Framework for Remote Integration over the Internet”, 7th Annual Conference on Systems Engineering Research. 2009.
NCOIC Net-Centric Services Framework Version 2.1 2009-10-01 Robert Palmqvist, Saab., Lars Schylberg, Saab., Allen Jones., Boeing., Jerry Sonnenberg, Harris
OASIS SOA Reference Model
No comments:
Post a Comment