I have an application which is packaged as a single ear file deployed on WebSphere. Inside the package, the code is organized in to UI files, Business Logic files and Database related files. Now, is this a monolithic application or a 3-tier architecture?
What is the difference?
You are comparing wrong things. Monolithic application need to be compared against Micro Services. In monolithic application; you deploy all the features/api end-points in a single EAR/WAR file; i.e. single JVM. In micro-services they are deployed in multiple JVMs. Note that in Monolithic architecture also you have multiple REST end points exposed.
3 tier, or 2 tier or N tier architectures is a different concept. It says how many subsystems/modules your application is divided like database layer, client layer, application logic layer. Hence, monolithic as well microservices both can be n tier applications.
Remember that a EAR and what is in it is a packaging choice. Your same application can be deployed in multiple ears in multiple Java EE containers on one or more servers. The EJB-jars and WARs are intended to do that. With Java EE you choose how to distribute you application across the containers and nodes based on what make sense.
Technically a tiered application is one where the layers can be independently deployed, distributed and accessed. I.e. my business logic can be on 5 servers in 9 ejb containers and accessed by 3 user interfaces that could be desktop, mobile, web etc. And possibly parts of different applications.
The more traditional definition of a monolith was an application that wasn't tier. Specifically that its parts cannot be composed in to other applications at runtime
Is it good idea to separate out implementation of each http verb in different micro service?
For example
GET books/{id} - micro service A
POST books/{id} - micro service B
This appears to be overkill for "books" api but in a typical enterprise an api resource/verb do a lot more than a hello work api.
Is it good idea to separate out implementation of each http verb in
different micro service?
The boundaries of microservices are usually drawn by separable business concerns. The main reason to do that is for enabling separate teams to be responsible for the complete lifecycle of a service, with minimal external dependencies. This allows for a faster release cycle of services in a complex system.
For understanding the microservices architectural style I recommend reading the material from Martin Fowler.
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.
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.
What exactly is web service composition?
Composition refers to the way something is build, the new term at the moment is mash-up which basically means utilising a variety of different services in a composite application. So that functionality of disparate application can be used in one application.
I think your referring to service granularity - which means how much functionality a service exposes. a coarse grained service will expose a whole process as a consumable unit whereas a fine grained service will expose a specific unit of logic from a larger process. Obviously, it is up to the service architects to determine what granularity of service works best in the given environment.
This also, in a way has to do with the style of SOAP message you are using whether it is RPC style or document and that a service should be atomic and not hold external state. Meaning it does not need to know any more information other than that in the SOAP message to perform its function.
Hope this gives you a good starting point. The trouble with service-orientation is that it differs depending on who you read, but the main points stay the same!
Jon
Some web services which are provided for clients are abstract and composition of some smaller web services and it's called web service composition.
Sometimes there are more than one web service in order to use as the mentioned small web services, so we choose them based on QoS (Quality of Service) and many researches have been done on this subject.
Web service composition involves integration of two or more web service to achieve more added value of business functionality. A work flow composer is responsible of aggregating different web services to act as a single service according to functional requirements as well as QoS constrains. BPEL is one of the popular composers uses XML language to perform service composition. Fine-grained services perform single business task and provides higher flexibility and reusability. However, coarse-grained service involves performing complex business functionality leading to lower flexibility