| Author |
Message
|
| Esa |
 Posted: Thu Nov 28, 2013 3:08 am Post subject: private ESQL function |
 |
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
I would like to do something like this
| Code: |
BROKER SCHEMA foo
CREATE FUNCTION DoStuff(IN param CHAR)
RETURNS CHAR
BEGIN
RETURN DoApplicationSpecificStuff(ApplicationLabel, property);
CREATE FUNCTION DoApplicationSpecificStuff(IN application CHAR, IN property CHAR)
RETURNS CHAR
LANGUAGE JAVA
EXTERNAL NAME "foo.MyJavaClass.doApplicationSpecificStuff"
CLASSLOADER "SomeClassLoaderService";
END; |
This code is not valid, because statements are not allowed in function or procedure scope
In other words, I would like to prevent applications from calling DoApplicationSpecificStuff directly -- and accessing stuff that may belong to some other application.
I could put the functions into a module, but is there a way to access a module other than propagating to a node that is hosting it?
Or make a static java method aware of the Application that called it? |
|
| Back to top |
|
 |
| Omuch |
| Posted: Mon Dec 02, 2013 11:32 am Post subject: Re: private ESQL function |
|
|
Acolyte
Joined: 23 Mar 2012
Posts: 54
|
| Esa wrote: |
I would like to prevent applications from calling DoApplicationSpecificStuff directly -- and accessing stuff that may belong to some other application. |
I don't understand your architecture, do applications have directly access to your ESQL functions??
I suppose that the applications sends their data to some input - MQ or Soap . then you can design your service / flow how the application access the ESQL functions. |
|
| Back to top |
|
|
| Esa |
| Posted: Mon Dec 02, 2013 11:09 pm Post subject: Re: private ESQL function |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Omuch wrote: |
I don't understand your architecture, do applications have directly access to your ESQL functions?? |
Message flow applications. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Dec 03, 2013 12:39 am Post subject: Re: private ESQL function |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Esa wrote: |
I could put the functions into a module |
That's it. Make it private to an ESQL Module.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Dec 03, 2013 2:18 am Post subject: Re: private ESQL function |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| smdavies99 wrote: |
| Esa wrote: |
I could put the functions into a module |
That's it. Make it private to an ESQL Module. |
Just tell me how to call it from another module, without propagating... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 03, 2013 5:37 am Post subject: Re: private ESQL function |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Esa wrote: |
| smdavies99 wrote: |
| Esa wrote: |
I could put the functions into a module |
That's it. Make it private to an ESQL Module. |
Just tell me how to call it from another module, without propagating... |
You don't by definition it is private to that module.
What you are looking for is a Library... and yes that is callable from anywhere as long as the library project is referenced...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Dec 03, 2013 6:16 am Post subject: Re: private ESQL function |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| fjb_saper wrote: |
What you are looking for is a Library... and yes that is callable from anywhere as long as the library project is referenced...
|
Yes, exactly. The functions are in a library. But I want to make the other one not callable from anywhere else but from another function in the same library.
Something like putting the function in a private broker schema that is not visible outside the library.
If I made an RFE, which of the following alternatives would be the best (easiest to implement)?
- DECLARE PRIVATE FUNCTION ....
- DECLARE PRIVATE SCOPE ...
- PRIVATE BROKER SCHEMA ... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 03, 2013 11:20 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Now I get it better.
You are looking at something like scoping ESQL like java with modifiers like
public,private, protected, friendly (no modifier)...
Private only accessible from within the same file
Protected only accessible from within the same broker schema
friendly ?? only accessible from within the same library ??
There is no such thing as inheritance in ESQL... makes the scope of protected a little bit different... doesn't it?
Needs an RFE indeed.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mgk |
| Posted: Tue Dec 03, 2013 1:30 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
For this discussion the scope for ESQL is effectively the Application. Code in a schema deployed to application A cannot be seen by code in application B, unless it is also deployed to B. Modules do not help here as a Module maps to a node and you can only call code at the Module level from within the same node (Module).
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Dec 03, 2013 10:57 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
@mgk:
The problem is:
how to allow a function to be called indirectly via another function only, and never directly?
It's true that you cannot directly call code that has not been deployed with the application. But are you telling that you can indirectly call ESQL code that has been deployed outside the application? |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Dec 04, 2013 11:48 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Actually, it doesn't make sense to provide private access to an ESQL function, because even if you could prevent access to a private function in runtime, it would be very easy to copy the contents of the function into a non-private function.
This is, by the way, a good example of the But the requirement is... syndrome described by smdavies99. I have created a proprietary implementation for storing and using sensitive data on Message Broker platform (encrypted in UDSC properties), but noticed a theoretical security problem with it. So I thought I had a requirement to restrict access to ESQL functions.
But my real business requirement is still a way to securely store and use sensitive static configuration information.
I think fulfilling the requirement would require several enhancements:
1. A way of storing secret properties in a User Defined Configurable Services: mqsichangeproperties and Message Broker API enhancements for storing a secret property, for example so that it gets encrypted with the broker's public key and base64encoded. When listing the properties with mqsireportproperties or MB API, secret properties should always be shown encrypted. The encryption should be broker specific so that the encrypted values cannot be decrypted by copy-pasting to another broker.
2. An ESQL function and a JCN method for retrieving a UDCS property (there is an existing RFE for this)
3. AN ESQL function and a JCN method for retrieving a secret UDCS property in cleartext.
4. A way of isolating configurable services by defining a policy, for example a list of message broker Application names allowed to access the service in runtime and a way to assign a policy to a configurable service.
2 and 3 should be implemented in a context-aware fashion so that policies can be applied to the calls.
I think this is a bit too complex set of requirements to put in one single RFE. On the other hand they do not necessarily make enough sense if requested separately. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 05, 2013 6:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| I suspect you'll find GlobalCache can handle all those requirements. |
|
| Back to top |
|
|
| Esa |
| Posted: Fri Dec 06, 2013 5:09 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| mqjeff wrote: |
| I suspect you'll find GlobalCache can handle all those requirements. |
I have been under the impression that Global Cache is a cache.
It's news to me that it can be used as a persistent source of static configuration data.
But that may in fact be the case. I need to do some research on what kind of backend it uses for persisting the data and how to load it from outside of message broker runtime. And how to authorize access to it. |
|
| Back to top |
|
|
| Esa |
| Posted: Fri Dec 06, 2013 7:25 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Accessing Global Cache from a static java method that is to be called from ESQL seems a bit too challenging. Obviously you would need to write your own Extreme Scale client for that? Or is there a way to instantiate an MbGlobalMap object outside JCN context? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Dec 06, 2013 8:33 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Esa wrote: |
It's news to me that it can be used as a persistent source of static configuration data.
But that may in fact be the case. I need to do some research on what kind of backend it uses for persisting the data and how to load it from outside of message broker runtime. And how to authorize access to it. |
Afaik and for at least 8.0.0.3 it does not persist the data (unless I am totally wrong and my experiments with it are useless). The only persistence I see is if there is a cache spread over multiple brokers, one broker can be restarted and the cache data will be replicated into the new broker.
For the cache to persist the data over a complete system restart it really no longer becomes a cache but an 'in memory DB'.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
