I am creating a system where a CEP engine looks like a good fit (I need detect time based patterns between events in a number of streams). The events detected need to be displayed to end users in a WPF application but not all users are entitled to see all events.
How is this typically handled when using a CEP engine? Do I need an additional service layer between the UI application and the CEP engine or can it be done in the CEP engine itself?
I'm not sure there's a "usual" answer to this question across all CEP engines. CEP engines are really not at all uniform in the services they provide.
You tagged this question with "streambase", so I can talk about that some. The StreamBase CEP runtime has support for user authentication when creating a client connection to a server to dequeue tuples from output streams. People typically hook this up to their local LDAP or AD server.
That said, there's no per-tuple dequeue authorization/entitlements enforcement mechanism in the StreamBase CEP runtime, at least as of the current release (7.3).
So, when StreamBase users want per-tuple entitlements enforcement, we usuallygude them toward building that in at the application layer, or use some other piece of available infrastructure. For example, rather than using native StreamBase Client connections, use an adapter to something like TIBCO EMS or IBM MQSeries and use the per topic/queue entitlements there to restrict access. Or as another example, have the StreamBase server send back a token to an authenticated user after connection, and use that token as a key for entitlements checks on the client side against LDAP using a dequeue interceptor.
Or, as you say, use your own services layer.
There's another example of "Poor Man's Entitlement Service" on the StreamBase Component Exchange. Search for "StreamBase Entitlements". This uses an in-memory or JDBC database to store users, roles, and entitlements and applies them on the server side with an efficient runtime entitlements checking mechanism. But there's no strict runtime restriction on the connections with this; it's just an example of implementing entitlements functionality with a nice UI. The clients voluntarily respect the restrictions, which is probably not what you were asking for.
Disclosure/Disclaimer: I am an employee of TIBCO Software, Inc. Opinions expressed here are my own and not TIBCO's.
Related
Can somehow explain me the difference in these products?
As far as I understand IBM ACE (AppConnect) gives you more or iPaas capabalities. It is allows you to make an API.
But from what I understand now is that API Connect is required for the actual API management. Proxy/policies etc.
Does anyone know you these products are licensed? Do you have to API connect for your APIs to be managed, governed etc?
This is not an exhaustive answer, but hopefully it'll point you in the right direction...
App Connect is for building integrations (flows) with various data sources. Could be databases, cloud services like GSuite or Salesforce, or even HTTP endpoints. Those flows could be triggered by events in one of those systems or by an API. You can also do things like turn a database schema into an API. You get the idea.
API Connect is for API governance, security, and socialization. In more concrete terms, it gives you tools for things like: adding authentication and/or authorization to all APIs, bundling APIs together, enforcing rate limits or quotas, providing a portal for sharing/selling your APIs with others, and so on.
You can create APIs using App Connect and stop there--it's usable/invokable without API Connect in the picture. API Connect provides enforcement policies to give you more flexibility in how you call that API and/or give others the ability to invoke the API. The two products complement each other, but an API management product would be required in order to manage and govern the APIs created by App Connect.
In terms of licensing, there are multiple available options. You can purchase the products as standalone software packages that you install and maintain yourself (see IBM Cloud Pak for Integration) or you can leverage the IBM-managed versions that IBM provides via IBM Cloud.
More information is available:
https://www.ibm.com/cloud/api-connect
https://www.ibm.com/cloud/app-connect
https://www.ibm.com/cloud/cloud-pak-for-integration
We are working on new requirement where we need to enable features based on contract with the client. It`s a Saas based software and support multi tenancy. The software by default have basic features enabled.
Basic features
Customer management
Basic billing/invoicing
Notification via email
Payments
Advance feature
Notification over SMS
Workflow
Etc
All the client serviced by same software (Obviously same deployment ) but data will be stored on different database schema.
How to handle basic, advanced, add on, and pro feature in this case?
We are using spring and hibernate.
AFAIK, you should be handling these internally in your application so that the features like notification, workflow are marked as application features and for each tenant, there will be a mapping between the tenant id and the feature so that the tenant has access only to the features that he is subscribed to.
So, when a tenant or his user logs in to the system, we identify the features and the contents that he can access and then show them to the user. This is called as a tenant licensing system.
Also, whenever a feature is consumed, your code should be recording the tenant that consumed that feature and by how much and when and there can be cost associated with units of usage measurements.
For more detailed discussion, please refer here
Though these are all explained in C#, there should be no hinderance in the conceptual understanding.
Hi we are thinking to implement a chat feature in our web app. (MVC 3 running on Azure) like Facebook or Gmail applications.
So the idea about this question is to have your technical architecture opinion about it.
How would you design it and which services you would use (worker role, queue, blob, Sql azure etc.).
Thanks
Instant Messaging is about asynchronous delivery of messages between multiple publishers and subscribers. This sounds like a perfect recipe for Azure Queues.
If the number of users who will use this feature is small, you can create a queue per recipient. Web-app would drop a message onto the recipient's queue and would check queue of its own user.
The positive about this approach is its simplicity The downside of this approach is the frequency of checking the queues per user and the cost associated with that.
If you have 10,000 users logged into IM and the app is checking their queue's once per second, that's 1penny per second. Which translates to ~$26k/month.
Windows Azure Service Bus provides Publish-Subscribe messaging with Topics that can be used for this scenario. You can see a Silverlight based Chat sample for this: http://servicebus.codeplex.com/SourceControl/changeset/view/9715
In addition you can see a Multi-tier app sample that shows using Service Bus Topics/Subscriptions from Web/Worker roles here: http://code.msdn.microsoft.com/windowsazure/Multi-Tier-application-6c033cad
I'm looking at having thousands of simultaneous connections from mobile phones to the server whereby anytime a user interacts with his cell phone, the data is sent and logged by the server. Also, anytime the server has new information for that user, the server can push that information without a browser refresh. I am wondering what is more stable and how you would build this?
A good real-time framework or infrastructure will have numerous APIs that should let you connect any device, no matter the technology, to the real-time server e.g. an iOS client library for iPhone and iPad, a JavaScript client library for numerous platforms including normal and mobile web, an Android compatible Java library and so on.
An interesting idea might be to choose which ever framework or real-time service suits your needs best and then using something like PhoneGap. But, as #rt2088 says, it depends if you need the notification app to be running as a service on the phone or as a standalone application.
The choice will also depend on whether you want to install, host, maintain and manage the scaling of your own real-time services or not. If not, there are a number of services out there who you could use so you can concentrate on building your application. If you do want to manage your own infrastructure then the Comet Maturity guide could be a good start. It's a little out of date but is still probably the best reference available.
the ability to push new content the
user based on his GPS location which
is "pinged" to our server. Based on
that, we deliver local content. What
frameworks are you talking about?
There are a number of real-time frameworks available at the moment. Some are hosted services and others require installation on your own hardware. The majority of them will come with a bunch of libraries in different technologies that make it easier to get up and running with them e.g. a JavaScript library that wraps the WebSocket object and also manages fallback for web browsers that don't support WebSockets.
I've just created a Real-Time Technologies Guide in which I've listed all the real-time technologies that I could think of and provided a bunch of tags associated with each.
wouldn't a javascript client library
cover all platforms if it is a web
appilcation?
If the application is a web application then yes, a JavaScript library would be all you need for the client application. The server side libraries that you require would depend on the real-time technology you choose.
Best solution to achieve this is to use the WebSocket communication. It is bidirectional asynchronous communication. Currently every browser supports this new standard and plenty of code snippets available. You just have to google it. There are many server and client side frameworks. choose the one best suits to your requirement.
The details of the WebSocket specification is available at -
Websocket specification
Do you need notification when user uses mobile browser of handset or the mobile handset itself (performing non-browser tasks)? Based on that, the framework to record user activity can be selected.
Can anyone give me some suggestions of a business scenarios where I can implement Java Messaging Services (JMS). The message can be sent either by queue(point-to-point) or topic (regular/durable subscription).
I will be using JMS (enabled through TIBCO Enterprise Messaging Services).
The business scenarios must involve atleast 3 IT systems/applications.
The classic use case is that of an Enterprise Service Bus with JMS as one of the available transports. In this case any number of IT systems can request a service invocation by placing a message on a well-known queue. The service provider listening on that queue dynamically determines the reply based on the JMS message's Reply-To fields. An example of a typical service is to inquire on or update customer demographic information. For purposes of inquiry, this definitely meets your requirement of involving at least 3 IT systems since pretty much everything dealing with customers would need to request this service.
Another example with broad application is logging. I have several customers using JMS messages to capture log records from across the network and forward them to a hub of central servers. Because it is JMS, the central hub can be highly available by using redundant servers and can scale horizontally to absorb seasonal loads.
For pub/sub an example I really liked is from an insurance company. They publish events on topics that are subscribed in various call centers, internal news tickers and to business partners. During a hurricane a few years back, these events included updates on landfall predictions and then after the storm passed the updates included locations of mobile claims adjusters and other support services. Pub/Sub was a great way to coordinate this massive mobilization of personnel and communicate back to ground support back at headquarters.
A more mundane pub/sub use case with broad applicability is systems management. Instrumented applications can publish their status and interested parties can receive those notifications. If something is acting weird in Production, the administrator can dynamically enable a subscription to a stream of diagnostics. Ordinarily with no subscribers, the diagnostics are not produced. However, without any interruption in the running system, simply by subscribing, diagnostic messages from the app are produced on demand.
It's actually harder to find examples where JMS messaging should not be used. The most common contraindications are truly synchronous messaging and a requirement to process messages in strict sequence. All JMS providers I'm aware of make allowances for these requirements to varying degrees and I'm aware of many deployments of systems with these requirements. However the ideal use cases for JMS messaging are truly asynchronous or pseudo-synchronous communication and messages that are atomic (that is to say messages have no dependencies on each other or to specific broker instances).
Here are some of the scenarios where we (food retailer) use messaging:
-connection systems between remote locations, in our case POS and inventory management systems in stores, and central ERP and forecast systems: master data changes are sent as XML messages from the central ERP system to the store systems. the store systems send changes in inventory, orders and sales to the central systems. This is completely PTP based, as the master data is unique for each store.
-usage as a central messaging backbone, either directly for systems that are capable to do messaging, or via some adapter functionality for databases, files, SAP systems or HTTP. Here the messaging system builds the base for our ESB.