In short Coupling, Cohesion and Granularity are part of SOA Design Principle and they can be summarized as follows:

• Service Coupling:
  • Definition: Refers to the degree of interdependence between two business processes.
  • Preferable State: Weak coupling is favored in SOA, indicating lower dependency for increased flexibility and maintainability.
• Service Cohesion:
  • Definition: Represents the degree of functional relatedness and focus of operations within a service.
  • Preferable State: Strong cohesion is preferred in SOA, indicating that a service should encapsulate closely related and well-defined functionalities.
• Service Granularity:
  • Definition: Denotes the scope of functionality exposed by a service.
  • Preferable State: Coarse granularity is recommended in SOA, suggesting that services should provide broad functionalities to address specific needs, promoting reusability.

Service Coupling:

Service Coupling is a critical design principle that examines the degree of interdependence between any two business processes or services within a system. It essentially evaluates how tightly or loosely these services are connected and the implications of changes in one on the others.

Characterized by the level of dependency, tight coupling signifies a strong interconnection where modifications in one service may necessitate corresponding changes in others. Conversely, weak coupling is the preferred state in SOA design. Weak coupling implies a lower level of dependency, allowing for greater flexibility, scalability, and ease of maintenance. Services with weak coupling can evolve independently, reducing the risk of unintended consequences when modifications or updates are made.

The benefits of weak coupling extend to the adaptability of the architecture to changes in business requirements. Services that are loosely coupled are more resilient to alterations, ensuring that adjustments in one part of the system do not propagate unexpectedly to other interconnected services.

For example, a service employing standardized interfaces and protocols can interact with other services more loosely, minimizing the impact of changes in one service on others. Achieving weak coupling often involves defining clear service interfaces, minimizing direct dependencies, and utilizing standards to facilitate interoperability between services. In essence, Service Coupling is a foundational principle in SOA design that promotes a modular, adaptable, and scalable architecture.

Service Cohesion:

Service Cohesion stands as a pivotal design principle governing the internal organization and functional relatedness within an individual service. It delves into the degree to which the operations encapsulated within a service are logically connected and focused on a specific set of functionalities.

Characterized by its emphasis on functional relatedness, strong cohesion is the ideal state for services in SOA. A service exhibiting strong cohesion encapsulates a well-defined and closely related set of functionalities, ensuring that its operations are united by a common purpose. This design approach enhances the service’s clarity, maintainability, and usability, as all contained functionalities contribute to a coherent and unified business capability.

In contrast, weak cohesion suggests a service with disparate functionalities that may not be logically connected, leading to a lack of clarity and potentially hindering the service’s effectiveness. Strong cohesion, on the other hand, facilitates a service’s reusability, as the encapsulated functionalities are designed to work together seamlessly, promoting a modular and extensible architecture.

For example, a service responsible for order processing should ideally encapsulate functionalities such as order validation, payment processing, and inventory management, exhibiting strong cohesion by focusing on a cohesive set of operations related to order fulfillment.

Achieving strong cohesion often involves careful analysis of the business processes and ensuring that the functionalities grouped within a service share a common context and purpose. This principle contributes to the creation of services that are not only well-defined and purposeful but also conducive to building a scalable and adaptable SOA.

Service Granularity:

The concept of Service Granularity plays a crucial role in defining the scope of functionality exposed by a service. It is essentially a measure of how broad or specific a set of functionalities needs to be in order to address a particular business need. The degree of granularity directly impacts the reusability, flexibility, and efficiency of the services within the architecture.

In SOA, the preferable state for Service Granularity is characterized by a tendency towards coarse granularity. Coarse-grained services encapsulate broader and more encompassing functionalities, capable of addressing significant business requirements in a single service invocation. This design approach promotes simplicity, reduces the number of service interactions, and facilitates easier maintenance.

Conversely, fine-grained services expose narrower sets of functionalities, potentially requiring multiple service invocations to fulfill a specific business operation. While fine granularity may seem intuitive for certain scenarios, it can lead to increased communication overhead and complexity, making the system more susceptible to performance issues and maintenance challenges.

For example, a coarse-grained service responsible for customer management might encompass functions such as creating, updating, and deleting customer profiles, providing a comprehensive set of functionalities within a single service interface.

Achieving the right level of granularity involves careful consideration of the business context and requirements. Coarse granularity is favored as it enhances the potential for service reuse, reduces the impact of changes on service interfaces, and aligns with the overarching goal of creating a modular and scalable architecture in SOA. Striking a balance between granularity and functionality is key to building an effective and adaptable service-oriented system.

