Web Services

Hii guys. from starting today i going to working on presenting new web services post series. since this web services has been taking large part of the developer society it comes with lot of questions and many more complex scenarios. so if any one got any thing to ask just comment below so we can discuss them.

What is Web Service

The term Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organizations to communicate data without intimate knowledge of each other's IT systems behind the firewall.
Unlike traditional client/server models, such as a Web server/Web page system, Web services do not provide the user with a GUI. Web services instead share business logic, data and processes through a programmatic interface across a network. The applications interface, not the users. Developers can then add the Web service to a GUI (such as a Web page or an executable program) to offer specific functionality to users.
Web services allow different applications from different sources to communicate with each other without time-consuming custom coding, and because all communication is in XML, Web services are not tied to any one operating system or programming language. For example, Java can talk with Perl, Windows applications can talk with UNIX applications.

Types of Web Services

On the conceptual level, a service is a software component provided through a network-accessible endpoint. The service consumer and provider use messages to exchange invocation request and response information in the form of self-containing documents that make very few assumptions about the technological capabilities of the receiver.

On a technical level, web services can be implemented in various ways. The two types of web services discussed in this section can be distinguished as “big” web services and “RESTful” web services.

SOAP Web Services

Big web services use XML messages that follow the Simple Object Access Protocol (SOAP) standard, an XML language defining a message architecture and message formats. Such systems often contain a machine-readable description of the operations offered by the service, written in the Web Services Description Language (WSDL), an XML language for defining interfaces syntactically.

The SOAP message format and the WSDL interface definition language have gained widespread adoption. Many development tools, such as NetBeans IDE, can reduce the complexity of developing web service applications.

A SOAP-based design must include the following elements.

A formal contract must be established to describe the interface that the web service offers. WSDL can be used to describe the details of the contract, which may include messages, operations, bindings, and the location of the web service. You may also process SOAP messages in a JAX-WS service without publishing a WSDL.

The architecture must address complex nonfunctional requirements. Many web service specifications address such requirements and establish a common vocabulary for them. Examples include transactions, security, addressing, trust, coordination, and so on.

The architecture needs to handle asynchronous processing and invocation. In such cases, the infrastructure provided by standards, such as Web Services Reliable Messaging (WSRM), and APIs, such as JAX-WS, with their client-side asynchronous invocation support, can be leveraged out of the box.

RESTful Web Services

REST is well suited for basic, ad hoc integration scenarios. RESTful web services, often better integrated with HTTP than SOAP-based services are, do not require XML messages or WSDL service–API definitions.

Project Jersey is the production-ready reference implementation for the JAX-RS specification. Jersey implements support for the annotations defined in the JAX-RS specification, making it easy for developers to build RESTful web services with Java and the Java Virtual Machine (JVM).

Because RESTful web services use existing well-known W3C and Internet Engineering Task Force (IETF) standards (HTTP, XML, URI, MIME) and have a lightweight infrastructure that allows services to be built with minimal tooling, developing RESTful web services is inexpensive and thus has a very low barrier for adoption. You can use a development tool such as NetBeans IDE to further reduce the complexity of developing RESTful web services.

A RESTful design may be appropriate when the following conditions are met.

The web services are completely stateless. A good test is to consider whether the interaction can survive a restart of the server.

A caching infrastructure can be leveraged for performance. If the data that the web service returns is not dynamically generated and can be cached, the caching infrastructure that web servers and other intermediaries inherently provide can be leveraged to improve performance. However, the developer must take care because such caches are limited to the HTTP GET method for most servers.

The service producer and service consumer have a mutual understanding of the context and content being passed along. Because there is no formal way to describe the web services interface, both parties must agree out of band on the schemas that describe the data being exchanged and on ways to process it meaningfully. In the real world, most commercial applications that expose services as RESTful implementations also distribute so-called value-added toolkits that describe the interfaces to developers in popular programming languages.

Bandwidth is particularly important and needs to be limited. REST is particularly useful for limited-profile devices, such as PDAs and mobile phones, for which the overhead of headers and additional layers of SOAP elements on the XML payload must be restricted.

Web service delivery or aggregation into existing web sites can be enabled easily with a RESTful style. Developers can use such technologies as JAX-RS and Asynchronous JavaScript with XML (AJAX) and such toolkits as Direct Web Remoting (DWR) to consume the services in their web applications. Rather than starting from scratch, services can be exposed with XML and consumed by HTML pages without significantly refactoring the existing web site architecture. Existing developers will be more productive because they are adding to something they are already familiar with rather than having to start from scratch with new technology.

GSOC 2015 Proposal : Tooling Support for OSGI Remote Services

Abstract – 

There are main two tasks will be consist with this project the objective of both two tasks will be, provide resources to the people who are interested towards the ecf to get to understand the remote services and make it easy to work with ecf on aspect of creating OSGi Remote Services.so as the first task there is my gsoc 2014 project which is provided 4 PDE templates for osgi remote services. So this PDE templates need to be prepared for inclusion in ECF proper. by adding them to ecf it make it easy for any new ecf user to understand how remote services work and what are things that need completed in oder to create OSGI remote service. Next would be creating eclipse wizard for creating OSGI services. The idea here would be for Eclipse users to use wizards to create OSGi services (and remote services) like they create projects, classes, packages. This may lead to start of creating eclipse based eclipse nature for Remote services.

Detailed Information – 

First task is to prepare that already developed PDE templates to include with ecf proper to get benefit to the users. Under bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=454062) there are few errors that need to be fixed before the inclusion so that errors will be corrected throughout the first time period of this project.so mainly befor the inlution this primary subtask will be done

