| Author |
Message
|
| lancelotlinc |
 Posted: Wed Dec 29, 2010 6:09 am Post subject: Open Source / Closed Source for WMB Msg Flows |
 |
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
In the WMB forum, Vitor and I began a dialogue on whether or not it is useful to have a UDN so that our team members could not see the impelementation details, make changes to the code, or possibly invalidate the functionality through unintended fallout.
I advocated using a Subflow rather than a UDN so that members of my team could see what was going on and the implementation would not be dependent on me. If I took a vacation, were hit by a bus, or otherwise unavailable, the closed source approach leaves the Production environment vulnerable.
Vitor has a different opinion. Vitor please post your viewpoint...
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Dec 29, 2010 6:21 am Post subject: Re: Open Source / Closed Source for WMB Msg Flows |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| lancelotlinc wrote: |
| If I...were hit by a bus |
And whom do you think would be driving it? 
| lancelotlinc wrote: |
| Vitor has a different opinion. Vitor please post your viewpoint... |
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 29, 2010 6:26 am Post subject: Re: Open Source / Closed Source for WMB Msg Flows |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Vitor has a different opinion. Vitor please post your viewpoint... |
I feel slightly misquoted.
| lancelotlinc wrote: |
| advocated using a Subflow rather than a UDN |
I pointed out that I'd been using sub flows for common functions for years, but gave a few examples where I felt the "black box" offered by a UDN would be useful.
I didn't advocate the wholesale use of UDN and/or the conversion of all sub flows into UDN. I certainly wouldn't advocate any practice that left a production system vunerable.
I didn't immediately flock to your "if it's not open source you're some kind of selfish dinosaur" view, and accept the possibility that I am indeed some kind of selfish dinosaur. We've discussed in previous posts that your world is much nicer than mine, and is filled with Build Engineers, automated development practices, far-sighted management and a raft of good things. I envy you your good fortune.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Dec 29, 2010 6:32 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
@Vitor
The example you pointed out for closed source was software with intellectual property rights. I would agree with you on this. Along with the closed source would come support (usually at additional cost).
My position is, when working within a team, I prefer to be open and collaborative; not closed to my team mates.
Do you feel that a closed solution is appropriate within a team, or not? If so, what would be a plausible example?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Dec 29, 2010 6:42 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Surely an illogical question? Within a team where the intellectual property belongs to the company employing that team, a closed solution would never be appropriate otherwise any changes would not be changes but re-writes.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 29, 2010 6:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
My position is, when working within a team, I prefer to be open and collaborative; not closed to my team mates.
Do you feel that a closed solution is appropriate within a team, or not? If so, what would be a plausible example? |
Define "team".
Consider a number of projects working with a single broker solution. Within this are a number of common functions, such as error handling. These shouldn't be changed at will for the needs of a single project "team".
Consider a flow which is complex, sensitive or has a tight SLA. You might not want every member of the "team" access to it.
Consider a flow which contains business sensitive processing. It might be an audit requirement that the code not be available except to given individuals or under particular controls.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Dec 29, 2010 6:59 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
My position is, when working within a team, I prefer to be open and collaborative; not closed to my team mates.
Do you feel that a closed solution is appropriate within a team, or not? If so, what would be a plausible example? |
Define "team". |
I would define it same as exerk.
| Vitor wrote: |
| Consider a number of projects working with a single broker solution. Within this are a number of common functions, such as error handling. These shouldn't be changed at will for the needs of a single project "team". |
Agree. My mechanism for managing this is policy rather than technology. ie. I would make it a public policy that management approval (my approval if I were the PM) is needed to make source changes.
| Vitor wrote: |
| Consider a flow which is complex, sensitive or has a tight SLA. You might not want every member of the "team" access to it. |
I would want all team members to be able to see what it is. Everyone should have at the very minimum read access.
| Vitor wrote: |
| Consider a flow which contains business sensitive processing. It might be an audit requirement that the code not be available except to given individuals or under particular controls. |
I have not seen such a flow within a development team. I know that DATA can be subject to PCI or SOXLY requirements; but I have never seen a message flow be that covert. One exception might be DoD.
exerk hit the nail on the head: team members are trustworthy. Each member deserves my trust. Otherwise, dismiss the untrustworthy members and replace them with people who do deserve this respect.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 29, 2010 7:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I see this debate as merely one about packaging.
Certainly there are cases where in larger companies, one team may produce a set of JAR files that are the only things handed to other teams for reuse. This is the same thing. The assumption is that the source for those jars is kept somewhere where it can be retrieved and worked on the team exceeds it's truck number.
In fact, Broker is usually used to ensure that most teams are black-boxes to other teams. There's a well defined interface to the software that the team builds and maintains that provides business function - and everyone else talks to that interface without knowing a darn thing about what's inside it.
The main reason to provide a compiled subflow as a UDN instead of as a plain .msgflow file is to ensure that everyone is using a known, labeled, UNMODIFIED version. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Dec 29, 2010 7:07 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
@mqjeff
Good points.
In the original discussion, the OP was trying to use a UDN and it was unclear what the purpose of the UDN was to be. What we really got out of the OP was insufficient to make a judgment on fitness to a particular purpose.
I would like to see some incremental improvements in Broker in the next few years that improves the packaging concept.
For instance, to modify a production system by putting a commonly used jar file in the shared-classes directory is a big headache with multiple layers of approval required. But including it in many EGs or Bars that need it is wasteful. Some deployment descriptor in a Bar should be able to auto-write a jar file contained in the Bar to the shared-classes directory at deploy time rather than having to get special permission from system admins.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Last edited by lancelotlinc on Wed Dec 29, 2010 7:09 am; edited 1 time in total |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Dec 29, 2010 7:08 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
I'll refine my post...
I agree with Vitor and mqjeff that elements must certainly be black-box, e.g. error handling routines, and with lancelotlinc that the rest be 'open'. It's about finding the balance that benefits the site.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 29, 2010 7:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| For instance, to modify a production system by putting a commonly used jar file in the shared-classes directory is a big headache with multiple layers of approval required. But including it in many EGs or Bars that need it is wasteful. Some deployment descriptor in a Bar should be able to auto-write a jar file contained in the Bar to the shared-classes directory at deploy time rather than having to get special permission from system admins. |
Wow, no.
No, no no no.
First of all, you should read about the JavaClassLoader configurable service in v7.
Secondly, all changes to production systems of any kind should require approval. And be logged. And be handled by deployment engineers, rather than developers or system admins.
That said, changes to shared-classes should not require multiple layers of approval - it should be part and parcel of the approval for making the deployment of the flow or flows that use those JARs. If the issue is that you need separate approvals to schedule the restart of the EG to allow it to load the jars at startup rather than at deploy - that's part of the reason you are using shared-classes in the first place. You can't avoid the need for restart and still get the advantages you're looking for. If the issue is the scope of the change - that everyone and their brother is using shared-classes... then you need to be making brokers that have their own workpath so that everyone is using one broker and their brother is using the other.
So the problem is more that you have the wrong deployment architecture for the solutions you've designed or that your approval process is not in sync with the needs of the organization properly (or at least with your own expectations of what it should be, which may be very very different!)
Or use a JavaClassLoader configurable service....  |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Dec 29, 2010 7:21 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
all changes to production systems of any kind should require approval. And be logged. And be handled by deployment engineers, rather than developers or system admins.
|
"Join the movement." NFL Play 60 ESB commercial. [insert youtube link here]
Let me get my notes back out for Build Engineer.
Ok, mqjeff, you have the floor. Tell me your job description for a Build Engineer.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 29, 2010 7:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I don't have a formal description.
Maybe the build engineer does all of the production deploys, maybe someone else does. I tend to think of a build engineer as someone who, you know, does the *builds* rather than the *deploys*. And I tend to think of a build engineer as being on the development rather than the admin side. But that's just me. <shrug/>
Perhaps the build engineer sets things up so that at a certain point, the production broker admins run a set of scripts that does a given deploy.
Perhaps the build engineer is a production broker admin. Dunno. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 29, 2010 7:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Agree. My mechanism for managing this is policy rather than technology. ie. I would make it a public policy that management approval (my approval if I were the PM) is needed to make source changes. |
How does this work when you have multiple PMs of equal rank with opposing (and occassionally) antagonistic viewpoints? Who all claim they "own" the source code?
I'll admit that I've perhaps taken a simplistic view to short circuit the politics; I've found that claiming the technology doesn't permit what they want to do easier on occassions than endless meetings.
| lancelotlinc wrote: |
| Vitor wrote: |
| Consider a flow which is complex, sensitive or has a tight SLA. You might not want every member of the "team" access to it. |
I would want all team members to be able to see what it is. Everyone should have at the very minimum read access. |
It's laudible, I'd be inclined to agree if there was no risk they'd then copy the code and start using their clone of it in their project with their "harmless" modifications.
| lancelotlinc wrote: |
| Vitor wrote: |
| Consider a flow which contains business sensitive processing. It might be an audit requirement that the code not be available except to given individuals or under particular controls. |
I have not seen such a flow within a development team. I know that DATA can be subject to PCI or SOXLY requirements; but I have never seen a message flow be that covert. One exception might be DoD. |
I've seen several. One of them is here.
| lancelotlinc wrote: |
| exerk hit the nail on the head: team members are trustworthy. Each member deserves my trust. Otherwise, dismiss the untrustworthy members and replace them with people who do deserve this respect. |
Please see my comments above regarding multiple PMs. I've known development teams who, if I'd had my way, would have been run out of the building at gunpoint. Or at least sat in a locked room until the phase "standards & controls apply to everyone even if your project is urgent" had been tattooed on each forehead.
You'll recall in one of our earlier discussions I talked about the training & quality of the development staff here. The C# guy they've got writing ESQL is a nice person without a trace of malice in him but his code has been proven untrustworthy because he just doesn't knwo what he's doing.
His PM is a different matter & I don't like turning my back on him. Office politics prevent any realistic solution .
I think, as is often the case, mqjeff has encapsulated it: we're talking about packaging.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 29, 2010 7:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Tell me your job description for a Build Engineer. |
Let's not start that again.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
