0

As mentioned in wiki,

A service-oriented architecture (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. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online.

Each SOA building block can play any of the three roles:

  • Service provider

  • Service broker

  • Service requester/consumer


Implementation approach

Service-oriented architecture can be implemented with Web services. Ex: Web services based on WSDL and SOAP

A web service implementation talks about exposing POJO with @WebService tag and another implementation talks about exposing those POJO in services.xml.

The client will avail those exposed services over SOAP or REST.

————————

1) Are web services(like Axis2) only option to implement SOA building blocks?

If yes,

2) what are the challenges of conventional middle ware(RMI/CORBA) that web services addressed?

  • Additionally, RMI is faster in communication compared to web service implementation like Axis2 – overexchange Jan 1 '18 at 13:04
  • As a quick note: Java RMI is quite convenient in a pure-Java environment, but it's more of a bridge between to JVMs than a suitable communication mechanism in a SOA. In particular, with RMI all your processes must be Java and must be deployed with the same class files. By using a language-agnostic protocol or serialization format, you gain a lot of flexibility. RMI is also synchronous 1:1 communication. Message queues are more flexible, incl. many-to-many communication or async/event-driven patterns. It doesn't matter if RMI is faster if it's the wrong tool. – amon Jan 1 '18 at 13:46
  • @amon I do not think there is a need here to compare interoperability aspect. 1-1 communication? Please check my below referred query – overexchange Jan 1 '18 at 13:49
3

The goal is the same: have a mean for systems using different languages and operating systems to interoperate. Therefore, it's not that different after all.

How should you choose one over another? It all depends on how well such or such tool is supported by the platforms where they will be used.

If your intention is to make communicate two services developed by teams who are familiar with CORBA, you know what to do. If, on the other hand, your intention is to provide a service to be used by anyone, chances are, many developers would know how to call it through REST, some of them would have a prior experience with SOAP, and only few will know how to use CORBA, meaning that REST would be your first and maybe only choice.

See also: Microservices REST or AMQP, which case.

  • One more relevant question – overexchange Jan 1 '18 at 13:20
  • Despite rmi/corba evolved before web service, why many developers know REST or SOAP? – overexchange Jan 1 '18 at 13:39
  • Do you mean RMI/CORBA fit in service oriented architecture products? – overexchange Jan 1 '18 at 13:40
  • 1
    @overexchange: developers know REST and SOAP because CORBA lost popularity. Why did it lost popularity, you'd ask? See an excellent answer by Jörg W Mittag which explains that. – Arseni Mourzenko Jan 1 '18 at 13:51
  • @overexchange: about CORBA fitting in SOA, it depends on your definition of SOA. For me, CORBA is one of the ways to do SOA. This opinion is not necessarily shared by everyone: stackoverflow.com/q/2461595/240613. – Arseni Mourzenko Jan 1 '18 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.