Here are a few that I could see a web service being stored in: BMC.CORE:BMC_ApplicationService BMC.CORE:BMC_LogicalSystemComponent BMC.CORE:BMC_SystemResource
A bit of a stretch BMC.CORE:BMC_Document BMC.CORE:BMC_ProtocolEndpoint Jason On Fri, Apr 4, 2014 at 7:13 AM, Carl Wilson <[email protected]> wrote: > ** > > Hi, > As a CI, a Web Service can be a "Software Application" component (as that > is essentially what it is) and would have a one to many relationship like > any other Application CI. It therefore is a technical component of a > Service and should be in the model if needing to track changes to this > component that are service affecting. > > Cheers > Carl > > www.missingpiecessoftware.com > On 3 Apr 2014 08:05, "Pierson, Shawn" <[email protected]> > wrote: > >> ** >> >> I'm actually thinking that the aspect of the web service being a CI >> itself, the internal/external aspect could definitely be tracked via the >> Product Categories rather than adding an attribute. I also want to make >> sure that our I.T. folks don't think of web services as being related to >> the ITIL definition of services, or the CMDB line drawn between business >> and technical services, so I wouldn't track this as either of those. I >> just don't want to create a specific class for WSDLs or anything like that. >> >> >> >> The other attributes that Joe brought up might not be as vital for us >> depending on how we can leverage relationships. >> >> >> >> Thanks, >> >> >> >> *Shawn Pierson * >> >> Remedy Developer | Energy Transfer >> >> >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> [email protected]] *On Behalf Of *Rick Cook >> *Sent:* Thursday, April 03, 2014 9:55 AM >> *To:* [email protected] >> *Subject:* Re: Web Service CIs >> >> >> >> ** >> >> Why not deal with it via Categorization and SLAs? Those could drive >> increased priority, visibility, notifications, etc. That allows you to >> keep your Services generic and focused on something actually provided while >> still giving you control and reportability over the distinct combinations >> of data management is most concerned about. >> >> >> >> On Thu, Apr 3, 2014 at 7:39 AM, Joe D'Souza <[email protected]> wrote: >> >> ** >> >> That's what I figured was the drive behind it. >> >> >> >> While thinking along those lines, I also thought that it might be >> appropriate to identify one of the components of software applications as >> Application Clients, and classify application clients as thick or thin, the >> ports they use, whether they are internal or external, and whether it's a >> web application client or a web service, and include firewall load balancer >> attributes too as I have seen that a number of times changes to firewalls >> or load balancers often breaks a lot of these components.. >> >> >> >> Joe >> >> >> ------------------------------ >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> [email protected]] *On Behalf Of *Pierson, Shawn >> *Sent:* Thursday, April 03, 2014 10:24 AM >> >> >> *To:* [email protected] >> *Subject:* Re: Web Service CIs >> >> >> >> Tracking them as a component of an existing application (or technical >> service) is the direction I'm looking for. While our security group is the >> driving force behind it, we need to know how our applications are >> interfaced from a CMDB perspective as well. It would be nice to know who >> the consumers are of a web service so when you have a Change Request to >> rename or modify the structure of that web service, you can immediately see >> who will be impacted. The internal/external requirement is what the >> security group cares about the most, but it would be useful so we know if >> we're potentially impacting outside customers as a result which would bump >> up the risk level. >> >> >> >> Thanks, >> >> >> >> *Shawn Pierson * >> >> Remedy Developer | Energy Transfer >> >> >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> [email protected]] *On Behalf Of *Joe D'Souza >> *Sent:* Thursday, April 03, 2014 9:04 AM >> *To:* [email protected] >> *Subject:* Re: Web Service CIs >> >> >> >> ** >> >> I think I sort of see the why. >> >> >> >> Web Services when published have a potential of being used by n number of >> systems, and these systems could potentially be affected by an outage or an >> update of a web service and one could potentially loose track of all the >> potential consumers of a WS unless you have a proper DB of all its >> consumers. That's probably the management initiative behind wanting it in a >> CMDB so that any change requests to any of the systems or thee web services >> that are used by these systems, can then be tracked, depending on the >> relations between the system and the WS. >> >> >> >> If this is the drive behind it, I would think along the lines of >> considering the WS as a component of an application, rather than creating a >> specific CI just for Web Services. As for tracking if that WS is available >> inside or outside the network, you could build an attribute for the >> components of that application, that publishes that WS, on whether it is On >> Premise or Off Premise - and if Off Premise if it is a WS. >> >> >> >> Or maybe create a attribute for Software Applications for being On >> Premise or Off Premise, and then have components to the application, one of >> them being the various web services. >> >> >> >> Something along those lines. >> >> >> >> That should give you the ability to track change requests tied to a WS. >> >> >> >> Joe >> >> >> ------------------------------ >> >> *From:* Action Request System discussion list(ARSList) [ >> mailto:[email protected] <[email protected]>] *On Behalf Of *Rick >> Cook >> *Sent:* Thursday, April 03, 2014 9:27 AM >> *To:* [email protected] >> *Subject:* Re: Web Service CIs >> >> >> >> ** >> >> If you are asking our opinion of the strategy, I am opposed to it. >> Services are the what, not the how. I might add that management >> requirements should be the same. Tell me what you need, and let me figure >> out how. >> >> If they want to track this via Services, create one or more that >> describes the generic function being performed for the customer. Making >> them customer specific leads to an out of control service catalog. >> >> Rick >> >> On Apr 3, 2014 5:45 AM, "Pierson, Shawn" < >> [email protected]> wrote: >> >> ** >> >> Good morning, >> >> >> >> We got a new requirement this morning of setting up web services as CIs >> so they can be tied to Change Requests as well as provide our I.T. security >> department a list that they can maintain and monitor. Mostly we would need >> to just track the name, a URL, and some attribute for marking it as being >> available outside the network. There are a few different classes that I >> could see potentially using but since there isn't one that is marked >> specifically for it I wanted to see where you all would suggest tracking >> them. >> >> >> >> Thanks, >> >> >> >> *Shawn Pierson * >> >> Remedy Developer | Energy Transfer >> >> >> >> Private and confidential as detailed >> here<http://www.energytransfer.com/mail_disclaimer.aspx>. >> If you cannot access hyperlink, please e-mail sender. >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> Private and confidential as detailed >> here<http://www.energytransfer.com/mail_disclaimer.aspx>. >> If you cannot access hyperlink, please e-mail sender. >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: >> "Where the Answers Are" and have been for 20 years_ >> >> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> Private and confidential as detailed >> here<http://www.energytransfer.com/mail_disclaimer.aspx>. >> If you cannot access hyperlink, please e-mail sender. >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
