I was looking at 12 factor app principle and saw this statement. I believe this statement states that the application must respond to any backing service such database or message broker and connect to them irrespective of what they are. How does it differ from traditional way of connecting? For eg: in my microservice , I was defined database and kafka broker as user provided service in cloud foundry. It just provides the connection parameters as vcap service variables. I still have code to connect to a database and kafka broker which are entirely different. What does this statement signify and how does it differ from what we do in non-cloud environment?
As stated in the below article:
https://12factor.net/backing-services
It states that :
A backing service is any service the app consumes over the network as part of its normal operation. Examples include datastores (such as MySQL or CouchDB), messaging/queueing systems (such as RabbitMQ or Beanstalkd), SMTP services for outbound email (such as Postfix), and caching systems (such as Memcached).
Microservice can connect to any backing service irrespective of the platform. In PCF, you are binding services to your microservices to connect. In other cloud environment, you can point to any backing service like AWS RDS or other services provided by the Platform.
The real difference is this :
Backing services like the database are traditionally managed by the same systems administrators as the app’s runtime deploy. In addition to these locally-managed services, the app may also have services provided and managed by third parties. Resources can be attached and detached to deploys at will. For example, if the app’s database is misbehaving due to a hardware issue, the app’s administrator might spin up a new database server restored from a recent backup. The current production database could be detached, and the new database attached – all without any code changes.
Related
To understand application architecture of composer rest server, I would like to understand following things.
Lets say, We have 4 peers of different organization. Now, What would be recommended approach in context of how we would be managing composer rest server.
1) Having one composer rest server per peer
2) Having one composer rest server per network and all peers will share composer rest server
3) Having one composer rest server per channel
firstly, just to confirm its called 'Hyperledger Composer' and 'Fabric Composer' was its old name from way back.
secondly, the answer is you would have one or more (think HA and availability) REST server instances per Composer business network, per Organisation that participates in that business network. It is also dependent on how each deploys REST server instances within their own infrastructure zones and somewhat dependent what user / user base will be authenticating to it (the likelihood is they would be authenticating their own users / REST clients to consume the REST server APIs - by whatever the chosen Passport strategy is, to authenticate in a multi-user environment - eg. LDAP OAuth2 etc. So, the REST server is not strictly tied to 'peers' per se. The peer information is defined in the connection profile info, in the business network card.
Composer business networks are deployed to a specific channel/ledger - and configured so in the business network cards that access it - the connection info specifies the channel, and the REST server instance is instantiated using an appropriate business network card.
See more on deploying your REST server here:
https://hyperledger.github.io/composer/integrating/deploying-the-rest-server.html
I have written a web application that is, typically, installed internally by customers (based on IIS/MSSQL server).
When a customer wants to provide external access to the application, we offer the following supported scenarios:
Publish the application in their DMZ (pretty standard deployment).
Use our own platform where we host the application in our own cloud infrastructure for them.
However, because I have more and more customers who misunderstand the requirements for publishing an internal application, I would like to add a "one click" way of providing that service.
My idea is to have a reverse proxy installed on the customer's web server that will connect to a cloud server we control. When the application starts, it will connect to our server, authenticate and maintain the connection. When a user wants to use the application, she will use an URL that directs it to our server (say https://myapp.mycompany.org/CustomerID or https://CustomerID.myapp.mycompany.org). The server will then lookup the list of connections from reverse proxy to find the one matching the customer ID and, if found, use that connection to relay the end user connection.
In essence, that is the same thing as what Azure Application proxy or TeamViewer do, only without the need for using Azure AD or TeamViewer.
Is there an existing framework I can use for building such a service ? I know I can write it on my own but that is quite a large development.
Got a question on IBM worklight server, thanks in advance for any comments on this subject.
Workflow:
User --> WorkLight Server --> Back-end Server
Scenario:
(1) Designed a mobile application with IBM worklight studio and deployed to worklight server.
(2) Must use worklight server for the first entry point (user authentication by LDAP via worklight server)
(3) This mobile application designed for downloading/uploading huge file size (10mb to 1gb) to the backend server behind the worklight server (refer to the workflow pls.)
Question(s):
(1) How session sharing can be done in between worklight server and the back-end server?
(2) If session sharing cannot be done, what's the safest way that mobile application download/upload the files to the back-end server given that the application and back-end server do not know its the same authenticated transaction by skipping worklight server?
(3) Did I misunderstood anything from the worklight server architecture? as far as I know worklight server is just kind of gateway and presentation layer for deploying mobile application by its framework. Heavy and complex computation logic should be handled by other backend server. As long as the worklight server network IO is wide enough for file transfer, it shouldn't be a problem for the worklight server act as a gateway in this case. For file transfer, it shouldn't be a burden for CPU for computation as it is just simply in and out from the user device to the backend server (worklight as a middle man).
Thank you and sorry for the lengthy question.
(1) How session sharing can be done in between worklight server and the back-end server?
Can I make the assumption that you will be using a worklight adapter in order to do your file transfers? In that case, a "session" between the adapter and the client will be created. To be a bit more specific, if I have a global variable stored in my adapter and I modify the variable based on the adapter call from the client, the state of the variable will be maintained upon subsequent requests, and the state of that variable will only be visible to the calling client. (Just a note, this is not always true in clustered environments, where the client may be calling adapters on separate worklight servers)
(2) If session sharing cannot be done, what's the safest way that mobile application download/upload the files to the back-end server given that the application and back-end server do not know its the same authenticated transaction by skipping worklight server?
As stated above, this can be achieved through adapters. Since adapters can be protected through authentication, it knows that the client is calling through the same authenticated transaction.
(3) Did I misunderstood anything from the worklight server architecture? as far as I know worklight server is just kind of gateway and presentation layer for deploying mobile application by its framework. Heavy and complex computation logic should be handled by other backend server. As long as the worklight server network IO is wide enough for file transfer, it shouldn't be a problem for the worklight server act as a gateway in this case. For file transfer, it shouldn't be a burden for CPU for computation as it is just simply in and out from the user device to the backend server (worklight as a middle man).
You hit the nail on the head. I haven't personally done any performance testing with a high amount of computations on the worklight server, but if it is being used simply as a passthrough then you should be fine. The worklight server has been known to be able to process a relatively high amount of concurrent adapter calls, so I believe you will be fine with your setup.
My application is distributed in multiple components (Web Applications).
The components are deployed on different glassfish servers.
Each Glassfish server is running on a different host.
I'm using the provided Security Realm for authentication.
Is there a way, that a user that is already authenticated on server x, doesn't need to authenticate again on server y (single-sign-on)?
I was looking into session replication. But if I understand clustering correctly, this means I would have to deploy the applications to the whole cluster (each instance). What I need is a physically distributed solution.
My reason for this setup is not load balancing or high availibility. This is a customer demand.
Any ideas or workarounds? Thanks!
This is an area where products like Oracle Access Manager come in for single-sign-on across multiple services. Oracle GlassFish Server (commercial product that includes GlassFish Server Control features) has a JSR 196 JAAS Provider for Oracle Access Manager. Check out the How-To document on setting it up.
Hope this helps.
Real application how can i use this app fabric ??
How can i put my business logic in this and this logic use in my windows azure application??
Thanks
The Azure AppFabric is a collection of services that allow to you leverage functionality traditionally provided on premise by infrasture components common to most networks. Currently, it consists of the following:
Azure AppFabric Service Bus - allows for connection of applications by providing a centralized relay point in the cloud. Applications create outbound connections to the rendezvous location, thus helping mitigate the challenges posed by security measures like firewall restrictions on in-bound connections and IP masking via NAT layers. This feature includes both 'real time' options as well a 'message buffer' dynamic to allow for more disconnected style communication.
Azure AppFabric Access Control Service - the "ACS" allows WIF applications to quickly access various identity providers and consume a single format of claims token. Used in conjunction with products like ADFS, it allows cloud hosted applications to authenticate against on-premise identity stores.
Azure AppFabric Cache Service - currently in public testing, this service brings the "Velocity" style functionality to applications. This provides them with a distributed cache system as well as a new session provider.
There's more features/services coming in 2011, but these are the hot ones currently. Regarding hosting your business logic, this is not something that is currently available in the Azure AppFabric. There's been mentions that we may eventually see the potential for placing applications "on the edge", meaning the servers that front the Azure AppFabric connections, but no ETA or even firm commitment that this will happen.
You can implement your business logic in Windows Azure, in a web or worker role depending if you need it to be synchronous or asynchronous.
You can surface the business logic using the service bus, though you could also implement your logic on premise and surface them via the service bus.
AppFabric is not a business logic layer. Think of AppFabric as cross-cuts, or glue between different parts of your application.
For now Business logic goes in components like a web or worker role, or an on premise app which you could expose on the internet using AppFabric Service Bus.
In a future release, AppFabric will release "Composite Apps" which in a nutshell seem to allow you to deploy managed WCF/WF workflow services, which makes for a better "business engine". But for now I think you could probably just use Workflow services in a web role.