I have been looking a lot at SOA recently. Isn't CORBA exactly the same thing as SOA?
In addition to the fact already mentioned, that SOA is an architecture, and CORBA a specific implementation.
CORBA doesn't implement SOA
the main difference is that CORBA is Object Oriented or Component Oriented and SOA is Service Oriented
The main technical difference (in my opinion) is that in SOA you pass messages (or data objects) and in CORBA you can pass generic objects (which can have methods)
so although you can implement SOA using CORBA (by limiting you self to a subset of the functionality), the standard way of using CORBA isn't service oriented.
The difference between CORBA and SOA is that CORBA is a specific technology, whereas SOA is a style of architecture.
SOA as a concept has been around for years, but was only more recently named as such. There are many technologies that can be said to implement SOA - either completely, or aspects of it. CORBA could be said to be one of them, although the term wasn't around when CORBA was created.
CORBA certainly implements are large part of the SOA surface area, but I don't think you could say it does so completely (whatever that means). SOA can be a bit vague.
While there is no "official" definition of SOA, part of the point of it is to decouple the various services from each other. This includes possibly decoupling the implementation (platform and technology) used in the service. As an example if one exposes a service via WebServices, any client be it java/python/.Net etc... could consume this service - but utilizing a RPC/remote procedure call framework will often tie you into a particular platform/implementation in order to call the service.
Corba does offer some of what SOA promises, but is at best a subset of what SOA is "meant to be"
The main difference though is that SOA is a general architectural concept, while Corba is a technology implementation of the RPC/Remoting concept
Not really. SOA is an architectural style while CORBA is a particular technology with which you can implement SOA.
CORBA and SOA are both architectures. It is wrong to say CORBA it is an implementation. It is not. It is an architecture, a vision of systems build with objects. SOA is also an architecture, a vision of systems build with services. They both are ways to organize your systems as a collection of either objects or services. There are specific implementations for CORBA as well as for SOA.
They are both technologies. They both give you receipts and recommendations for structuring your systems and for managing complexity. There are tools developed by third parties to support these technologies for both of them.
The objects in a Common ORB Architecture (CORBA) provide services so you can think of a translation between Service Oriented Architecture (SOA) and Common ORB Architecture. They are not the same thing, but one can imagine implementing a software system with either the one or the other, making them, from a certain point of view, equivalent.
They are not the same thing in the same way as Object Oriented Programming and Structured Programming or Functional Programming are not the same thing, although one could use any of the above mentioned programming styles to implement a certain functionality.
They are inherently different because one depends on the technology (CORBA) and the other doesn't.
CORBA is an open standard developed by the OMG (Object Management Group) for the use ORB (object request broker) middleware with a great focus on interoperability (software platforms, hardware platforms and programming languages).
SOA is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. The basic principles of service-oriented architecture are independent of vendors, products and technologies.
I had the same doubt as you because the definition of SOA is too broad and I can see many concepts of CORBA can be mapped naturaly to SOA's terminology. For example in CORBA, clients (objects) ask to servers (also objects) to do some work through a communication protocol over a network. Moreover CORBA implementations provide general services like logging and event support. I think this link summarizes the relation between CORBA and SOA:
The first service-oriented architecture for many people in the past was with the use of Object Request Brokers (ORBs) based on the CORBA specification. The CORBA specification is responsible for really increasing the awareness of service-oriented architectures.
Related
Can I use SOA and three-tier in one application? Using SOAP to connect for external services, using MQ and Spring MVC. I have an application server and server for the database.
Yes, it seems that they are very different things.
There is a vast array of different SOA implementation styles, you can do it in so many ways. One is to have services talking to APIs over http where the APIs in question are written in a 3 tier style.
You can also have an event driven architecture where messages are passed on a message bus or a queue or some sort, the services reading and writing to those queues can be written in a three-tier style.
To sum up yes you can have SOA and three-tier in the same architectural solution, one does not exclude the other.
Does this help your decision on how to structure your service design and how to structure the wider solution architecture?
I've been trying to get my head around some SOA principles and I came across this page which describes a microservice in SOA:
http://soapatterns.org/design_patterns/micro_task_abstraction
Solution: Individual units of non-agnostic logic with specialized
processing and deployment requirements are separated using the
microservice model and abstracted into a microservice layer in which
there is the architectural freedom to tailor environments in support
of specialized service processing and deployment requirements.
What are exactly these specialized processing and deployment requirements?
And what's the key difference between a microservice and a taskservice in SOA? as they both appear to me none-agnostic and can be composited of other entity and utility services.
Service Oriented Achitecture (SOA) deals with defining services, design of what the services are meant to do, their interface, governance, service lifecycle, operational SLA's and "usage agreements" (these last two lead to a number of non-functional requirements), among others.
Microservices can be considered more of a development and deployment approach. If SOA is defined correctly (your interfaces are clean, designed with appropriate granularity, loosely coupled), it is easier for you to apply a microservices approach, subject to your technical platform.
Once you have defined a service, your implementation considerations would include infrastructure, application servers, build and deployment mechanisms. A key defining feature of a microservice deployment model is that as much of the "stack" is self-contained within a single deployable unit (can be referred to as a container).
Using a Java example, at the very least a microservice might be one service or function (exposed as Rest or SOAP) running in its own standalone JVM (bundled libraries, application/web server) which you can refer to as a container (example here). Contrast this with a more "traditional" approach where you might have one team managing the application server on which you might deploy multiple services or functions. The major benefit is you can avoid conflicting dependencies, your environment is fully in your control (effectively a few lines of code) and your service might perform more predictably as it has no interference from other services contending for the same resources (JVM threads, Data sources to name a few).
Specialised container management tools such as docker and associated scripting allow you to put together any required configuration you need from your environment.
Update 16/Jan/2018
Also note this paragraph on the distinction between SOA and Microservices as concepts. I translate it as: People didn't do SOA right so needed a new buzzword. True to an extent. However, you could also see the two as complementary concepts - SOA being more design heavy while microservices being a more deployment focused methodology.
they have many common features. but how the difference?
MOM allow asynchronous while SOA does not, this is the only difference?
SOA, Service Oriented Architecture, is an architecture that defines how to structure access to business information between different applications. In a nutshell, usually, one application needs something done with a piece of information (may it be an orderfile or anything else) that application has a need. Another application may be able to do the corresponding processing of that piece of information, hence it has a capability. The first application then Consumes the Service of the second application, which Provides the Service (no matter the underlying technology, which can be anything such as JMS, HTTP/SOAP, HTTP/REST, EMail, FTP, etc.). To make this work, a Contract between the first application and the Service has to be defined which clears such things out as Message Format (XSD or similar), Protocol (HTTP/SOAP? JMS?) etc.
MOM, Message Oriented Middleware, on the other hand is just a family of software/middleware platforms. They are actual implementations, and not a high-level concept like SOA. They can be used to implement a SOA architecture, an Event Driven architecture or other architectures. Usually, MOM enriches a set of applications with asynchronous messaging where a MOM server stores and forwards the messages. Often things such as transactions, guranteed delivery, fail-over, loose coupling and load balancing are built into MOM implementations. Examples of MOM are IBM WebSphere MQ, Apache ActiveMQ, RabbitMQ, JBoss HornetQ, etc.
Message oriented middleware (MOM) is a type of technology where as SOA is a type of architecture. Even though a lot of people think about web-service when they talk about SOA, you can use MOM to implement it as well (in fact in many cases that's the better option)
Can we safely say that if ESB provides Orchestration features, it is eligible to be an implementation of BPM?
I understand that BPM has a different purpose, which is to Model some business processes and the implementation of those business processes can be done by any simple Java/J2EE application, complex SOA application, or some application saying that I provide BPM. Is that right?
First Question:
Your statement is valid for some business processes which merely models request-response interaction.
But when it comes to complex business processes we need to consider some other features apart from orchestration features. Here I have list down few such scenarios.
Let's take a business process which requires to maintain its state for a long period of time. We normally call them state-ful or long running business processes. To support these sort of business processes, there should be a state persistence mechanism. This functionality is not relevant to orchestration features.
Consider a business process, which requires some compensation capabilities. In that case, some of the business process modelling standards like, WS-BPEL have defined its compensation mechanisms. So apart from orchestration features, there are some other features which are needed to be considered.
Second Question:
Yes. But there are several pros in a BPM engine compared to your mentioned implementation mechanisms.
One advantage is, it's not possible to achieve a level of modelling abstraction provided by a BPM engine from a Java application. Let's say we used a JAVA application to implement a business process logic and that business process went to production. Say we need to change a endpoint URL of its partner service. In this case, now the business process implementation need to be modified, re-compiled and deployed back into the production system. if we implement the business process with a business process language standard like WS-BPEL, we can change the business process configuration very easily and push it back to the production. This improves the efficiency and reduce the business maintenance cost.
As well there are other reasons like easy adaptability and flexibility.
I've created these slides some time ago to explains exactly how you can use them both and the relationships between them:
http://www.slideshare.net/salaboy/jbpm5-community-training-module-25-bpm-for-developers
You need to understand the different perspective between something like BPEL/ESB/Orchestration and BPMN (business oriented) they have very different scopes.
Cheers
Normally ESB is assigned to the middle layer — orchestrating low-level services into larger service units, which will be exposed to the business for use in processes — and BPMs in the top layer.
So BPM will be used in the Business Process Orchestration Layer and ESB will enable and facilitate this by working in the Business Services and Service Enablement.
In another words to be successful with business processes first you need to have all your systems and apps exposed as services; that is where an ESB comes into play.
You could see this link : http://blogs.mulesoft.org/why-bpm-and-esb-need-to-work-together/
Let me add clarity by making the distinction between BPM, Orchestration, and ESB, via design patterns and specifications.
Generally speaking, "Orchestration" has been defined as a compound pattern employing the Process Abstraction, Process Centralization, and the State Repository design patterns. By virtue of the implementation of the State Repository Pattern and contrary to a previous post, Orchestration supports long running, synchronous business processes, just like BPM.
The major practical distinction between the 2 is that Orchestration middleware (e.g. WebSphere Process Server, BizTalk, Oracle BPEL Manager, and Windows Workflow Foundation) supports most of the WS * specifications. This includes Ws BPEL, Ws Security, Ws Atomic Transaction, Ws Business Activity, Ws Reliable Messaging, etc., while most BPM Tools do not.
As a result, feel free to use Orchestration at an Enterprise Level, but be very careful about using BPM in that scope.
In practice, both BPM and Orchestration tools enable the graphical representation of a business process. The distinction is that Orchestration may be expressed through Vendor-Neutral BPEL (Business Process Execution Language), while BPM is expressed via Vendor Specific BPMN (Business Process Modeling Notation). This is another reason to avoid BPM tools at the SOA/Enterprise Level.
In cases where a BPM Tool implements the Ws * specifications, it is an Orchestration Engine for all practical purposes. The distinction again being that BPM tools rely on Vendor-Specific BPMN and Orchestration tools rely on Vendor-Neutral BPEL.
In cases where both BPM and Orchestration need to coexist, limit BPM to application architecture (e.g. MVC style) and let Orchestration promote the sharing of enterprise assets.
An ESB is an entirely different animal. It should used for asynchronous, rather than synchronous processes and relies on a different set of design patterns (i.e. Service Broker, Asynchronous Queuing, Intermediate Routing, and the Content Enricher patterns)
Web services is a Service Oriented Architecture implementation.
But, can we say that CORBA, RMI and the Java EE platform are also an implementation of SOA?
If you say that SOA means WS-* standards, then the answer is "no".
But if SOA means distributed components communicating using an agreed-upon protocol, then the answer is yes, you can think of CORBA, RMI, and Java EE as SOA. (My advice is to drop the "2" - it's been out of the picture for a long time. Please refer to it as Java EE unless you want to appear out-of-date.)
Even web services have at least two flavors: SOAP and REST. You might also include XML-RCP.
The difference in all cases is the choice of protocol.
SOAP uses its own XML request/response idiom over HTTP.
REST is straight HTTP - GET, POST, URL for every request.
CORBA uses an OMG standard protocol. Interoperability between ORBs, and different bindings for each language, used to be a big problem. It's been so long since I've used CORBA that I have no idea of the current state of the art. I don't know anyone who uses CORBA anymore. From my vantage point, it's a failed, dead technology.
RMI is the Java-only answer to CORBA. All endpoints must be implemented in Java and speak RMI.
Java EE uses RMI as the underpinnings of EJBs.
Simple and open win: that's why HTTP-based protocols are growing in popularity.
yes. WS-* is one of the mostly used ways in which SOA is implemented.