Reading the paper , attending the lectures of the course “Services Engineering with Models” and reading a lot of heterogeneous web pages, I learned a lot of new concepts about Service-Oriented Computing and Web Services. First of all, I want to clarify the definitions of the basic concepts.
Service Oriented Computing(SOC) paradigm uses services in order to let developers to rapidly create low-cost and massively distributed applications.
Moreover, the visionary promises of SOC are that developers can very easily combine pre-existent services using them as an external component of their now dynamic business process and agile applications.
Service Oriented Architecture (SOA) is an architectural model and a style of software design which allows interoperability, re-usability, loose-coupling of its components.
As said here  SOA enables business and IT convergence through agreement on a set of business-aligned IT services that collectively support an organization’s business processes and business goals.
Software as a Service (SaaS) is a software distribution model in which a third-party provider hosts applications (and so services) and makes them available to customers over the network.
In my opinion, the difference between Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and SaaS is the choice at which layer of abstraction the control of the provider stops and so at which one the control of the client starts.
In my opinion, looking only at the small aspect of programming, Service Oriented Programming is in direct continuity with Object Oriented Programming (OOP) and Component-Oriented Programming (COP). As shown in the following picture:
One could write an entire book on this aspect. I want only to say that SOP is to another layer of abstraction, it is above the original COP because a Component, starting from his code, can be reused and so reincluded in new application, instead a functionality of a Service is in an endpoint of a network and who want to use it can make his application invokes the Service functionality. Later in this post, I will talk about Service Triangle and so about publishing, finding and binding services.
A Service can be a help, a work or a loan provided by a company performed through the network to satisfy a need to fulfill a demand.
Talking about a Software Service as said here :
“is a software asset of distinctive functional meaning that encapsulates a high-level business concept including contract, interfaces, implementation, business logic and data.”
In figure 1 of  there are the architectural layers of SOC, organized like a pyramid. In this pyramid of SOC there are 3 different layers:
Service Foundations: At the base of the pyramid there is the layer of the basic services capabilities provided by the backbone infrastructure that realize the runtime of all the SOA. It connects heterogeneous components to each other and to the Internet. To provide a very good integration between all these heterogeneous components it’s important to introduce the concept of the enterprise service bus. It supports services, messages and event-based interaction. It has two main purposes: breaking up the logic into easily manageable pieces and make the system loosely coupled.
Service Composition: The middle layer of the pyramid contains roles and functionalities for aggregating multiple services. It must understand all the different services’ policies, makes them collaborate with good performance respecting the security requirement.
Service Management: At the last plane of this scheme there are many actives like installation and configuration, monitoring and tuning, etc. More in details it involves monitoring events produced by the services and processes, collecting statistics about the state of the processes/virtual machines and eventually change the state (suspending, resuming, terminating, etc.)
After the reading of this paper , I can say that SOC triangle is a simple principle, a guideline for SOA. We have 3 entities: Service Register, Service Provider and Service Requestor.
The main approach can be described in these points:
Provider creates some service, making it available to some client
Provider creates “registration documents” and registers these with some “registry service”
Consumers, looking for that particular type of service, locate binding information via the registry service
Consumers then bind (based on the indicated protocol in the registry documents) with the producer, and consume the product service
The primary method by which services are registered and discovered (located) in an SOA is through common registries based on the Universal Description, Discovery, and Integration (UDDI) specification.
The term Bind means the procedure that “tie” the client that want to consume a service and a server (there could be more than one providing the same service) that is providing it. This procedure is very important because it’s important to determine the specific detail required to make the first connection and then all the next one.
In Web services, you describe a binding using the WSDL binding element.
The invocation of a Web Service is different from the Binding because it happened after it and it is the real consumption od the service. It’s like to actually invoke some “method” from the server in order to obtain a result, and so it’s the true use of a service.
I liked a lot this  paper because for each of service pyramid it clarifies the roles, the state of the art and the research challenges.