fbpx
Select Page

java-web-services-sevenemntor

Learn From the SevenMentor Institute for Java Classes in Pune | Sevenmentor.com

In this blog series I will be attempting to explain the concept of services, how services evolved with the growth of:

  • distributed applications
  • collaborative enterprise applications – firstly collaborative applications that were similar technology stacks and then, with innovation by diverse enterprise teams, diverse technology stacks
  • internet and with it web applications
  • Web 2.0 and social applications and the need to take advantage of new application features additions as early adopters and getting faster deliveries

The growth also coincided with architecture evolution to support the service evolution – we have seen application integration and collaboration using services grow, Service Oriented Architecture becoming mainstream, Container based application deployment and Microservices Architecture come forth in the last few years to support scalable and hyperscale service deployments.

I will cover some significant service implementation manifestations like RPC, CORBA, COM/DCOM, EJBs, WebServices like SOAP WebServices and REST WebServices.

Each manifestation pushed forward the service evolution multifold until it encountered challenges in fulfilling a new set of distributed computing use cases and a different manifestation became more popular.

So we can be sure that though REST WebServices utilizing Container Solutions and MicroServices Architecture is very popular in solving some of the current requirements, the next set of distributed computing use cases will bring forth a new service implementation manifestation.

So lets enjoy the service journey and enjoy the current stability of service implementation manifestation while it lasts and look forward to the next disruptor in this area as it would also mean a new phase of collaborative application evolution.

And as we’ll notice, evolution in every area is the only constant.

For Free Demo classes Call: 8237077325

Registration Link: Click Here!

Distributed Computing vis-a-vis Service Evolution

Fundamental to understanding services is understanding what a service is.

A very generic and basic elaboration of the term is that service is an application component that serves an application functionality. A further addition to this base is that it accepts request for delivery of application functionality and provides response(s) that encapsulates the application functionality delivery.

So this means a function in a functional language like C, a SQL Function/Procedure in a database like Oracle/MySQL or an object in an object-oriented language like Java/C# comprising of functions are services.

Hence an application could be defined as comprising of multiple services collaborating together to deliver the application functionality and fulfilling its objectives.

A traditional non-distributed application would look like this:

webservices

However it becomes obvious that as an enterprise demands more functionality and business requirements, a single monolith application is unable to service all these demands. Hence we get a number of dedicated applications created to fulfil a group of enterprise functions e.g. you may have product cataloging applications, customer order intake applications, order fulfilment applications, order dispatch application, billing applications, etc…And at the same time we need all these dedicated functionality applications to interact with each other to fulfil the enterprise business objectives, like for e.g. getting customer to order a product, bill him, fulfil and dispatch the order in the example above.

As a result, we end up having a service requirement or use case to go beyond traditional application boundaries to request for delivery of a collaborating application’s functionality and getting a response from that application for the same.

This is the point where distributed computing requires service implementations to support invocation of application functionality across the network, which differed from the earlier scenario. As a consequence we got Remote Procedure Calls (RPC) to allow procedural languages like C, FORTRAN to have their applications remotely collaborate across the network. This was achieved by the support of eXternal Data Representation (XDR) protocol in these languages. XDR allowed complex data structures required in service requests and responses to be defined and encoded/decoded across the client/server machines.

This step in the service evolution allowed an application to break the boundaries of a single machine and work with other applications across the network.

Along with procedural languages we had object oriented languages like C++ which tried to use RPC. But it quickly became apparent that it was a cumbersome process and needed retrofitting to use it in an object oriented contruct from a function-based approach that it followed.

So new distributed computing protocols like CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Common Object Model) were invented to allow a more natural object-oriented interaction. CORBA evolved via a consortium of large standardization group with support of large companies like IBM, Oracle and Sun. COM/DCOM came from Microsoft for their technology and development stacks.

CORBA uses an interface definition language (IDL) file to define the interfaces that objects in the service represent. These then map to language specific constructs. CORBA got good support from vendors and applications built in C++, Java, Python, Ruby via standard mappings. We also got non-standard mappings C#, Visual Basic, Perl.

DCOM evolved from Microsoft and got support on the Windows platform and development stacks in Visual Basic, Visual C++, .Net Applications.

Due to issues in cross-vendor ORB implementations and challenges in overcoming security firewalls, we ended up with CORBA being used for mainly homogenous and similar technology stack distributed application implementations being developed and recommended.

Also DCOM got mainly tied up with Microsoft application stack and platforms.

This got further complicated by the fact that two strong distributed computing standards didn’t work well together. We ended up having protocol converters in case we wanted CORBA applications to communicate with DCOM applications or vice-versa. And even this was too complicated to be recommended as a regular solution.

Consequently the requirements of integrating diverse applications over an enterprise led to a standardization of the Service integration and interaction mechanisms. The growth of Internet, widespread support of HTTP/HTTPS protocols for across the network communication, development of XML standard allowed evolution of distributed applications collaborating over Web Services based on SOAP and REST.

But that’s the details of my next blog. So stay tuned!!!

For Free Demo classes Call: 8237077325

Registration Link:Click Here!

Author: Kiran Tiwari

Designation: Software Trainer

Company: Sevenmentor Pvt. Ltd.

Call the Trainer and Book your free demo Class for JAVA now!!!

call icon

© Copyright 2019 | Sevenmentor Pvt Ltd.






Pin It on Pinterest