As i know SOA(Service Oriented Architecture) is based on collections of discrete software modules, known as services. These services can exchange information with any other service within the reach of the network without human interaction.
SOA uses SOAP or REST protocol to transfer XML or JSON document between various services.
But i'm confused with ROA(Resource Oriented Architecture) and about what is the difference between the two architectures.
Any help will be appreciated, rectify me if i'm wrong.
As the terms imply a Service Oriented Architecture is oriented at services, and a Resource Oriented Architecture is oriented at resources. In general differences between two things A and B are often best explained by defining the essence of A and B. So it comes down to the question, what is a 'service', and what is a 'resource'?
I'll leave that mostly to the reader, as most developers probably have an idea of what either is. Although it's actually not that easy, as one thing could be seen both as a service, and as a resource (similar to the classic Wave-Particle duality of light in physics). For instance, Flickr is a service that provides you with photo's, but can also be seen as a resource for photos. But basically a resource is more static data (like a photo) and a service is more processing (e.g. delivering a photo, or resizing a photo so they can show a thumbnail of one).
I understand the difference best by looking at the way an application implement its 'functionality':
An application built with a Service Oriented Architecture is more a 'Facade', e.g. it combines or composes its outgoing functionality based on functionality that is in the services it uses 'behind the screens' (possibly over the network). E.g. its core processing consists of calling external services, supplying them with parameters, and combining the results with possibly some extra processing or algorithms for the user.
An application built with a Resource Oriented Architecture does more of its processing internally (e.g. as opposed to calling external components) but uses external resources as input. E.g. its core processing consists of retrieving static resources and then doing more calculating internally.
I'll rectify first:)
For the purpose of this answer let's just say that REST is a way of organizing resources and the operations you perform on them.
SOA uses SOAP or REST protocol to transfer XML or JSON document between various services.
Absolutely not. REST is not a protocol. SOAP is a protocol, that's true. It is frequently used in SOA architectures, particularly for the implementation of SOAP over HTTP or SOAP over JMS. However, SOA does not imply SOAP. You could use any other protocol.
Same applies to XML and JSON. You could use just any other language or dialect.
Now the explanation. SOA is service oriented architecture. Therefore the whole system is made up of services that typically perform some operations. The architecture is based on this. Imagine a cloud of servers where each one holds at least one service, for instance WeatherPredictor, ForexCalculator, etc.
Opposed to this you have the resource oriented architecture, ROA, where the system is made up of resources. Imagine a cloud of servers where each one represents one or more resources, for instance Weather, Euro, Dollar, ...
ROA is typically used in big, open systems, because of the advantages it brings. In ROA architectures you would typically find RESTfull services. RESTfull services are nowadays typically implemented with just JSON over HTTP, or XML over HTTP.
SOA is used a bit everywhere. In SOA you commonly find the SOAP over HTTP, SOAP over JMS, etc.
But some day you may encounter a RESTfull web service that for some weird reason uses SOAP (perhaps the developers needed to embed the message in the SOAP envelope for some obscure reason). I think you won't find this example in real life, but just to show you that SOA or ROA do not imply the protocol to be used, in this case SOAP.
Hope this helps.
Based on my experience, my understanding is as follows:
ROA is API wrappers over data models, SOA is API over functional modules.
ROA is used to provide CRUD operations. SOA is used to link modules at run time.
ROA insulates API consumers from changes to data models. SOA allows drop in replacements of modules, simplifying deployment and customisation.
Two main types of distributed system are:
Request / Response type systems
REST - Resource oriented
Communication with HTTP resource
Involves operation for lifecycle of resource through HTTP GET, PUT, POST etc.
resource data can be cached
SOAP - Service oriented
Involves communication with specific application service
doesn't involve lifecycle operations on service lifecycle management
All messages are sent to service endpoint
endpoint decides how to process request
EJBs - Object oriented
Communication with object
involves marshalling unmarshalling of object
stateful
Message passing type systems - Messaging Queue
You should be able to differentiate the differences between SOA & ROA from here.
ROA (Resource Oriented Architecture) and SOA (Service Oriented Architecture) are two different architectural styles for building distributed systems.
In ROA, the focus is on the resources that are being accessed, and the interactions between clients and servers are centered around those resources. In other words, ROA is a style of architecture that is primarily focused on data or resources, and the way in which those resources can be accessed and manipulated.
In contrast, SOA focuses on services, which are self-contained and modular components that can be reused across different applications. SOA is designed to facilitate the integration of different applications and systems by making it possible to share services between them.
Here are some key differences between ROA and SOA:
Focus: ROA is focused on resources and the interactions between clients and servers that are centered around those resources. SOA, on the other hand, is focused on services and the way in which those services can be shared between different applications.
Granularity: ROA is generally more fine-grained than SOA. The focus on resources means that interactions with the system tend to be more specific and targeted. SOA, on the other hand, is often more coarse-grained, with services that are designed to be reused across many different applications.
Reusability: SOA is designed to maximize the reuse of services across different applications, while ROA is primarily focused on the access and manipulation of resources.
Interoperability: SOA is often used as a way to facilitate the integration of different applications and systems, while ROA is more focused on providing a consistent and reliable way to access and manipulate resources.
Overall, both ROA and SOA are valid architectural styles that can be used to build distributed systems, and the choice between them will depend on the specific requirements of the system being built.
Related
An IT architecture composed of software that has been exposed as “Services” – i.e. invoked on-demand using a standard communication protocol. So, loose coupling on how to use SOA, give a good example.
There are three major types or methods or approaches that have been emerging for club information, disparate and systems in a business. As different service providers and businesses race towards providing solutions to customers and consumers, these approaches help to meet the requirements for coarse-grained, loosely clubbed and asynchronous services.
1. The Enterprise Service Bus
The first approach that helps to build and implement an optimal SOA is the enterprise service bus or ESB. This approach helps to coordinate and arrange the different elements that are in the form of distributed services on a network. This approach considers the systems to be discrete and distributed services that connect to one another through message oriented infrastructure that is asynchronous. This kind of a message-oriented infrastructure makes it possible to have loosely coupled connections between independent services or modules.
2. Business Process Management
Many companies, for many years now, have tried to solve business process problems by the implementation of Business Process Management approach. This approach takes into consideration the IT assets and systems as activities or tasks that participate in well synchronized and well-orchestrated business procedures. BPM tools are mainly used at the time of modeling and designing procedures rather than using them to construct processes that can reach integration objectives. This is the main challenge of BPM. By BPM solutions on their own are enough to meet SOA requirements because they do not consist of the runtime environment that is needed for loosely coupled modules.
3. Service Oriented Integration
The third and the last approach to proper implementation of SOA is the service-oriented integration approach. This particular approach makes use of the architectural guiding rules or principles to build an environment or ecosystem of services that businesses can combine dynamically and create superior level processes that can meet ever changing and evolving requirements. This approach moves past tightly coupled and brittle modules by creating a distinction between the consumer and producer of a service. It thus imposes the aspect of loose coupling that is needed to implement SOA properly to meet business requirements. Even this approach by itself isn’t sufficient to guarantee long time running interactions between services.
As per Service-Oriented Architecture (SOA) definition, an architectural style that supports service-orientation.
Does that mean only web services (SOAP and REST) are treated as part/backbone of SOA? What about messaging services?
No and yes.
A webservice can be designed in a service orientated way, but a "service" (SOA) describes functionality, a bundle of business logic.
Service orientated architecture means, you have different systems, different users, and the way you implement your business focuses on the whole beeing a service.
The former (SOA) is something abstract, a paradigm, a commitment on how to implement something, the latter is technology (REST, SOAP, ...).
In conjunction with webservices, the "how to" is often described using WS-Business Process Execution Language (short: BPEL). It is used to orchestrate providers and consumers and allows high-traffic processes to scale in the cloud.
Consider your bank, processing many business steps per second in a very standardized fashion; using standard services like transfering money from one account to another.
Talking about Java and JMS, Oracle has a tutorial up: This example shows the steps to create a simple JMS queue in WebLogic Server 11g for testing purposes.
The project I'm currently involved requires that business logic must be implemented in Web Service that will be consumed by the Presentation Tier Components (i.e. Web Applications).
The company has an Enterprise Service Bus, and up-to-date almost every Web Service developed is exposed through this bus. I asked some colleagues around about when to expose Service through ESB and I got this answers:
If there's an ESB, expose everything through it: There are several benefits like Load-Balancing and location transparency
If the ESB will only act as a Proxy -i.e no message transformation- just don't use it: You'll overload the ESB and lose performance. You'll better do a point-to-point connection.
You should expose a component through ESB if there's a protocol transformation (like exposing a Stored Procedure as a SOAP Service). If this isn't present you better go Point-to-Point.
So I'm curious if there's a general agreement or best-practice of when to expose a Web Service through it or not. Any reading/reference would be a great help.
From my point of view and after 4 years of experience with SOA technologies, using an ESB will always overload the system since you are adding a new layer and making all your communications go through it. Transformation (either messaging or protocol) and routing aren't to hard to accomplish without an ESB and point to point communication will have a bit higher throughput. Same happens also with business process automation, there are ways to get there without the need of an ESB.
In the other hand, the use of an ESB has several benefits in the scope of a corporation but it must be within a vision and strategy. One of the best examples is a company that has been working for a long time with a wide range of tools, each of them for a specific purpose and that made the company be distributed in teams which work in silos, ones isolated from the others. After a long time that makes interaction between teams complex and slow. A well planned SOA strategy will help to integrate all those tools and start replacing them for more meaningful lightweight items.
So, IMHO, Using an ESB just to solve a couple of "issues" in a single project without a corporate strategy isn't a good idea and, eventually, the word SOA will be banned in your company, when the problem isn't SOA by itself by rather the lack of vision and corporate strategy.
The only rule of thumb that I found regarding the use of ESBs is: The requirement of transformation, routing, business process automation (with or without human interaction), etc. in a single project is not a symptom of going SOA (almost every project has to perform transformations, routing and business process automation), but when those needs are the ones for a whole corporation then it's worth to think about it from a business point of view, never a technical one. If there isn't a business perspective, then SOA will fail.
This is a really wide topic and discussion can last for ages, I will suggest you a couple of links for further reading:
Some SOA Case Studies
Top 10 Reasons why SOA fails
I consider a self-described / auto-descriptive service as a good thing in a SOA architecture, since (almost) everything you know to call the service is present in the service contract (such a WSDL).
Sample of a non self-described service for me is Facebook Query Language (FQL http://wiki.developers.facebook.com/index.php/FQL), or any web service exchanging XML flow in a one String parameter for then parsing XML and performing treatments.
Last ones seem further more technically decoupled, since technically you can switch implementations without technical impact on the caller, handling compatibility between implementations/versions at a business level. On the other side, having no strong interface (diluted into the service and its version), make the service tightly coupled to the existing implementation (more difficulty to interchange the service and to ensure perfect compatibility).
This question is related to How to Implement Loose Coupling with a SOA Architecture
So, are self-described / auto-descriptive services loosely or tightly coupled in a SOA architecture ? What are the impacts regarding ESBs ?
Any pointer will be appreciated.
The thing is that loosely coupled SOA services will tend to interact with each other using publish/subscribe semantics not supported by WSDL (which only supports request/response).
When you introduce an ESB like NServiceBus, it focuses on messages and ownership rather than the method invocations that tools generate from WSDL. Those messages can then be represented either as classes in code or in an XSD for interoperability.
The transportation of XML messages from one endpoint to another when done with standard web services does look quite silly as the contract doesn't appear in the WSDL, and that's one of the places where ESBs come in.
Hope that helps.
The basic client-server model (even when implemented using questionable interfaces) had a presentation layer, a business layer, and a data layer. Are the directory and discovery methods using webservices models considered a entirely new layer? I would argue that the discovery layer is actually just expanding the role of the data layer to include information on where a service can be found. I am struggling to understand the interplay between webservices and the MVC framework and I am trying to understand the bigger picture as to where the directory and discovery components fit into that framework.
I would say that there is an additional layer -- the service layer -- that sits between your business layer and the presentation layer or your business layer and the data layer depending on whether you're doing a thin- or thick-"client" implementation. This layer would encapsulate service discovery and delivery, including marshaling/unmarshaling data for transfer. See Fowler's Principles of Enterprise Application Architecture Service Layer description. In his concept the service layer sits between the business layer (domain model) and the presentation layer (UI). This concept would apply to a thin-client or web-based client implementation.
I would say there are not basically 3 tiers in the web services model.
Web services is essentially SOA (Service Oriented Architecture), which can imply a multi-tier (n-tier) model. It refers to distributed computing and could be scaled up to a massive system with hundreds of "tiers".
I would agree with you that conceptually, getting your data from a service as compared to a database, could be similar to getting data from other data sourced like databases, etc., and that this could be conceived of as an additional function of the data access layer.
Of course it also depends on semantics. Often "tiers" refers to discreet parts of the overall system (i.e. front-end, middle-tier, back-end data sources, other tiers such as integration with web services, etc.); while "layers" often refers to the vertical layers in the code such as presentation, controller, business logic, data access, etc.