I want to build an e-commerce application using JSF 2.0. I saw some examples (including the ones that come bundled with NetBeans). In those examples data was stored in some sort of database and was retrieved and queried using SQL. In those examples there was some sort of persistent object in the application. What I want to do is retrieve data from a Restful Web Service and so I will not use SQL at all. My question is: Do I need to include a model section (MVC pattern) in my application having persistent objects or should I just use beans which will directly connect with the web service? How does such an application generally work?
Your REST service would provide some data (JSON, XML), probably it would be handy to map these data to model classes on JSF application side. So in your JSF bean you would connect REST service, map data obtained from it to model classes and then call some bussines logic (that use model classes).
Obviously if the REST service returns single number or string there is no use to create another class just for the sake of architecture. Similarly if you bussiness logic is very simple, it is better to do everything in JSF managed bean class.
Related
I'm implementing Liferay 7 Service Builder which should not create database table and will call RESTful web services API. The web services to be invoked are custom and outside the Liferay; they have nothing to do with Liferay at all. The web services provide JSON format data to Service Builder. The Service Builder shall map it to its generated POJO class, and by using Jackson library would convert it back to JSON string. The portlet which would call the Service Builder (XxxServiceImpl) converts the JSON string to POJO object and render it on JSP.
I've search the world wide web to no avail. I hope anybody can help me.
Thank you.
By creating an empty entity, you'll get the services generated for you, though with no model classes - they'd be up to you to create yourself:
<service-builder package-path="com.example.foo">
<namespace>FOO</namespace>
<entity name="Foo" local-service="true" remote-service="true">
</entity>
</service-builder>
This will generate FooService, FooLocalService and the matching implementation classes, but no FooModel etc. - as this is something that you'd persist yourself anyways, you can (and should) build the model classes on your own. Liferay's ServiceBuilder would help you with the database persistence, but not with any other persistence.
I have a requirement to build a service endpoint to provide specific Sitecore 8.0 items (containing a given field value in a given branch of the content tree) to requesting mobile app clients. Encapsulating this logic (and perhaps some other calculations, etc) means the out-of-the-box API is not suitable.
I'd like to mimic an existing SOAP service exposed by another CMS, however I'm not above using a modified version of the RESTful itemWebApi if it confers greater code reusability or upgrade-safety.
Based on my research thusfar, it would appear my options are to build a custom handler, a completely separate asmx service (ala this approach), or to build a custom controller (similar to this custom Web API controller method).
Overriding or replacing the default pipeline processors for the itemWebApi does not seem viable, as I don't want to replace/modify the OOB API if I can avoid it.
Has anyone with the same type of requirement for Sitecore 8 found a better approach?
The approach I chose was to create a separate service "router" developed using the adapter pattern to be consumed by our mobile app clients. The router in turn calls the Sitecore ItemWebApi.
This fit my needs the best as it is completely decoupled from the Sitecore application and the client can be modified if necessary without impacting the endpoint.
It would also be worth looking to EntityService within Sitecore.Services.Client in Sitecore 8. Its a Web API based service but has more flexibility over the standard Sitecore Item Web API because you can define your model and the business logic yourself.
I can see you have mention my other blog post on adding a custom Web API controller. Enitity Service is different, it's a framework by Sitecore to achieve a standard way of creating custom web service for Sitecore.
I have written a blog post on EntityService. It has both a Javascript and standard rest based API to communicate with the service too.
http://mikerobbins.co.uk/2015/01/06/entityservice-sitecore-service-client/
Example Application here: https://github.com/sobek1985/EntityServiceDemo
And a few more posts on advanced features in Entity Service: http://mikerobbins.co.uk/category/sitecore/sitecore-service-client/
Trying to understand which of the better modules to use for my page's specific need. Services module is popular, but that seems more for providing service, where the Web Service Client is good for consuming a web service.
Here's the requirement:
On the web page, I've got a form whose fields (location, service areas, region, indicators, etc) are to be built dynamically and some are selectable based on other selections. (So choosing worldwide would make Hubzone 8A not appear.)
Another team built the SOAP web service, it sits on another server outside the web server. What they delivered to me is a URL to invoke, basically an XML file:
http://webserviceurl.com:52901/navigator/NavigatorServices?wsdl
(Obviously, I just can't use the Feeds module to import the XML manually, right? The whole point of the web service approach is that as the data in the web service is updated, the Process form will by dynamic.)
So I'm really at the beginning of this. Need some guidance.
Web Service Client and SOAP Client are the ones that should do the work for you.
If you find it difficult to understand how to use them, you can simply use nuSOAP library + some PHP code inside a module. This article provides a good tutorial about providing and consuming Web Services using nuSOAP.
PHP provides a SOAP API. So you can simply create a module using this API (and Drupal Form API).
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.
A friend wants to consume my ASP.NET MVC 2 application in a similar fashion as adding a web reference to it, accessing my functions, and using my model objects from a .Net web form from a separate website.
Any links out there that could explain how to "dress" my MVC responses so that his server to server consumption would be similar in experience to a web service?
I suggested using System.Net.WebClient to pull the results in to a variable then deserialize the JSON result, but maybe there's a better approach out there?
I'd suggest that you consider an API controller or a separate API application depending on the load you expect from people consuming data from your application. A separate API application will allow you to move it off your application servers if needed.
Rarely, will you find that the data that you would provide via an API is a one-to-one match with what your views need to be rendered. Behind the scenes you could abstract the data generation so that your API and your application controllers reuse the same code to get at the data, but the front-end of the API would understand how to negotiate security (from an API perspective) and present data that is easily consumed by a program. Moreover, you won't find that you're creating extra controllers and methods in your application just to provide some data that will never be used in a particular view.
You could use MVC or WCF for the API and JSON or XML as the payload format. If you use WCF, you get the benefit that he really can simply add a service reference to connect to it without you having to build a WSDL file/action.
From another's advice, Phil Haack added this to MVC 2 Futures. Add the DLL reference to the Application Start, and bingo. It uses a validator.