This is a discussion point I'd like to raise, regarding how folks position the administration of MQ. Is it seen as a resource/utility function, like networks, databases, or servers, or is it rather identified as being closely linked to applications, and therefore, integrated closely in application development/sustainment? Or rather, might it only be kept separate from applications, if there is enough demand for MQ admin activities in multiple projects/applications, so as to not be too aligned with anyone application?
I have seen it both ways.
The larger the organization, the demand for MQ services will be high and hence a separate team of MQ admins. They maintain the MQ network as well as work on various projects that involve MQ.
In small companies MQ is aligned with either infrastructure administration team or application support team especially the middleware support team.
From my point of view, MQ looks like a platform which integrate services and applications. It works like a factory that package the message, store them in a queue system and send them out to the services and applications, instead of connecting and directly exchanging information with each other.
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
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.
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.
I have to integrate my web service with IBM Enterprise Service Bus (ESB).
I think that there should not be any mediation because this service has only one location
and do not have to change requests.
Is it true? Can ESB administrator simply connect web service to the bus?
If it is necessary to write mediation code:
are there any free tutorials and tools to create such mediation
or I have to buy WebSphere Integration Developer (WID)?
This mediation should be simple and I don't want to spend money on something
used once.
Disclaimer: I'm a WebSphere ESB consultant for IBM.
The answer to your question depends on what you're expecting WebSphere ESB (WESB) to do for you. If you're simply trying to connect a Web Service consumer to a Web Service provider, you don't need need WESB to do that. However, typically folks want to use WESB because they either want to put some logic between the two (maybe transforming from one Web Service interface to another, for example), or because they might want to later. In either case, you'll need to create a mediation module to do that - there is no bus per se that you just connect services to.
In practice, you will need WebSphere Integration Developer (WID) to do that - it would be a lot of work to create the mediations manually, it's not documented, and it's not supported by IBM either. Your local IBM client team should be able to advise you, but these products are typically purchased together.
Hope that helps.
There are several ESB's in IBM's portfolio. The only one that don't really need WID is IBM WebSphere DataPower (I don't know enough about Lombardi to comment). If you have choice, I would use that to get your company started down this path.
In medium to large organizations what team or group typically support middle tier components like Oracle Application Servers?
(Unix Team, DBA Team, Or Application Development/Support Team)
In a client server application design the delineation of ownership between the server and the client is very clear. In the client server case the Unix Administrators manage the servers and the development support team manage and support the clients. (and the DBA's support/manage the database)
Recently at our shop the lines have become blurred; the introduction of an Oracle application Server (OAS) has popped up;
OAS seems to require a very unique set of skills but also show some similarity to the client server skills. (part Unix Admin, Part Dba, Part Application Developer/Client Support)
What have others done when confronted with this kind of challenge......??
Does a completely new team form that exclusively supports the Middle Tier??
Our It Group has 3 Unix Admins; 3 Application Support staff; 3 Dba's to give the perspective of the size of the teams....
There are a couple of different options, to my mind:
1) Roll it into the application development/support team as this is part of an application that isn't necessarily where only Admins are useful. There should be a separation between development and support to some extent as different tools may be used and some may have a stronger skill set for one over the other such as if one prefers investigating things then support may be a better fit.
2) Platform management team which is a separate group where there is a separation of the layers involved in the applications the company produces. I used to work for a company where the middle tier and back-end were managed by one team that was separate from the Applications group which seems appropriate if there is the plan of having that middle and back-end tiers become a platform for the company to pitch to other companies to use how they see fit in terms of making their own applications on top of this API.
I can see a logic in using either method depending on how one sees what the IT arm offers in a sense.
For large organizations, you generally eventually get to a point where there are dedicated teams to manage the middle tier web servers and application servers.
The problem for smaller organizations generally comes that when you first deploy the app servers, there may not be enough admin work to justify a separate person in that role, at which point you have to cobble together time from other teams. It's not particularly unusual for DBAs to manage the app server (particularly for Oracle DBAs managing Oracle Application Servers). It's also not particularly unusual for the Unix admins to manage the app server. Either way, though, some of the work will inevitably benefit from input from the other team.
IMHO there should be a single "Oracle" team, comprising DBA's, unix admins, application admins, and even a network person for big installations. There is really only one system, although it has multiple tiers and technologies. You do not want four teams all passing the buck round when a system fault occurs. Ask me how I know ;)