I am planning to build an application bundle that includes a mobile app, a website and an web service for other developers. Website has the first priority and mobil application has second.
For creating the mobile application ordinarily first i need to create the web service.
What is the way i should follow:
Create web service, than website and mobile application using it.
Create website, than create service and mobile application.
P.S: I will develop the service and website using Scala and Play! Framework
The optimal order will vary depending on priorities and how stable requirements are.
Usually during development, the understanding of the problem improves and the requirements change. This can happen particularly for the user interface. The first usability tests can lead to changes in the application's design and behavior.
A construction order that takes this into account would be:
Create an initial version of the website. Depending on the project this would include a short description of the project, a way to collect emails, and authentication features such as user registration and login.
Create the mobile application, mocking the service layer in the mobile application itself (i.e. using mock service proxy objects). The objective is to discover and stabilize user interface requirements. This process will clarify which services are needed, which operations these services must perform, and exactly which data these operations must receive and provide.
Implement the web service, based on the already stabilized requirements.
Complete the web site, including description of the application's features and benefits, and showing the application's content (e.g. screenshots, videos).
This order assumes the application's features are the main benefit of the project. If, on the other hand, the main value and complexity resides in the web service, and the application is just a thin, optional front-end over it, then it might be more appropriate to develop the web services first and then the application.
Related
I'm going to integrate a Moodle-based application into my website wherein all data/activities being posted in this Moodle-based application can be retrieved by my website and vice versa.
So, is the Moodle web service enough to access all the data in that Moodle application?
Yes, you should be able to use web services. No, not all data is accessible out-of-the-box.
Things you can do with the webservices:
Retrieve a list of users, courses, assignments
Upload files
Create notes
Send messages
Enrol to courses, groups, cohorts
Check grades
On your Moodle site turn on web services and go to /admin/webservice/documentation.php to get a full list of existing functions you can call.
You can see some examples of this implemented in the Moodle Mobile App:
User: http://docs.moodle.org/26/en/Mobile_app
Dev: http://docs.moodle.org/dev/Moodle_Mobile
If these satisfy your requirements then yes web services should be sufficient as they are.
If they do not then you can extend the web services as a local plugin to provide richer functionality, which would be limited by your development capacity rather than the system itself. To port all of the features of some modules to web services would be a significant undertaking, but there are some low-hanging fruit to get activity lists, forum discussions/posts, choice polls, etc.
Web services is a better approach than exposing the database to an external system as it allows you to utilise the core APIs to improve integrity.
I am not sure if I am comparing onion with a cabbage. But I am really confused with the portlet and a web service. I know that web service is making your software components in your application as a service to other applications but to me it is similar to a portlet responding to requests. I know that my understanding is making you(Portlet & SAAS developers) really upset. But I need some clarity on this.
Why cannot I use the request-response to portlet work similar to a web service?
If yes, what is the benefit I get in using a web service than a portlet?
If not, then what are portlets lacking to act as a web service?
I am a newbie in portlet development. Please dont curse me for this question.
Please suggest.
EDIT:
Most of the answer say that the portlet is a UI component. My customer has requested me to create a webservice in liferay. So is it to make a portlet as a web service? If yes, can you please provide a pointer or some code snippet?
Addressing your 'edit' specifically with regards to Liferay...
Liferay plugin projects can expose web services without too much work.
The Liferay Service Builder actually has facilities so you can create SOAP web services or JSON web services backed by tables in the Liferay database (and that make queries on existing database tables). In the case of JSON web services, the URL scheme generated is not RESTful (unfortunately), but it is well defined. With a bit of work on your part you can impose Liferay's permission system on web service calls as well.
Here's a reasonable starting point in the Liferay Developer's Guide:
See the links on that page to SOAP and JSON services.
Note that a 'portlet' is only one type of Liferay plugin. The web service facility is part of the service layer - which can be used by many plugin types. So there isn't necessarily a portlet involved in creating a web service in Liferay, you can make a web service that has no visual component associated with it.
Portlets are areas you create to add and display content. Portlets can be added to the left and right of the center body area and can contain myriad content ranging from news, events, calendars, RSS feeds, collections, plain text, and more. Also, you can set properties and policies for showing the portlets.
you want to use portlet when
You have content you want to have special focus, like news.
You need to specify the configuration data for an item. - i.e. number of entries to show.
You want to give the content editors a choice about when and where to display content.
You'd like to show it only to some groups or users.
On the other hand, web services:
Enables applications to expose their services
“progammatically”, i.e. the services can be invoked by programs
Enables software running on other computers (could be a desktop, mobile phone, PDA, etc.) to invoke operations exposed by Web applications
if you are trying to identify the main difference portal historically, the portlets have three layers architechture (client, middle tier, backend) this cause two weakness:
Different portal groups have no well established way of sharing services
Different technologies(Java, Perl, CORBA, EJB) in middle tier.
Different protocols(GRAM, IIOP,...)
Consequently, lots of redundancy, reinvention
Example: batch script generation
so Web services address the service sharing problem and reduces the redundancy.
source1 source2 source3
Portlets are meant to be a user interface component in a portal solution.
Web Services provide functionality to remotely interact with a system commonly using SOAP, REST, JMS or other related
They provide completely separate functions. The closest you get is the serveResource method in portlets. This functionality is used to serve various types of content from a portlet (such as a PDF document or an AJAX response) without the need to perform a full page request.
I currently develop a Web application that can be accessed over HTTP by an Android application or a Web browser. Both user agents basically provide the same functionalities. The Android app calls RESTful Web Services built with JAX-RS/Jersey, while Web pages are Facelets backed by JSF managed beans. I thus consider that there are two types of possible entry points to the Web app. The Web services do all the necessary work (accessing the resources, performing the database operations within DAOs, etc.) and most importantly, they must act on their own. Therefore, they constitute an independent layer.
In order to reuse the code, is it a good practice to call a Web service from a managed bean? Are their life cycle compatible?
The idea is to inject the Resource object into the managed bean (with CDI, but not necessarily) and to call its methods programmatically. The Web service would act as a business delegate (?) to the underlying services.
I widely googled the question but I didn't get a clear answer. I saw some pieces of code where the managed bean invokes a Web service with its URL, but since all my components are located in a single server app, I don't see what prevents me from linking them directly.
Subsidiary question on error handling: I am also annoyed with the idea of catching WebApplicationExceptions from the Web service into my managed bean for returning error messages back to the view (with FacesMessage). My father always told me that I should never catch runtime exceptions...So, is there a good way to handle them correctly?
In this case, you would be better off having the business logic out from the Web Service into "some central shared code". Then, then web services and the managed beans would call into the shared code.
I've put the term "some central shared code" in quotes, as what you use depends on your runtime environment. If you're using a JavaEE container like Glassfish or JBoss, this sounds like a perfect use of EJB and stateless session beans (which are designed to ensure the resources are managed well). You could also use Spring Beans as the shared code and centralize the logic that way.
It all depends on what you find more comfortable from a development and production sense. But both support injection, so both the Web Service and JSF Managed Beans could have the services injected as any other resource.
I am discovering webservices to impliment in my asp.net website. I visited many sites about Why use webservices and read many articles and found out that web services are good when you have something that is used frequently without loading your page.
I want to know some other example scenarios where web services are used.
Whether i can use web services in sending an order form to database or it is just for textbox box auto completion like google and etc.
Note: I know web services can be used from mobile, web or desktop applications.
But My question is When do i use web service in ASP.Net Application?
Some articles read so far
Codeplex
How to create a Web service using Visual Studio.net
w3school
On a Large Scale, Webservices are basically written, when you want to expose your database, your code, to some other user.
By exposing database, means, suppose, you have a large collection of all the pharmaceutical companies in a given region, storing details in db like, medicines they produce, their policies etc etc. And now, you want people to use it(possibly your paid Client, or simply free access to anyone). So what you going to do? Obviously broadcasting working connectionString to your database will be a disastrous move.
So what you do is to make few methods on top of your db i.e. CRUDE operations and expose these methods in your WebService i.e. someone can interact with these methods through a URL and fetch data or send data or both.
Most general use of WebServices is when you want your specific language built( say ASP.NET) logic and data to be accessible to people on different platforms.
Like mobile devices. Their frontEnd is built in fancy framework say like Titanium, but they fetch their data through a Sql Server using WebService built with Microsoft's WCF-Rest approach. They store their data, Synch their data through a WebService.
In a typical example, We had a very large shopping Website, and it was standalone i.e. we were the only users of its database, its data, its users. But then a requirement came, that certain Client wants to model it and make use of its existing data and logic, but they have got JAVA platform. Our entire system was built on ASP.NET 3.5. What to do then. We simply exposed our BAL through a ServiceLayer and gave it a fancy name ServiceBAL and lived (and earned) happily ever after.
These are some business oriented usage of Web Services.
Other simple, mere usage of webService like textBox auto completion, existing user check and so many, am sure, you must have found out during your scout.
Web services are reusable components you can use anywhere. for example suppose you are building order processing system where order can be place by mobile,web etc. So instead of creating a different function for different application or different platform it's better to create a web service of order processing system such as placeOrder or takeOrder web service and consume them on different applications.
Web Services are the means by which devices communicate over the World Wide Web.
Whether you use a mobile application, search engine or an enterprise system, the user piece of the application (the interface) resides on your device.
The data, and potentially the business rules, live on some other server on the network. How your interface communicates with the server piece is the role of Web Services.
I am very new to SharePoint development as well as SharePoint overall, so I apologize if this question seems like a no-brainer. I'm currently working on a SharePoint 2013 app and I'm wondering if it's possible to make a call out to some URL from within the SharePoint environment. Basically, I want to do this within an event receiver after some action is done to a list, and from there I want to make a call to some web service on my server to update my system. Using the REST API to poll the SharePoint server isn't a good option for this scenario since it won't scale very well.
When dealing with SharePoint 2013 apps you can access any resource using standardized APIs. In addition to REST SharePoint is offering the JS Client Object Model (CSOM).
In order to access data from another web than the current one, your app needs the permission to interact with the entire tenant.
If you're trying to query data from another host, you have to use JSONP because of the same origin policy.
if you are building an app using the "new App Model" for wiring up Remote Event Receivers it is possible to do anything, in which your app hosting framework/environment allows you to. If you are building a Classic App (Farm Solutions) you'll have access to perform operations which are allowable from the SharePoint servers directly...typically this is a lot as GAC deployed assemblies are granted full trust.
depending on what you are trying to do and what kind of resources you app will consume. I'd consider moving the dependancies away from SharePoint and building using the new App Model versus the older farm solutions. As you sound like you are starting in SharePoint, this gives you an opportunity to learn the new ways of doing development for SharePoint.
Lastly, you might consider building a workflow. Not sure what kind of app you are building but the new workflow capabilities include actions which can make RESTful calls. Potentially making your application a "no code" solution. Again it all really depends.