1. Remove the errors that contain in the projects
2. Remove the errors in templates
3. Make them available on other projects not only pure OSGI projects 

Except for the fixing errors that showed in the bug, it will be added new template. This template would be related to the tutorial in the wiki (http://wiki.eclipse.org/Tutorial:_Raspberry_Pi_GPIO_with_OSGi_Services) . This tutorial shows how to use OSGi Services to access the Raspberry Pi GPIO. Adding this template into eclipse ecf as PDE template that may allow user to get to know about that how simple implementation of remote service can be done and by using raspberry pi. For adding templates mainly eclipse PDE will be used. 

Second task would be creating complete new wizard for creating osgi remote service wizard

When user create OSGI remote service 

Create a interface and include all the methods
Create an implementation for above interface
Register the service

Would be a basic three steps. Those first two steps can all be done via any existing tooling and/or frameworks...e.g. Eclipse, bndtools, declarative services, blueprint. Also in the PDE there is PDE project examples that shows two new PDE example templates but this depends upon PDE templates, so it's only usable with PDE. so there is no any other simple way to create complete generic OSGI remote service projects. 
This task focus on creating brand new wizard for simplifying the creation and registration of OSGi Remote Services with specific distribution providers and specifications. And the related documentation to the project.
This project will develop a new project category call “ECF OSGI Remote Service” in to eclipse following new project wizard.

Users will be able to select the category and able to create new OSGI remote service project using Wizard like shown below this wizard will allow user to specify the project name, working directory and execution environment settings.

Once we collect those information it will direct to next page that asks user about basic infrastructure of the remote service project.
In that wizard page it will gather information about service interfaces and their implementation classes and their packaging information. for this phase I think Eclipse JFace TableViewer in JFace framework would be suitable. Once user complete this wizard page those information will be added to MANIFEST.MF file in OSGI bundle.
After that wizard it will direct to another wizard page which ask about the dependencies of the OSGI project. in this phase it will add those dependencies to the MENFEST.MF of the OSGI project. Page may look like page shown below.

Once user have completed the page it will invoke another page.In that wizard page it will ask information about service registration 
In this phase it user can specify about their distribution provider and which of the interfaces of the service need to be exported all of the above information may gather into final service activator class which will register the service  as a remote service.The ability to create a OSGI remote service project via simplified automated way it will really appealing. particularly for the novice OSGI developers. Since additional Eclipse-based tooling were made available, it would be helpful to provide more tutorial-style documentation that uses that improved tooling .therefor creating Tooling support for OSGI Remote Services will be a benefit to developers.

Background – 

Last year also I have participated wit google summer of code with eclipse foundation and completed it success fully. so this year In the time leading up to the start of the GSoC program I am going to improve my knowledge about Eclipse Communication Framework . And my major goal is to get familiar with the OSGi Remote Services and Eclipse based Tooling .And thoroughly study the source code for existing Tooling supports for various eclipse projects. To improve my knowledge on above aspects I expect to read the documents regarding them and to have a discussion with the project mentors.

Deliverables –

 What do you expect to deliver? Be as specific as possible.

Schedule – 

  • March 31 - April 2
Preview the previous work and get familiar with it discuss about things that need to be change in pre created templates
  • April 3 – April 13
Fix the errors and complete them for deployment
  • April 14- April 28
Discuss about new templates and how it should be on the PDE template in public mailing list with all committers in the project 
  • April 29 – May 10
Prepare template for the raspberry pi tutorial and add them to project
  • May 10 – May 12
Test all the code in that project and send it to mentor for verify before inclusion
  • May 13- May 16
Include that project with ecf proper
  • May 17 - June 15
Study about eclipse JDT and EMF and its functionality towards a designed new wizards and views for the project
Discuss and design UI and its requirements for proposed wizard
Start coding
Start working  on GUI
  • June 16 - June 26
Midterm Evaluation
  • June 28 - July 24
Add required new classes and update existing classes which requires to add OSGi Remote service.
Further develop the GUI and integrate it with the code
Integrate all implemented parts eclipse single project.
  • July 25 - August 6
Test if added new functionality is working properly.
Do the required changes to fix the bugs.
  • August  7 - August 14
  • August  14 - August 28
Finish project and Submit Deliverable

Expectations –

 What do you expect from your mentor? What help are you going to need? (e.g. will you need help learning about Eclipse plug-in development, or about any specific features of Eclipse that you'll need to leverage as part of your project?).

Contact Information –

Email : gmsakith@gmail.com
Phone number : +94776070991
Time-Zone : GMT+5:30
I’m Sakith Indula. I am a fourth  year  undergraduate in Department of Computing and information System in Sabaragamuwa University Of Srilanka .last year also I have participated with Google summer of code with eclipse ECF and I worked on creating PDE templates for OSGI remote services and successfully completed it on last august. I have much experience in java and developing various applications, basically I am doing programming with Java therefor I have a advance knowledge with programming in Java also I have experience with programming in  C,C++ and XML.I have implemented many projects in java including a one which spanned for four months .Also I was a project team member of the following  projects.

Track M : Bus Tracking System For National Trans Port Board [1]
Scloud : cloud base file sharing platform for any kind of mobile through Apache Stratos.

I am able to work 50 hours a week  for GSoC from April to August ( 6 hours on weekdays and 10 hours on weekends).So I’m confident enough to take up this project as I have the required skill set for this project and I will deliver my best to make this project a success. ‘And I would like continue forward the work for ECF even after GSoC finishes and to complete the work all the way to deployment.

[1] https://www.facebook.com/projecttrackm