AR Server as middleware? Huh, it cant handle larger xml than a few Kb. Storing XML in a database as tables and fields(like its done in AR System) are not the prefered method when talking about performance.
We all love the Malloc 300 errormessage when using webservices.... -- Jarl On 6/9/07, Chris Woyton <[EMAIL PROTECTED]> wrote:
Here's an opposing thought worth considering... Going back to the spirit of ARS being a Rapid Development Platform, why would BMC encourage development of the *same thing* that's out there already, regardless of who produced it? Many have lost sight of ARS as a development medium because it's been perceived as "just a Help Desk" for quite some time - and adding 50 more flavors of IT Request/Service Management won't do much to fix that perception. Requiring partners to produce products that are in non-competition is certainly part of the goal - money drives everything, as they say. However, it may also be construed as pushing the horizontal boundaries of the platform - pushing ISV's to take the product and move it into other arenas. There's obviously some interest in taking advantage of this facility, so instead of ITSM-esque applications, how about Fleet Management, Document Management, Middleware (Web Services + ARDBC + Workflow Engine is a dynamite combo for this), Financial Applications, etc. IMHO, those things add value to the platform - another ITSM product doesn't. A bigger pie provides revenue to BMC, no doubt, but it also gives the ISV a chance at more than crumbs. -Chris Woyton ATS, TuringSMI ps with regards to Robert's comment on CMDB, another thought comes to mind - I've often pondered using the OBJSTR sub-system as a development medium all on its own. Imagine this - you build a core set of Classes for a particular use, for example, Middleware/Data-Transfer. When a new Data Source becomes available, specialized a Sub-Class for it. Consumers of the data can then point to the specific Sub-Class or the root Parent Class (or at any point in the tree) depending on what data they need to use. Or, in a Request Management application, rather than providing different "Views" of an app to suit different groups, specialize a Sub-Class for that Group such that common data is shared, but specific data is segmented. Data sets could be used to support Tenancy in a model like this and the Recon Engine could facilitate inter-application integration (as well as exta-application). Maybe one of you hyper-motivated young guns can play with that idea (Reinfeldt already busts my chops for the 30 or so half-written emails to him I haven't had time to finish, so no way would I commit to prototyping that stuff..hehehe) :) -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Robert Molenda Sent: Thursday, June 07, 2007 9:27 PM To: [email protected] Subject: Re: Hypothetical Axton - you think too much outside the box :) Just like so many of us on this list :) :) We need more of this thinking again!!! I have actually been wondering about this for some time now, especially in the area of CMDB and 'Re-development' or 'Module Integration' so to say. The BMC CMDB while being 'OK' (not to take this completely off topic) is such an overhead that a much simpler and "customer fitting design" would be so much more performant to the ARSystem and other applications... (none the less cheaper and easier to maintain at times!) At what point will BMC begin to limit customizations? Imagine if the install of say Incident Management installed all objects in "Locked Mode"... I wonder at times if BMC forgot the first envisioned cause for ARS... Rapid Application Development, Flexible Workflow, ... Robert -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Thursday, June 07, 2007 6:28 PM To: [email protected] Subject: Re: Hypothetical I don't know what BMC's criteria are for approval, but I do know that there are already competing Service Management products out there, what's the point of a few more, unless someone thinks they've architected the code better than BMC does? Rick -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Thursday, June 07, 2007 4:24 PM To: [email protected] Subject: Re: Hypothetical hmmm... probably if you write it first and big brother likes it, you're SOL. Prepare to be bought or dropped (aka, prepare to be boarded)? I guess there's money to be made there, but geez, what a disappointment... Axton Grams On 6/7/07, patrick zandi <[EMAIL PROTECTED]> wrote: > ** > Woo, So first inventor win's ? as long as you pay and have it locked. > huh .. > Land Grab.. > > > On 6/7/07, Axton <[EMAIL PROTECTED]> wrote: > > > > Just a hypothetical question. > > > > Deployable applications, which include the ability to enforce user > > fixed/floating licenses, are available to partners/ISVs. > > > > Partners are not allowed to write competing products. > > > > Does this mean that companies/people attempting to write apps that > > are similar in nature to those that Remedy offers are in a catch22 > > situation? > > > > Axton Grams > > > > > ______________________________________________________________________ > _________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > ARSlist:"Where > the Answers Are" > > > > > > -- > Patrick Zandi __20060125_______________________This posting was > submitted with HTML in it___ ________________________________________________________________________ ____ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
