In short, three different fellowships are available:

1. Research Fellowship: For individuals without a PhD who are considering pursuing research studies.
2. PhD Scholarship: For those who wish to pursue a PhD in Switzerland for a period of 3+ years.
3. Post-Doc Scholarship: For individuals with a PhD who are looking to spend one year in Switzerland conducting postdoctoral research.

Please note that all fellowships are intended for individuals who have not previously spent time in Switzerland. Consequently, if you are awarded one of these fellowships, you will be ineligible to apply for the others in the future as you technicaly already have a Phd or Postdoc in Switzerland.

Let’s see each one of them in dettail:

Research Fellowship

Research Fellowships are 12-month programs aimed at highly qualified postgraduate researchers from all academic disciplines. Applicants must have obtained a master’s degree or equivalent by July 31, 2024, except for ETH Zurich applicants, who must meet this requirement by June 30, 2024. Candidates should be born after December 31, 1988. The application requires a support letter from an academic host professor at a Swiss university, including a brief CV (maximum 2 pages), explaining their willingness to supervise and support the research. This letter differs from the confidential recommendation letter also required. Additionally, applicants must submit a research proposal with a defined time frame. Notably, this fellowship is not available to those who already hold a PhD degree

PhD Scholarship

PhD Scholarships are designed for highly qualified PhD students from all academic disciplines, offering funding for 12 to 36 months, extendable in three 12-month increments based on academic progress. Applicants must have obtained a master’s degree or equivalent by July 31, 2024, except for ETH Zurich applicants, who must meet this requirement by June 30, 2024. Eligible candidates should be born after December 31, 1988. The application requires a support letter from an academic host professor at a Swiss university, including a brief CV (maximum 2 pages), detailing their commitment to supervise and support the PhD throughout its duration. If an assistant professor supports the application, a full professor must co-sign the letter. This support letter is distinct from the confidential recommendation letter also required. For PhD studies at a University of Applied Sciences, an additional support letter from a faculty member of the host research university is mandatory. The doctoral degree must be awarded by a research university. A detailed research proposal with a defined time frame is the centerpiece of the application and requires thorough attention.

Post-Doc Scholarship

Postdoctoral Scholarships are 12-month programs aimed at highly qualified early career scientists from all scientific fields. Eligible candidates must have completed their PhD between December 31, 2020, and July 31, 2024 (June 30, 2024, for ETH Zurich), and primarily for those who have not previously studied in Switzerland. The program does not fund sabbaticals. Applicants need a support letter from an academic host professor at a Swiss university, including a brief CV (maximum 2 pages), explaining their willingness to supervise the research. Former PhD mentors and co-directors for co-tutelle PhDs cannot be supervisors. A detailed research proposal with a timeframe is the centerpiece of the application. This scholarship is exclusively for full-time postdoctoral research in Switzerland, prohibiting fieldwork outside the country, and recipients are expected to reside in Switzerland during the grant period. For double doctorates, the date of the first degree is considered. The scholarship is not valid for mixed research conducted partly in Switzerland and partly in another country.

Where to find more Information

The official link of the scholarship contains all the relevant information and is the “GO TO” resources:

• https://www.sbfi.admin.ch/sbfi/en/home/education/scholarships-and-grants/swiss-government-excellence-scholarships.html

Additionally, each country has specific information and details regarding the application procedure, which can be found at the following link.

• https://www.sbfi.admin.ch/dam/sbfi/en/dokumente/2022/07/all-countries.pdf.download.pdf/2023_ESKAS_all_country_contacts_A_to_Z_for_application_documents.pdf

I recommend relying on the official information provided at the link above. The program itself warns about potential scams, and while there are numerous YouTube videos on the topic, some are generated by ChatGPT and others are, for lack of a better word, “dubious.” Here, I share videos from two YouTubers who, in my opinion, offer a reliable overview of the program. From Jama, part 1:

And part 2:

As well as from Aatiya:

My personal suggestions:

If you are interested in applying for a Phd or Postdoc in Switzerland, here are my personal suggestions:

1. Start Early (Paperwork): The application process is deliberately complex to filter out unmotivated candidates. The responsibility for managing the paperwork falls entirely on you, so begin early to ensure you have ample time to complete everything accurately.
2. Start Early (Connections in Switzerland): A critical aspect of the application is obtaining a support letter from a professor in Switzerland who is willing to endorse your candidacy and confirm that your proposal aligns with their and their institution’s research. Building these connections early is essential.
3. Start Early (Your Research Proposal): Develop a meaningful and well-written research proposal as soon as possible. Without a solid proposal, it will be challenging to secure support from a professor. You are solely responsible for writing this proposal. Once you have a polished version formatted according to the required templates, use it as your business card when reaching out to potential professors in Switzerland. Without this document, your communication is likely to be ignored or flagged as spam.

In other words, your commitment and the importance of contacting your potential supervisor as early as possible, armed with all the relevant information, cannot be overstated. This official video from the program provides additional valuable suggestions:

