Search Results

Search found 3 results on 1 pages for 'josek'.

Page 1/1 | 1 

• Use of Service Bus in a Pub-Sub Engine

  - by JoseK

  In one of our projects, we've built a Publisher - Subscriber Engine on Oracle Service Bus. The functionality being a series of events are published and subscribers (JMS queues) receive these whenever a new event is published. We are facing some technical issues now, performance-wise and hence an architectural review is underway. Now for my questions: Architecturally the ESB has to publish events into a DB and read from the DB which users wish to be notified, then push the event onto their respective queues. There is a high amount of DB interaction and the question is whether ESB should be having such high amount of interaction with the DB in the first place? Or should there have been some alternate component responsible for doing this. Alternately is there any non-DB approach in which we can store the events and subscribers? Where else can this application data be held within the ESB context?

  Read the article

• How to get out of supporting deadend sales pitches?

  - by JoseK

  As part of being a programmer, you often are asked to provide estimates/ make slideware / do technical demos for Sales teams to present to end-clients. Sometimes we go along for the 'technical' discussions or 'strategic capability planning' or some similar mumbo-jumbo. Sometimes, you kind of know which ones are totally going to fail and are not worth pursuing but the Sales guys present fake optimism and extract 'few more slides' out of you or the 'last conference call'. These don't lead to anywhere and are just a waste of time from other tasks for the week. My question is how do you get out of these situations without coming across as non-cooperative. Updated after Kate Gregory's answer: The problem is related to projects we know are doomed (from the technical feedback we've received) But Sales ain't convinced since they've just had a call higher up the management chain - so it's definitely going ahead !

  Read the article

• Is it okay to have many Abstract classes in your application?

  - by JoseK

  We initially wanted to implement a Strategy pattern with varying implementations of the methods in a commmon interface. These will get picked up at runtime based on user inputs. As it's turned out, we're having Abstract classes implementing 3 - 5 common methods and only one method left for a varying implementation i.e. the Strategy. Update: By many abstract classes I mean there are 6 different high level functionalities i.e. 6 packages , and each has it's Interface + AbstractImpl + (series of Actual Impl). Is this a bad design in any way? Any negative views in terms of later extensibility - I'm preparing for a code/design review with seniors.

  Read the article

1