Unlock the power of Service Oriented Architecture (#SOA )! Learn how #service Coupling Cohesion, and Granularity influence flexibility and #scalability in your #System . #softwaredevelopment #programming #API
Share on X

Service Oriented Architecture (SOA) Design Principle and Application Programming Interfaces (APIs)

The concepts of Service Coupling, Service Cohesion, Service Granularity, and APIs (Application Programming Interfaces) are intricately related in the context of designing and implementing a Service Oriented Architecture (SOA) or any modular and scalable system. APIs act as the external interface for services, and their design choices have a direct impact on the level of coupling, the cohesion within services, and the granularity of functionalities exposed. A well-thought-out API strategy is crucial for realizing the principles of a modular, scalable, and adaptable Service Oriented Architecture.

APIs and SOA operate at different levels of abstraction and have distinct purposes within the realm of software architecture. The distinction in their level of abstraction is rooted in their design principles, scope, and intended use. APIs are considered more low-level than SOA because they provide detailed interfaces for developers to interact with specific functionalities, while SOA operates at a higher level, focusing on the overall organization and alignment of services within a system. APIs are tools that facilitate the implementation of SOA principles at a more granular level.

This specific article focus on SOA design principles; if you want to know more on how to design a good API you can find more information here.

The post Service Oriented Architecture (SOA) Design Principle: Coupling, Cohesion, and Granularity appeared first on Francesco Lelli.

Folks at OpenAI developed the ChatGPT model as a way to optimizing language models for dialogues. I found this idea quite challenging with a lot of potential. Therefore, I asked to Chat.OpenAI an open question that on a topic that I am familiar with. As ChatGPT is design for dialog I asked also a few sub-questions as well where I was searching for more details. What follows is the unedited answers:

What is Service Oriented Architecture

Service-oriented architecture (SOA) is a software design approach that focuses on building a network of independent, modular components that provide services to other components over a network in order to form a complete application. This architecture is designed to make it easier to develop, deploy, and manage complex applications by breaking them down into smaller, independent units of functionality that can be developed, tested, and deployed independently. SOA is often used in distributed systems and relies on communication protocols such as web services to enable components to interact with each other.

Some of the key features of service-oriented architecture (SOA) include:

1. Modularity: SOA is based on the idea of breaking down complex applications into smaller, independent components that can be developed, tested, and deployed independently.
2. Independence: Each component in an SOA-based system is independent and can be managed and maintained separately from other components, which makes it easier to develop, deploy, and update applications.
3. Standardized communication protocols: SOA relies on standardized communication protocols, such as web services, to enable components to interact with each other. This allows different components to be developed using different programming languages and technologies, as long as they can communicate using the same protocol.
4. Reusability: Because components in an SOA-based system are independent and modular, they can be easily reused in other applications, which can save time and effort during development.
5. Flexibility: SOA allows for flexibility by enabling components to be added, removed, or updated without disrupting the overall functionality of the application. This makes it easier to adapt to changing business requirements and technology needs.

Modularity

Modularity is one of the key features of service-oriented architecture (SOA), and refers to the idea of breaking down complex applications into smaller, independent components that can be developed, tested, and deployed independently. This allows each component to be managed and maintained separately from other components, which makes it easier to develop, deploy, and update applications.

In SOA, each component is called a “service” and provides a specific function or piece of functionality. For example, a service might be responsible for handling user authentication, or for performing calculations, or for storing and retrieving data from a database. By designing an application as a network of interconnected services, developers can create more modular and scalable applications that are easier to maintain and update over time.

Modularity is an important concept in SOA because it enables developers to create applications that are flexible and adaptable to changing business requirements and technology needs. For example, if a new service is needed to support a new feature, it can be added to the application without disrupting the existing services or the overall functionality of the application. Similarly, if a service needs to be updated or replaced, it can be done without affecting the rest of the application. This makes it easier to evolve and improve an application over time without having to redesign the entire system.

Independence

Independence is another key feature of service-oriented architecture (SOA), and refers to the idea that each component in an SOA-based system is independent and can be managed and maintained separately from other components. This means that developers can work on different parts of the application without having to worry about how their changes will affect other parts of the system.

Independence is an important concept in SOA because it enables developers to create applications that are flexible and adaptable to changing business requirements and technology needs. For example, if a service needs to be updated or replaced, it can be done without affecting the rest of the application. This makes it easier to evolve and improve an application over time without having to redesign the entire system.

Additionally, because each service in an SOA-based system is independent, it can be developed using different programming languages and technologies, as long as it can communicate with other services using a standardized protocol. This allows developers to choose the best tools and technologies for each individual service, which can make the development process more efficient and effective.

Standardized Communication Protocols

Standardized communication protocols are an important aspect of service-oriented architecture (SOA), and refer to the use of specific rules and standards for enabling components to communicate with each other. In SOA, these protocols are used to enable services to send and receive messages and data to each other in order to perform their designated functions and contribute to the overall functionality of the application.

One of the most common protocols used in SOA is the web services protocol, which is a set of rules and standards for exchanging data between applications or services over a network. This protocol allows services to be developed using different programming languages and technologies, as long as they can communicate using the same protocol. This enables developers to create more modular and scalable applications that are easier to maintain and update over time.

In addition to the web services protocol, there are many other standardized communication protocols that are commonly used in SOA, such as REST, JSON, and XML. These protocols are designed to enable services to communicate with each other in a standardized and interoperable way, which makes it easier to develop and deploy complex applications.

Overall, the use of standardized communication protocols is an important aspect of SOA because it allows different components to be developed and maintained independently, while still being able to work together to form a complete application. This makes it easier to create flexible and adaptable applications that can evolve and improve over time.

Reusability

Reusability is a key benefit of service-oriented architecture (SOA), and refers to the ability to use components or services in multiple applications or contexts. In SOA, each component is called a “service” and provides a specific function or piece of functionality. By designing an application as a network of interconnected services, developers can create more modular and scalable applications that are easier to maintain and update over time.

One of the key advantages of this modular approach is that it allows services to be easily reused in other applications. For example, if a service is developed to handle user authentication, that service can be used in multiple applications without having to be redeveloped for each application. This can save time and effort during the development process, and can also help to ensure that services are well-tested and reliable.

Reusability is an important concept in SOA because it allows developers to create more flexible and adaptable applications that can evolve and improve over time. For example, if a new service is needed to support a new feature, it can be added to the application without disrupting the existing services or the overall functionality of the application. Similarly, if a service needs to be updated or replaced, it can be done without affecting the rest of the application.

Overall, the ability to reuse services in multiple applications is a key benefit of SOA, and can help to save time and effort during development, as well as improve the reliability and flexibility of applications.

Flexibility

Flexibility is one of the key advantages of service-oriented architecture (SOA), and refers to the ability to easily add, remove, or update components without disrupting the overall functionality of the application. In SOA, each component is called a “service” and provides a specific function or piece of functionality. By designing an application as a network of independent services, developers can create more modular and scalable applications that are easier to maintain and update over time.

One of the key benefits of this modular approach is that it allows developers to make changes to an application without having to redesign the entire system. For example, if a new service is needed to support a new feature, it can be added to the application without disrupting the existing services or the overall functionality of the application. Similarly, if a service needs to be updated or replaced, it can be done without affecting the rest of the application.

Flexibility is an important concept in SOA because it enables developers to create applications that are adaptable to changing business requirements and technology needs. For example, if the requirements for an application change over time, it is relatively easy to update or replace services as needed without having to redesign the entire application. This makes it easier to evolve and improve an application over time without having to start from scratch.

Overall, the ability to easily add, remove, or update components is a key advantage of SOA, and can help to improve the flexibility and adaptability of applications. This can make it easier to respond to changing business needs and technology trends, and can help to ensure that applications remain relevant and effective over time.

Summary (Still According to Chat.OpenAI)

Service-oriented architecture (SOA) is a software design approach that focuses on building a network of independent, modular components that provide services to other components over a network in order to form a complete application. This architecture is designed to make it easier to develop, deploy, and manage complex applications by breaking them down into smaller, independent units of functionality that can be developed, tested, and deployed independently. SOA is often used in distributed systems and relies on communication protocols such as web services to enable components to interact with each other.

Some of the key features of SOA include modularity, independence, and the use of standardized communication protocols. Modularity refers to the idea of breaking down complex applications into smaller, independent components that can be developed, tested, and deployed independently. Independence refers to the idea that each component in an SOA-based system is independent and can be managed and maintained separately from other components. Standardized communication protocols refer to the use of specific rules and standards for enabling components to communicate with each other.

Some of the key benefits of SOA include reusability, flexibility, and the ability to easily adapt to changing business requirements and technology needs. Reusability refers to the ability to use components or services in multiple applications or contexts. Flexibility refers to the ability to easily add, remove, or update components without disrupting the overall functionality of the application. The ability to adapt to changing business requirements and technology needs refers to the ability of SOA to enable applications to evolve and improve over time without having to redesign the entire system.

Does #OpenAI ( #OpenAIChat ) knows what is Service Oriented Architecture? #SOA #SoftwareEngineering #API
Share on X

Final Note (from the author) on OpenAI answering to What is Service Oriented Architecture

If we exclude the picture, the opening text and this closing text, the content is entirely generated by Chat.OpenAI using ChatGPT. The content of the answer looks sound and consistent and, from time to time, a bit redundant. In addition, the information are clearly correct and touch relevant sub-topics. Finally, strictly talking of the deepness of the content, it is sufficiently informative for a non expert but a bit useless for a domain expert as it can be classified as “a good introduction”. Is short? Does OpenAI knows what is Service Oriented Architecture? Well… the answer looks correct

If you are curious and you want to know more, at this link you can find another example of AI assisted writing

The post OpenAI: What is Service Oriented Architecture (SOA) ? appeared first on Francesco Lelli.

Abstract:
The growing synergy between Web Services and Grid or cloud based technologies is enabling profound, dynamic interactions between applications dispersed in geographic, institutional, and conceptual space. Such deep interoperability requires the simplicity, robustness, and extensibility for which XML has been conceived, making it a natural lingua franca for the network. Along with these advantages, there is a degree of inefficiency that may limit the applicability of XML.
In this paper, we investigate the limitations of XML for high-performance and high-interactive distributed computing. Our experimental results clearly show that focusing on parsers, that are routinely used for desterilize XML messages exchanged in these system, we can improve the performance of a generic the end to end web services based solution. Then we present a new parser, the Cache Parser, which uses a cache to reduce the parsing time by reusing information related to previously parsed documents/messages similar to the one under examination. Finally, we will show how our fast parser can improve the global throughput of any application based on Web or Grid or Cloud Services, or also RPC calls in general.

Key words: Web Service, Cloud Services, 3 tier architecture, SOA, RPC, Service Oriented Architecture

The may Web Services fully solve the “global enterprise integration” problem, but the proposed solution seems to exhibit a poor performance, and we believe that this could pose serious limitations on their actual applicability, as the number of commercial users will increase.
As shown in paragraph 2 we also believe that one of the limitations in using a full WS approach for implementing complex and highly interactive systems, comes from the large de-marshalling costs incurred on the receiver sides.
To solve this problem, we have designed a new parser: the Cache Parser. It is able to “well and quickly” retrieve information from XML documents, using previous knowledge about the document syntactic tree. In particular, our Cache Parser, which is used to de-marshal XML messages on the receiver side:

• Uses a checksum to detect if a new document is “well formatted”, and to know if it shares the syntactic tree with an already parsed one.
• Takes advantage of this XML-Document syntactic tree stored in a cache.
• It is based on a strict collaboration between sender and receiver.
• Consistently reduces the receiver parse time, without increasing the sender document creation time.

This algorithm is 25 time faster than a pull parser and if used in a WS scenario it can allow a 1.54 performance improvement factor in term of request handled per second. Finally it can be applied in any scenario where the client and the server decide to cooperate.

Full article available at this link.

Your help in sharing the idea is very welcome!

Improving the #performance of XML based technologies by caching and reusing #Information. #Webseries #RealTime #CloudComputing #API #APIs #programming #softwareengineering
Share on X

Cite this paper as:

F. Lelli, G. Maron, and S. Orlando. Improving the Performance of XML Based Technologies by Caching and Reusing Information.. IEEE International Conference on Web Services (ICWS), Chicago, September 2006.

• Full list of Articles
• Full list of Journal Publications

The post Improving the performance of XML based technologies by caching and reusing information appeared first on Francesco Lelli.

Service Encapsulation is often used to hide the internal representation, or state, of an object from the outside. In this way, we can present to the outside world a cleaner, simpler, and more coherent view of the internal systems. Many services which were not initially planned for a Service Oriented Architecture (SOA) may get encapsulated or become a part of a SOA in this way.

In the example of ACME Social and University of Nowhere, both the parties agreed on exchanging information in order to improve the existing geolocation service of ACME Social. In particular, ACME Social would like to receive the following information from the University of Nowhere:

• Retrieve a list of unique IDs of the students
• Retrieve the email addresse(s) of each student
• Get the class that the student is supposed to follow
• Retrieving the exact coordinates of the location of a given student according to the University of Nowhere.

Service Encapsulation: Can we design it as a stateless service?

Probably yes, even though students and their respective locations will change. From the point of view of the methods, we can expect that their behavior will not change over time. A possible UML diagram that describes the interface of the service could be as follows:

The class represents all the functionalities requested by ACME Social in 4 methods. It does not have attributes and this approach will keep the design simple. IDs, emails, as well as geocoordinates will be shared as Strings in order to use one of the basic types of a service.

In the case we will decide to implement a WS-I compliant service, we can assume that the calls of the methods can fail and may trigger exceptions on the service consumer’s side.

What about the concerns of ACME Social and the documentation of the service?

As the service represents the entry point of the systems of the university of Nowhere, we need to carefully balance the complexity of the interface that we need to design. On the one hand, it must be able to mask all the idiosyncrasies of the IT of the university in order to facilitate its consumption by ACME Social. On the other hand it must be able to deliver everything that is needed and agreed. The figure below shows how this interface sits at the intersection points of two different worlds with different needs and goals:

ACME Social, i.e. the client of the service needs a clear answer to the following questions:

• What does the service do? Answering to this question will require a proper documentation of the methods. The name may be intuitive, but some of its behavior may not. Therefore, it needs to be carefully documented.
• How can we use the service? The best way to answer this question is with an example of use. ACME social may use different languages so the example(s) need to be written in Java and Python (for example) and the code must be well documented (see these best practices).
• Where can we locate the service? The URL of the service, together with the way to get the authorization of use, should be part of the documentation. In addition, the service should be part of an UDDI registry as well.

ACME Social is not at all interested in:

• How to represent internally the request received from ACME social
• How to implement the service
• Where to host the server needed for running the service
• How to publish the service in the Internet
• How to keep it running

These aspects are of fundamental importance for the University of Nowhere. However, these concerns should not be shared with the consumers of the service.

A #service Encapsulation example using a location service. #servicedesign #programming
Share on X

The post A Service Encapsulation Example Using a Location Service appeared first on Francesco Lelli.

National Grid Initiatives or Infrastructures (NGIs) are organisations set up by individual countries to manage the computing resources they provide to the European e-Infrastructure (EGI). NGIs are EGI’s main stakeholders, together with CERN and EMBL, two European Intergovernmental Research Organisations (EIROs).
Each NGIs contributes a number of sites to the grid infrastructure. NGIs are responsible for the maintenance and running of the sites they operate.

European Grid Initiative

In particular SwiNG’s mission is to:

• Ensure competitiveness of Swiss science, education and industry by creating value through resource sharing.
• Establish and coordinate a sustainable Swiss Grid infrastructure as a dynamic network of resources across different locations and administrative domains.
• Provide a platform for interdisciplinary collaboration to leverage the Swiss Grid activities, supporting end-users, researchers, education centers, resource providers and industry.
• Represent the interests of the national Grid community towards other national and international bodies.

It offer the following services to researchers and research groups:

• Scientific applications
• Tools
• Seminars and Training
• Events / seminars
• Engagement with Funding Agencies

As well as connecting research and industry partners with IT providers across Switzerland.

Withing SwiNG developed a couple of use cases. The first was related to the integration of volunteering computing with the “classical” computational infrastructure. The second integrated high level malware (workflow) into the Grid user interface in order to achieve proper optimization of the processes. In particular we created a wrap interface around the NorduGrid UI in order to offer API access to the computational facility.

Links:

• SwiNG in the EGI Wiki
• Official Website of SwiNG

Some relevant publications includes:

• This is work in progress, just look at the full list of publication here

If this is not the research project that you are looking for, at this link you can see the full list of projects

The post Swiss National Grid Association (SwiNG) appeared first on Francesco Lelli.

Faced with an ever-increasing information flood in a complex and interconnected world, individual knowledge workers are in dire need for support in structuring their personal information space and maintaining fruitful communication and exchange within social networks across organizational boundaries. NEPOMUK develops technical support and stipulates and mobilizes community efforts to realize the Social Semantic Desktop.

This paradigm comprises a set of technical and methodological solutions for:

• supporting the knowledge life cycle via personal knowledge articulation support, embedding in personal work processes, and sharing, exchange and alignment across social networks
• cross-media and cross-application linking and browsing of information items based on standard semantic web data structures, together with un-intrusive metadata support
• knowledge communication within social networks and distributed search and storage to build, maintain, and employ inter-workspace relations in large scale distributed scenarios.

Links:

• Nepomuk in Wikipedia
• EU website of Nepomuk

Some relevant publications includes:

• This is work in progress, just look at the full list of publication here

If this is not what you are looking for, at this link you can see the full list of projects

The post Networked Environment for Personalized, Ontology-based Management of Unified Knowledge (NEPOMUK) appeared first on Francesco Lelli.

Abstract:
Current cloud service offerings, i.e., Software-as-a-service (SaaS), Platform-as-a-service (PaaS) and Infrastructure-as-a-service (IaaS) offerings are often provided as monolithic, one-size-fits-all solutions and give little or no room for customization. This limits the ability of Service-based Application (SBA) developers to configure and syndicate offerings from multiple SaaS, PaaS, and IaaS providers to address their application requirements. Furthermore, combining different independent cloud services necessitates a uniform description format that facilitates the design, customization, and composition. Cloud Blueprinting is a novel approach that allows SBA developers to easily design, configure and deploy virtual SBA payloads on virtual machines and resource pools on the cloud. We propose the Blueprint concept as a uniform abstract description for cloud service offerings that may cross different cloud computing layers, i.e., SaaS, PaaS and IaaS. To support developers with the SBA design and development in the cloud, this paper introduces a formal Blueprint Template for unambiguously describing a blueprint, as well as a Blueprint Lifecycle that guides developers through the manipulation, composition and deployment of different blueprints for an SBA. Finally, the empirical evaluation of the blueprinting approach within an EC’s FP7 project is reported and an associated blueprint prototype implementation is presented.

Key words: Cloud Computing, Service-based Application (SBA), Service-oriented Architecture (SOA), Cloud Development Methodology

Cloud blueprinting is a novel approach for engineering Service-based Applications (SBAs). Following this approach, developers can create sophisticated SBAs from applications, platforms and infrastructures offered by different providers in the cloud to achieve end-to-end business requirements. This paper has proposed the Blueprintconcept as a uniform, abstract description of cross-layer cloud service offerings, a Blueprint Template for describing the blueprints, and a Blueprint Lifecycle that explains how blueprints are used during all the engineering phases of an SBA.Blueprint has been adopted as one of the main innovative concepts within the EC’s 4caaSt FP7 project. An industry cloud computing case study has been jointly defined by the 4caaSt community and has been used as a running example in this paper to demonstrate our blueprinting approach. The current blueprint XSD template and web-based blueprint prototype is integrated in a joint 4caaSt demonstration. In the future, our vision is to continuously improve the structure of our blueprint template to capture new requirements of SBA development in the cloud. In particular, we will look at other cross-cutting concerns in cloud computing such as security, reliability, pricing, licensing, etc., thanks to the extensible design of the blueprint template that allows adding more blueprint properties. More functionality will also be developed for our blueprint prototype towards a comprehensive blueprint tool that supports the entire SBA development lifecycle and targets the effect of changes in the blueprints and their composition.

Full article available at the following link:

Blueprinting Approach in Support of Cloud Computing https://www.mdpi.com/1999-5903/4/1/322

Your help in sharing the idea is very welcome!

Blueprinting Approach is a service oriented architecture best practice in Support of #CloudComputing . #Software #Engineering #service
Share on X

Cite this paper as:

Nguyen, D.K.; Lelli, F.; Papazoglou, M.P.; Van den Heuvel, W.-J. Blueprinting Approach in Support of Cloud Computing. Future Internet 2012, 4, 322-346.

• Full list of Articles
• Full list of Journal Publications

The post Blueprinting Approach in Support of Cloud Computing appeared first on Francesco Lelli.

Abstract (Engineering Cloud Applications): Recently, Cloud Computing has become an emerging research topic in response to the shift from product-oriented economy to service-oriented economy and the move from focusing on software/system development to addressing business-IT alignment. From the IT perspectives, there is a proliferation of methods for cloud application development. Such methods have clearly shown considerable shortcomings to provide an efficient solution to deal with major aspects related to cloud applications. One of these major aspects is the multi-tenancy of the Software-as-a-Service (SaaS) components used to compose Service-Based Applications (SBAs) on the cloud. Current SaaS offerings are often provided as monolithic one-size-fits-all solutions and give little or no opportunity for further customization. Monolithic SaaS offerings are more likely to show failure in meeting the business requirements of several consumers. In this paper, we analyze the state-of-the-art of the standardization, methodology, software and product support for SBA development on the cloud, identify some shortcomings, and point out the need of a novel approach for breaking down the monolithic stack of cloud service offerings and providing an effective and flexible solution for SBA designers to select, customize, and aggregate cloud service offerings coming from different providers.

Key words: Cloud Computing, Service-based Application (SBA), Service-oriented Architecture (SOA), Cloud Development Methodology

The paper provide a survey on existing support for Service-based Application (SBA) development on the cloud. As a summary, the survey has shown that the current cloud solutions are mainly fraught with shortcomings:

• They introduce a monolithic SaaS/PaaS/IaaS stack architecture where a one-size-fits-all mentality prevails. They do not allow SBA developers to mix and match functionalities and services from multiple application, platform and infrastructure providers and configure it dynamically to address their application needs.
• They introduce rigid service orchestration practices tied to a specific resource/infrastructure configuration for the cloud services at the application level.

The above points hamper the (re)-configuration and customization of cloud-based SBAs on demand to reflect evolving inter-organizational collaborations. There is clearly a need to mash up services from a variety of cloud providers to create what has been termed a cloud ecosystem. This type of integration supports the tailoring of SBAs to specific business needs using a mixture of SaaS, PaaS and IaaS. To deal with the identified shortcomings, we pointed out the need of an abstract and uniform representation for cloud service offerings across cloud computing layers, i.e. SaaS, PaaS, and IaaS. By using this uniform description for cloud service offerings, SBA developers can reuse, customize and combine distributed SaaSs for the SBAs in a seamless manner

Full article available at the following link:

http://www.scpe.org/index.php/scpe/article/view/794

PDF version at the following link:

On Engineering Cloud Applications – State of the Art, Shortcomings Analysis and Approach

Your help in sharing the idea is very welcome!

On #Engineering #CloudComputing Applications – State of the Art, Shortcomings Analysis and Approach
Share on X

Cite this paper as:

Taher, Y., Nguyen, D. K., Lelli, F., van den Heuvel, W. J. A. M., & Papazoglou, M. (2012). On engineering cloud applications: State of the art, shortcomings analysis, and approach. Scalable Computing: Practice and Experience, 13(3), 215-231.

• Full list of Articles
• Full list of Journal Publications

The post On Engineering Cloud Applications – State of the Art, Shortcomings Analysis and Approach appeared first on Francesco Lelli.

The project aims to extend the state of the art of computing grid technologies, by introducing the handling of real-time constraints and interactive response into the existing Grid middleware. Our goal is to build a widely distributed system that is able to remotely control and monitor complex instrumentation that ranges from a set of sensors used by geophysical stations monitoring the state of the earth to a network of small power generators to supply a national power grid. These new applications introduce, to the GRID, requirements that are strongly related to the availability of networks where network classes specifically tuned to address such real-time and highly interactive requests are implemented. One of the main objectives of the project is to verify, with real applications running on existing Grid testbeds over both national and international network infrastructures (e.g. GEANT) the feasibility of a Grid-based remote control of systems requiring real-time response. Data acquired from such instruments typically needs to be stored, analysed on-line to compare the data with a given model or to perform some predictions (e.g. meteorological applications). GRIDCC will integrate the proposed “grid of instruments”, or suitable emulators, into existing Grid infrastructures that will provide the computational and storage power needed for the applications. The reference architecture that is proposed here, along with the related software framework, introduces a new concept, that of a “Virtual Instrument Grid Service” (VlGS), which is a service enabling access, through the Grid, to any instrument by providing an appropriate interface on the instrument side. The architecture combines special-purpose services like virtual control rooms, diagnostic and problem-solving services, data-mining services and tele-presence, which are used to support various instruments with existing grid resources like computational farms and databases.

Links:

• EU website of GridCC

If this is not what you are looking for, at this link you can see the full list of projects

The post Grid Enabled Remote Instrumentation with Distributed Control and Computation (GridCC) appeared first on Francesco Lelli.