As a part of Service builder, I used Local services many time but I never used the Remote services. I Read about the Remote services from the following tutorial http://www.liferay.com/documentation/liferay-portal/6.1/development/-/ai/writing-the-remote-service-class-liferay-portal-6-1-dev-guide-en.
Still I didn't completely understood the purpose and where exactly we use these Remote services.
Can any one please explain where and why we use these remote services with simple real time example.
Local services can only be invoked by Liferay itself or by a Liferay application (e.g., by a Liferay portlet).
Remote services can be invoked by any application that can access your Liferay portal (e.g., over the internet).
So, for example, if you wanted to create a desktop or mobile application that can access Liferay's Bookmarks API, you'd need to invoke the Bookmarks remote services: http://localhost:8080/api/jsonws?contextName=bookmarks
Similarly, if you're creating a custom Liferay entity via Service Builder and you want to allow developers to create desktop or mobile clients that can interact with your entity (e.g., peform CRUD operations on your entity), then you need to create remote services.
Also it's a Liferay best practice and convention not to add permission checks to local services but only to remote services. Even if you don't anticipate that any non-Liferay applications will need to access your service, you should still consider creating remote services, if only to have a place to add permission checks. (Your remote service would include permission checking code and then would invoke local your local service. This is a common pattern in Liferay.)
For more information, see https://dev.liferay.com/develop/tutorials/-/knowledge_base/6-2/creating-remote-services.
Related
We have a WCF service which is hosted as a windows service with endpoints exposed over tcp. We need to migrate and host this on Azure Service fabric.
Would like to know which option within Service fabric would be better :
1. Stateless Service
2. Guest Executable
Also what are the steps to migrate the same.
Any pointers would be very useful.
Thanks
Avanti
Both solutions are suitable for you,
Guest Executable: You can migrate the service as-is without code changes, the only work required will be configure it in the application within SF, configuration like exposing the ports used by the service, define startup parameters, and required settings.
Stateless Service: You need to write the hosting of the service using SF application model, this will make changes to the original solution and might add changes to other dependencies, like for example if the service has 32bit dlls that does not run on 64bit.
I would recommend you start moving it as a Guest Executable, then move to Stateless Service in a later stage if you think you could make a better use of the platform features.
Regarding the guidance, you should be fine following the official documentation
Originally I was going to deploy a new system I am creating straight into Azure app services
However part of the system needs to get data from a third party via a dll which is registered with regsvr
Is there any way of doing this or avoiding this?
I think I have to create a virtual machine?
Paul
Due to the way the AppService Sandbox works, you cannot execute a regsvr operation.
See also:
SQLXML on Azure Web sites
General information about the sandbox:
https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
If you need this component, and want to avoid using virtual machines, you could try hosting the component as a web API inside a Azure Service Fabric cluster.
You can use OWIN to host the API, and it should be possible to register your dll via startup tasks.
Azure Service Fabric register COM component
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cloud-services-migration-worker-role-stateless-service#startup-tasks
Depending on your application, you could either host everything in the service fabric API, or host only the component as an API there, while providing the actual application inside as Azure AppService.
I am using liferay 6.2 on my system and I created a site and some portlets. Now I want to use the same site in mobile application. I searched on internet about mobile application that uses liferay services.
If I create a mobile application using liferay SDK. Is it possible to communicate with portlets which I created in desktop site.
I think you already know that LR 6.2 theme system is powered by bootstrap, so if the portlet of your markup is well written you can have a great view of the website in a mobile environment.
Speaking about a native mobile application, I think you are referring not to Liferay SDK, but to Liferay Mobile SDK.
In this case you will be able to access to your data by using API it provide to you. In fact, it wraps Liferay JSON web services.
An other option for you is to use any other kind of way to write your mobile application and to write inside also a client for accessing to Liferay JSON web services.
These options start from a basic concept: your portlet make used Liferay Service Layer to provide data access. In this case you just need to be sure that you declared your services also as "remote". If not just modify your service.xml file and relaunch the build-service.
If you not used LR service layer (and don't want to use it), just create a service layer (without tables) with one method for any your external calls.
If you not used (and won't use) Liferay service layer, you just need to create a RESTfull resource listener, and manage your remote calls in this way.
Last, don't forget that Liferay core services are already exposed as JSON services (so you can call it by Mobile SDK or with any client of your app)... by the way, starting from LR 6.2, there are some differences in accessing to these methods for guest users.
Hope it helps.
It is possible using Custom Remote Web services, Via Http You can call that service and communicate with portel using Liferay-mobile-SDK.
I have a mobile application that communicates with a REST based web-service. The web-service lives behind the firewall and talks to other systems. Currently this web-service requires a firewall port to be opened and a SSL cert generated for each installation. Mobile apps sends login credentials so web-services can login to custom back-end systems.
Recently a customer approached us asking how could we deploy this to 50 offices. As we don't want to say modify every firewall in every office, we're looking for options.. This is a list of possible solutions and my thoughts on each one:
Open firewall port and expose https webservice - This is our current
solution but we dont want to have to contact 50 network admins and explain why we need to do this.
VPN - Too heavy weight, complex and expensive, we only need access
to one server. Does not solve problem as firewall needs to be
modified.
Microsoft Azure Hybrid Connection Manager - This provides a managed
service where the Azure cloud will expose an end point. Azure will
also expect connections from a easy to install application that
lives behind the firewall. When a REST call is made to the cloud
end-point, the request is forward down socket that was initiated by
the software behind the firewall. This does what we want but as its
a Microsoft Solution there might impose other requirements that our
customers might not want. Currently the simple Hybrid Connection Manager is free. But for how long?
Jscape MFT Gateway - Similar to Azure but you can host their server anywhere. Not that expensive but is not opensource.
Netty - A async java library/toolkit where this type of application could easily be build. Client and server apps would need to be build and deployed. Dont know what we dont know about Netty.
MDM, AirWatch, BlackBerry BES - A MDM based solution would work expect that MDM's are centrally managed and are not often in every office where the backend services are located. Airwatch has an AppTunnle but im not sure about the specifics.
At this point the Microsoft and Jscape systems are possible solutions.
But most likely these solutions will require us to modify the mobile software to work around issues such as:
How does the user know which server to login to? A locator service
needs to be built such that, an email address is used to lookup their
office, or they need to select their office location from a list.
While the connection is SSL many company might want some additional protection since network login information will be send down the pipe.
How is load balancing and fail-over managed?
So, at this point i'm looking for more options. The best option would be a commercial product that offers some level of customization. Second, would like a well used open-source product that could be installed in Aws and customized.
Thanks
The best approach we found was to use the PUTTY API and setup a reverse proxy.
I have 2 web applications running in a web role and I only run single instance in the azure cloud. I would like to send and receive notifications between these 2 applications and any outsider should not have access to them.
That means, web service in both of them are out unless there is a
way to block outsiders from accessing a web service and only a
request from same system would succeed (May be vip and request ip
comparison would do, anything beyond that?).
File system watchers. Create a LocalStorage and use it in both
web apps and watch for files webappA and webappB in each other.
Use Azure Storage Queues.
MSMQ - not interested as its not supported in azure.
Could you please list other options available for me in azure web role
? Thanks in advance.
Note: Please avoid suggesting Internal Endpoint as I am running only a single instance with 2 web applications running in it.
You can set up "private" web services to listen on Internal endpoints. These are not accessible via the outside world. You could have a WebAppOne endpoint and WebAppTwo endpoint, both marked Internal. You then just query the role environment to discover the assigned port for each, and fire up your ServiceHost.
Or... you could use a queue to pass information, as long as:
You're ok with it being asynchronous
You're ok with messages being looked at "at least" once
You're ok with messages possibly being looked at out of order
Or... your apps could write information to an Azure table. No need to expose the table to the outside world.