Completely agree, Remedy would need enhancements to handle the complex nature of Web Service calls internally.but I agree with Richard that we don't want to be making WS calls internally..the overhead of that would be huge to have apps on the same server communicating with each other through MidTier..
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Wednesday, November 02, 2011 2:11 PM To: arslist@ARSLIST.ORG Subject: Re: Request for Comments ** I see limitations to the form approach that could be counter productive and/or limiting. xml (encapsulated in a web service) provides a richer set of capabilities to describe, store, and validate data. For instance, if one of the services to get a list of things, be it incidents, changes, tasks, etc., a single response could be returned as an xml document. Part of the request could be what to query on, the other part of the request could be what to return. The same for a service like "create an incident", it could handle any number of tasks, work info records, related items, etc. that are desired at create time. I don't see an easy or good way to achieve similar results using a form. Again, I would expect this to all be native within AR, a new type of workflow action, if apps are to consume services from one another. Some type of interface where, within the workflow, you could browse the available services (and why stop at just Remedy services) and select the appropriate one and view the definition of the service. This is not so far from the current web service implementation, but a richer set of capabilities would be required. Axton Grams On Wed, Nov 2, 2011 at 2:55 PM, Richard Baird <richard_ba...@sympatico.ca> wrote: That works for me Axton. If they wanted to get even fancier, they could implement it via the "Interface Form" model I described, and have the saving of the form (along with it's attached/embedded XML legal operations, exceptions, etc...) automatically create and publish the web service. That way every integration method/mechanism would have the same behaviour, because it would be based on the same source (the "Interface Form" for the specific interface) Cheers! Subject: Re: Request for Comments From: Axton <axton.gr...@gmail.com> Reply-To: arslist@ARSLIST.ORG Date: Wed, 2 Nov 2011 14:45:38 -0500 ** 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 <richard_ba...@sympatico.ca> 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 <lj.longw...@gmail.com> Reply-To: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of Richard Baird Sent: Wednesday, November 02, 2011 9:46 AM To: arslist@ARSLIST.ORG 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" <david_eas...@bmc.com> 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" _attend WWRUG12 www.wwrug.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" _attend WWRUG12 www.wwrug.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"