In addition, please note that each professor will not/cam not endorse more then one (or two) candidates per year. Therefore many of the request may simply be not answered.

Can I help you further for your Phd or Postdoc in Switzerland?

It really depends. For this specific grant you (the applicant) are really responsible for doing the heavy lifting as well as for dealing with the dettails. As for the rest, (i) if you believe that you have what it takes for this fellowship, (ii) you fulfill all the requirements, (iii) you have a nice idea to pursue and (iv) it is related to one of the following areas:

1. Internet of Things (IoT): Refers to the network of interconnected devices and objects that can communicate and share data. IoT enables smart homes, industrial automation, and more.
2. Extended Reality (XR): Encompasses virtual reality (VR), augmented reality (AR), and mixed reality (MR). XR technologies blend digital content with the real world, enhancing user experiences.
3. Human Behavioral Informatics: The study of human behavior using data analytics and computational methods. It involves understanding patterns, preferences, and decision-making based on digital interactions.
4. Computer Vision: A field of artificial intelligence that focuses on enabling machines to interpret visual information from images or videos. Applications include facial recognition, object detection, and medical imaging.
5. Language Processing: Also known as natural language processing (NLP), it involves teaching computers to understand and generate human language. NLP powers chatbots, language translation, and sentiment analysis.
6. Security and Privacy: Addresses safeguarding data, systems, and networks from unauthorized access or breaches. It includes encryption, authentication, and privacy-preserving techniques.
7. Big Data Processing: Deals with managing and analyzing large volumes of data. Technologies like Hadoop and Spark enable efficient processing of massive datasets.
8. Distributed Systems: Involves designing and managing systems that run on multiple interconnected computers. Examples include cloud computing, peer-to-peer networks, and distributed databases.
9. Serverless Computing: A cloud computing model where developers focus on writing code without managing servers. Serverless platforms automatically scale resources based on demand.
10. Digital Decision Making: The process of using data-driven insights and algorithms to make informed choices in various domains, such as business, healthcare, and finance.

You can consider dropping me a line! Are you still finishing your thesis instead? These guides may help!

Good Luck!

The post Phd or Postdoc in Switzerland for International Students: On Swiss Government Excellence Scholarships appeared first on Francesco Lelli.

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.

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.

Abstract: Current grid technologies offer unlimited computational power and storage capacity for scientific research and business activities in heterogeneous areas all over the world. Thanks to the grid, different virtual organisations can operate together in order to achieve common goals. However, concrete use cases demand a closer interaction between various types of instruments accessible from the grid on the one hand and the classical grid infrastructure, typically composed of Computing and Storage Elements, on the other. We cope with this open problem by proposing and realising the first release of the Instrument Element (IE), a new grid component that provides the computational/data grid with an abstraction of real instruments, and grid users with a more interactive interface to control them. In this paper we discuss in detail the implemented software architecture for this new component and we present concrete use cases where the IE has been successfully integrated.

Keywords: grid; instrument; Instrument Element; IE.

Authors: F. Lelli*, E. Frizziero, M. Gulmini, G. Maron, S. Orlando, A. Petrucci and S. Squizzato

We cope with this open problem by proposing and realizing the first release of the IE, a new grid component that provides the computational/data grid with an abstraction of real instruments, and grid users with a more interactive interface to control them. The main benefits of the proposed solution are: A highly modular and flexible solution: (a) The middleware deployment is organised into pluggable independent components. (b) The IE architecture is not tied to specific technologies or third-party software. (c) Multiple and independent I/O interfaces: Commands and Controls directed at Instruments, Fast Data Publishing, Data Movement to/from the grid.

• A highly modular and flexible solution: (a) The middleware deployment is organised into pluggable independent components. (b) The IE architecture is not tied to specific technologies or third-party software. (c) Multiple and independent I/O interfaces: Commands and Controls directed at Instruments, Fast Data Publishing, Data Movement to/from the grid.
• High scalability: (a) IE is portable to different platforms. (b) The target environment ranges from large farms to embedded devices.
• IE middleware aims to be used in production environments: Mature middleware has been used, whenever possible, to assure robustness and stability.
• Fine customisation of the IE: The IE is easily adaptable to diverse scenarios and needs.
• High level of abstraction in the IE interfaces: (a) Service Oriented Architecture (b) Adherence to standards: WS-I-compliant web services.
• EGEE (gLite) compatibility: Many grid facilities and tools can be reused, for instance GridFTP or SRM interface for data movement.

Get the Article at this link

A #SOA ( #service Oriented Architecture) approach for #integrate #InternetOfThings devices into a #CloudComputing infrastructure. #servicedesign
Share on X

Cite this paper as:
Lelli, F., Frizziero, E., Gulmini, M., Maron, G., Orlando, S., Petrucci, A., & Squizzato, S. (2007). The many faces of the integration of instruments and the grid. International Journal of Web and Grid Services, 3(3), 239. 

https://doi.org/10.1504/IJWGS.2007.014953

• Full list of Articles
• Full list of Journal Publications

The post The many faces of the integration of instruments and the grid 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.