Trade-offs between Javascript SDK and Java pagelets from a service provider:
Service providers can ship a Javascript SDK to improve customization and programmability.
This does not pose any disruption to the existing services and models of the service provider. The SDK forms a separate layer over and on top of the services so that the business clients can choose to use the existing services or develop newer modes of content display using the JavaScript SDK. Powerful jQuery plugins and those exported by the service provider provide an immense combination to not only offload the customization of display but also enhance their integration into business workflows by replacing the existing interruption mechanisms with seamless business workflows.
There is a tradeoff in exporting a JavaScript SDK from the service provider instead of the service provider providing the client-side display. It has to rely on the clients to send the data securely without compromise. This is generally difficult to do without an all-in approach. However, the way the service provider may pass the data between its services is similar to how an external service might send the credentials to the service provider. Therefore, these services and the UI can also be hosted as single-origin for the JavaScript SDK while the service provider is exclusively API based.
The service Provider may also maintain its own user interface also powered by consuming the REST APIs and JavaScript SDK that it exports to its clients. In other words, the native user interface from the service provider as well as the self-customized interface from the client can exist side by side serving disjoint audience but maintained together as identity resources with the service provider.
Is it safe for the data to be sent over the https on several external network? This question is not really solved by the pagelet technology from the service provider. That said, it's true that data can be compromised when transferred from network to network. It's also true that procuring and processing data only with server-side technology reduces surface area and client involvement. However, pagelet technologies do not decentralize the development of the interface or the technologies that are used to deploy them. Moreover, with the adoption of cloud-based technologies, PaaS platform and containers, the client-side technologies may be freed up and made popular with their developer community. This lets the service provider develop more and more widgets and consolidate their best practice that others may not want to invest in. Furthermore, the identity provider may allow embrace partnership with vendors for different workflows and interfaces while consolidating the server-side APIs across data types.
Service providers can ship a Javascript SDK to improve customization and programmability.
This does not pose any disruption to the existing services and models of the service provider. The SDK forms a separate layer over and on top of the services so that the business clients can choose to use the existing services or develop newer modes of content display using the JavaScript SDK. Powerful jQuery plugins and those exported by the service provider provide an immense combination to not only offload the customization of display but also enhance their integration into business workflows by replacing the existing interruption mechanisms with seamless business workflows.
There is a tradeoff in exporting a JavaScript SDK from the service provider instead of the service provider providing the client-side display. It has to rely on the clients to send the data securely without compromise. This is generally difficult to do without an all-in approach. However, the way the service provider may pass the data between its services is similar to how an external service might send the credentials to the service provider. Therefore, these services and the UI can also be hosted as single-origin for the JavaScript SDK while the service provider is exclusively API based.
The service Provider may also maintain its own user interface also powered by consuming the REST APIs and JavaScript SDK that it exports to its clients. In other words, the native user interface from the service provider as well as the self-customized interface from the client can exist side by side serving disjoint audience but maintained together as identity resources with the service provider.
Is it safe for the data to be sent over the https on several external network? This question is not really solved by the pagelet technology from the service provider. That said, it's true that data can be compromised when transferred from network to network. It's also true that procuring and processing data only with server-side technology reduces surface area and client involvement. However, pagelet technologies do not decentralize the development of the interface or the technologies that are used to deploy them. Moreover, with the adoption of cloud-based technologies, PaaS platform and containers, the client-side technologies may be freed up and made popular with their developer community. This lets the service provider develop more and more widgets and consolidate their best practice that others may not want to invest in. Furthermore, the identity provider may allow embrace partnership with vendors for different workflows and interfaces while consolidating the server-side APIs across data types.
To list the advantages of JavaScript over JSP, we can include:
1) writing and debugging via browser is easier
2) no more compilation required
3) performance at par or even better with modular and refactored code
4) standard REST interface adoption
5) JsUnit is available for unit-testing so any existing language features are not lost with JavaScript.
Login screen enhancement: https://1drv.ms/w/s!
Login screen enhancement: https://1drv.ms/w/s!
No comments:
Post a Comment