I envisioned the interfaces implemented as web services, not as an API. A web service layer makes plugging into other things easier. One of the drivers for me starting this conversation is what I see many of the cloud providers offering and leveraging as their interfaces into and out of their applications. I have some exposure to the service oriented architecture as well, which plays into this paradigm nicely.
If, within Remedy, all the interfaces were exposed as web services and Remedy had a native way to consumer those web service based interfaces, it opens the door nicely for other things to operate at that level. Web services seem to be a common method of integration in the cloud space. SOA infrastructure deployments seem to be in their infancy, but I see them gaining traction, as long as they are capable of delivering on their value proposition. http://www.zapthink.com/2005/01/27/the-roi-of-soa/ The lifecycle around services is pretty well defined in this space as well. http://www.soablueprint.com/whitepapers/SOAPGPart3.pdf Axton Grams On Wed, Nov 2, 2011 at 2:20 PM, Richard Baird <[email protected]>wrote: > LJ, > > Having done lots of OO stuff as well as ARS over the years, I fully grasp > the concepts you're putting forward, however, I think the goal should be > "Interfaces", not necessarily "API Interfaces". For most apps built using > java or .net (or some other OO platform) as a base, I agree that tightly > defined api interfaces are the way to go. But ARS is somewhat different in > that the integration tools already in existence are widely used both within > the ITSM as well as many other third party or custom apps and they afford > great flexibility, which is one of the reasons ARS became so popular to > begin with. > > I don't see any reason that the capabilities we're talking about can't be > implemented via a "special" Interface Form type or layering versioning on > top of existing technology rather than requiring a call to a new > C/java/.net > api. Not everyone uses the api to do integration and for integration > between > apps both running on ARS platform (like the ITSM stuff), whether they are > BMC or someone else's, most will do it via workflow. > > If the "special" form approach is used (and fully documented), then an > integration using the interface would behave exactly the same if it is done > via workflow, C API, Java API, .net api, Perl, etc... Nothing to stop BMC > from doing full error checking, implementing exceptions, etc... for > activity > in the special form, and all the code would be visible so folks could > easily > understand what is happening when they touch the form (or encounter > problems), regardless of the mechanism used. They could even define the > legal operations, exceptions, etc... via xml so others could build their > own > Interface Forms for their own apps in a standard way. In addition, we'd be > able to see exactly how the ITSM apps do their integration between each > other without searching all over the place for the push/set field workflow, > since it would all (or at least the majority of the big/important > operations) be localized to the appropriate Interface Form. > > A potential drawback I see with this approach is that visual > studio/netbeans/eclipse/(insert your IDE here) might not see a specific > interface defined (i.e. we might still use setentry/getentry, which means > we'd have to actually read the interface spec....;). I suspect this is > exactly what some want, and again, there is nothing to stop BMC from adding > specific versioned interface api calls that interact with the appropriate > Interface Forms, but I think it would be a mistake to force the use of the > API, or any other particular mechanism when we don't have to do it to > achieve the goal, that being consistent, safe, published, versioned > interfaces between ITSM (or other) apps running on the ARS platform. > > Cheers! > > > Subject: Re: Request for Comments > From: LJ LongWing <[email protected]> > Reply-To: [email protected] > Date: Wed, 2 Nov 2011 10:17:47 -0600 > > > > Richard, > The point of API interfaces is actually reduced flexibility....not really > the point, but a byproduct. That reduced flexibility is actually a 'good' > thing though. Remedy, in the way that it works now has absolutely no > enforced structure. That lack of enforced structure allows you to > literally > 'do what you want'...which is extremely flexible, but extremely hard to > support and optimize. When you setup API interfaces to a system, you > harden > them and make them less flexible, but because of the defined contract > between the publisher and consumer you have extremely reliable results. > Because of this reliability you can guarantee results and ideally > scalability, and because of this contract you increase interoperability. > > Additionally, when you add to this contract, versions of the API...it in > theory allows you to upgrade from ITSM 10 to 11, but you aren't required to > upgrade your integrated app, because your integrated app can continue to > communicate with your ITSM Suite on the 10 version of the API and will > continue to function EXACTLY the same as it did when you were actually > running that version. > > That's the theory at least :D > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Richard Baird > Sent: Wednesday, November 02, 2011 9:46 AM > To: [email protected] > Subject: Re: Request for Comments > > Good to hear David! > > Here is a suggestion off the top of my head. Perhaps to help with one of > Axton's (and my) beefs, the concept of versioned interfaces, you could add > a > reserved field for forms used as "interfaces" to implement versioning. Then > add checking of this field into the workflow objects such that, workflow > only fires if the versions match, or something to that effect. Perhaps a > combination of fields, one to hold the version number and another to > indicate if it is specific to the version or applicable to lower versions > as > well or the lowest version number supported, etc? > > That would allow you to share workflow between interface versions where > appropriate, and even perhaps have workflow with the same name, but > different version and also to have workflow specific to a particular > version, thereby implementing something with similar results to > Inheritance. > > I'm not sure that additional API calls would need to be defined as that > could result in reduced flexibility, however the interfaces would need to > be > tightly documented. > > Cheers! > > Subject: Re: Request for Comments > From: "Easter, David" <[email protected]> > Date: Wed, 2 Nov 2011 10:00:02 -0500 > > ** > Just a quick comment - later versions of ITSM applications do have > interface > forms that are expected to be used to interact with the applications. > These > are used mainly by web service queries, but would be appropriate for any > external communication into the application. Those forms are the > recommended interaction point for external applications and insulate such > programs from the version-to-version changes in the underlying forms. > > > > Please do continue the discussion - the ideas being expressed can certainly > enhance and improve upon the architecture - but wanted to make sure folks > know that the apps are already headed in this direction. > > > > -David J. Easter > > Manager of Product Management, Remedy Platform > > BMC Software, Inc. > > > > The opinions, statements, and/or suggested courses of action expressed in > this E-mail do not necessarily reflect those of BMC Software, Inc. My > voluntary participation in this forum is not intended to convey a role as a > spokesperson, liaison or public relations representative for BMC Software, > Inc. > > > ____________________________________________________________________________ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > > > ____________________________________________________________________________ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
