39 Replies Latest reply on May 5, 2010 7:06 PM by cescamilla

    Some thoughts about PI Webservices

    MichaelvdV@Atos

      I would like to share some thoughts I have about the PI Webservices product.

       

      <disclamer>

       

      In no way I'm trying to be smart or anything, but these are things that are crossing my mind. And since one of the purposes of vcampus is to have a direct link to OSIsoft developers, what better way of sharing them here. I'm not trying to criticize the product or the design decisions, but I'm merely trying to start up a discussion to get some insight.

       

      </disclamer>

       

      After the presentation about PI Webservices on vCampus Live!, reviewing the documentation and playing around with the product I have some concerns.

       

      My main concern is the design of the service itself. From what I get, the team is trying to create an API which is very versitale, and can do lots of things with a few operations.

       

      This creates a lot of challenges: WCF does not support everything you would like it to support (overloading, serialization of type object, etc.). For instance: every value (which is a VARIANT) is returned as a string, because there is no real substitute for a VARIANT/object in the WCF world.

       

      By choosing WCF there has been made a decision to create an RPC based service (as supposed to a REST based approach). The 'design' concern here is that by normalizing the operations, there are only 3 operations, which could do basically everything with timelines. While this is a nice thought, I am concerned about the implications for users (us, the programmers).

       

      In the current version, every call accepts arrays of objects that describe the request. While this is a good approach, a direct consequence is that every request has to be packed in request objects, which have to be packed in an array. IMO this creates a lot of code overhead on the client side.

       

      One of the biggest advantages of the PI Webservices product is (IMO) that it provides a way to create Silverlight based PI applications, using an interface/API supported by OSIsoft. While developing Silverlight based PI products, "untill now" I had to create my own WCF/REST services. If I could use a Webservice supported by OSIsoft, this would certainly make my developer live a lot easier.

       

      But, at this moment: I would not use the PI Webservices product. I would rather create my own WCF service. The main reason behind this is the code overhead in the Silverlight client.

       

      What I would like to see in such a product is more operations. For each task an operation , something like this:

      [OperationContract]
      PiPoint GetPiPoint(string tagName);

      [OperationContract]
      List<PiPoint> GetPiPointRange(string[] tagNames);

      [OperationContract]
      PiValue GetSnapshot(string tagName);

      [OperationContract]
      List<PiValue> GetSnapshotRange(string[] tagNames);

      [OperationContract]
      PiValue GetValue(string tagName, string startTime, string endTime, ..., ...);

      [OperationContract]
      List<PiValue> GetValueRange(string[] tagNames, string startTime, string endTime, ..., ...);

      or maybe somewhat more in line with the current product (supporting single/range operations):

      [OperationContract]
      TimeSeries[] GetPIArchiveDataRange(PIArcDataRequest[] requests);

      [OperationContract]
      TimeSeries GetPIArchiveData(PIArcDataRequest request);

      [OperationContract]
      TimeSeries[] GetPIAggregateDataRange(PIAggregateDataRequest[] requests);

      [OperationContract]
      TimeSeries GetPIAggregateData(PIAggregateDataRequest request);

      This would already make it more user friendly for programmers! I cannot think of any drawback in supporting many/multiple operations

       

      or maybe even using basic type parameters

      [OperationContract]
      TimeSeries[] GetPIArchiveDataRange(PIArcDataRequest[] requests);

      [OperationContract]
      TimeSeries GetPIArchiveData(string path, string startTime, string EndTime, PIArcManner manner);

      [OperationContract]
      TimeSeries[] GetPIAggregateDataRange(PIAggregateDataRequest[] requests);

      [OperationContract]
      TimeSeries GetPIAggregateData(string path, string startTime, string EndTime, PIAggregateManner manner);

      Something along that line. What do you guys think of this?

       

      ps: I was wondering why there doesn't seem to much happening in the "Web Services and PI" subforum. Webservices is a hot item, and should be something we PI programmer geeks would 'want' from OSIsoft. Why is that?

       

      tl;dr; In my opinion the PI Webservices product should provide more, and more distinct operations. IMO the current implementation is not user friendly for (Silverlight) programmers to implement

        • Re: Some thoughts about PI Webservices

          Great post Michael.

           

          What would be interesting to hear from OSI is what mechanism they will be using for PI Web Parts 4.0 that will be Silverlight based - OSI have said (I asked in the webinar) they will not use the PI Web Services product within their own products, which I guess suggests they are using another method for Silverlight.

            • Re: Some thoughts about PI Webservices
              MichaelvdV@Atos

              Rhys @ RJK Solutions

              Great post Michael.
              Thank you sir

               

              Can you find some parallels with your idea's about this subject?

              Rhys @ RJK Solutions

              What would be interesting to hear from OSI is what mechanism they will be using for PI Web Parts 4.0 that will be Silverlight based - OSI have said (I asked in the webinar) they will not use the PI Web Services product within their own products, which I guess suggests they are using another method for Silverlight.

               

              Indeed. I also heard that OSIsoft is not using PI Webservices in their Silverlight products. This made me thinking: what other options (besides web services) do we have in Silverlight? Silverlight does (very limited) support sockets, but I don't think that will suffice.

               

              It has to be some HTTP based protocol, wheter WCF or REST based. Payload wise, SOAP wouldn't be the best option (overhead), so Plain Old XML (POX) or JSON should work. Maybe the binary WCF channel that Silverlight supports since SL3 ?

               

              I'm also very curious :) Maybe some of the OSIsoft devvers would like to elaborate on this?

                • Re: Some thoughts about PI Webservices
                  merighm

                  That is a great post, Michael.

                   

                  But was not "PI Web Services" positioned/presented as PI OPC UA Lite, which is there only because UA is not finlized yet?

                   

                  Moh&

                   

                   

                   

                   

                    • Re: Some thoughts about PI Webservices
                      MichaelvdV@Atos

                      MOH M ERIGH

                      That is a great post, Michael.

                       

                      Thank you sir!

                       

                      MOH M ERIGH

                      But was not "PI Web Services" positioned/presented as PI OPC UA Lite, which is there only because UA is not finlized yet?

                       

                      Since (from what I know) OPC UA does support both binary and SOAP (WebServices) as methods of transport, this could be the case. I am not an OPC UA expert, but I 'guess' the OPC UA webservice will be even more abstract for specific PI related operations.

                        • Re: Some thoughts about PI Webservices

                          MOH M ERIGH

                          But was not "PI Web Services" positioned/presented as PI OPC UA Lite, which is there only because UA is not finlized yet?
                          No, these are 2 very distinct initiatives/products. I invite you watch the replay (or review the presentation) of the PI System via Web Services webinar, where both technologies are described.

                           

                          Michael @ Atos Origin

                          OPC UA does support both binary and SOAP (WebServices) as methods of transport
                          This is incorrect: OPC UA supports both binary (a.k.a UA TCP) and HTTP-based, SOAP methods of transport. More information can be found in the PI and OPC UA webinar.

                           

                          (man, these webinars are good! )

                           

                          Michael @ Atos Origin

                          Webservices is a hot item, and should be something we PI programmer geeks would 'want' from OSIsoft.
                          Way to go! I'm sure the PI Web Services will be happy to read this. Keep trying the CTP out and keep the feedback coming.

                          And now I'm afraid I'll have to let the PI Web Services team answer the rest of Michael's original post - the technical part.

                            • Re: Some thoughts about PI Webservices
                              MichaelvdV@Atos

                              Steve Pilon

                              Michael @ Atos Origin

                              OPC UA does support both binary and SOAP (WebServices) as methods of transport
                              This is incorrect: OPC UA supports both binary (a.k.a UA TCP) and HTTP-based, SOAP methods of transport. More information can be found in the PI and OPC UA webinar.
                              Is my English lacking, or are we still saying the same thing?:

                               

                              1. Binary protocol

                              • best performance, the least overhead
                              • takes minimum resources (no XML Parser, SOAP and HTTP required -> important for embedded devices)
                              • best possible interoperability (binary is explicitly specified and allows less degrees of freedom during implementation as XML does)
                              • only one single TCP port (4840) gets used for communication and can get tunneled or enabled through a Firewall easily

                              2. WebService (SOAP)

                              • best supported from available tools. It can be easily used i.e. from JAVA or .Net environments
                              • Firewall-friendly. Port 80 (http) and 443 (https) will usually work without additional configuration.

                              [Shamelesly stolen from http://en.wikipedia.org/wiki/OPC_Unified_Architecture)

                               

                              As for the technical part Steve: what does your inner-programmer-geek think?

                                • Re: Some thoughts about PI Webservices

                                  Michael @ Atos Origin

                                  Is my English lacking, or are we still saying the same thing?
                                  You are absolutely right... my bad on this one, I somehow imagined a "not" in your sentence

                                   

                                  Michael @ Atos Origin

                                  what does your inner-programmer-geek think?
                                  As for everything else, the geek inside me thinks it would be good to have it all (both the RPC/SOAP and the REST approaches). But as always, it's a matter of juggling with functionality priority, time and resources... again, I'll let the PI Web Services team answer these questions if you don't mind 

                                    • Re: Some thoughts about PI Webservices
                                      MichaelvdV@Atos

                                      Steve Pilon

                                      I somehow imagined a "not" in your sentence
                                      Allright, I was thinking it might be a punctuation issue :)

                                       

                                      Steve Pilon

                                      As for everything else, the geek inside me thinks it would be good to have it all (both the RPC/SOAP and the REST approaches). But as always, it's a matter of juggling with functionality priority, time and resources... again, I'll let the PI Web Services team answer these questions if you don't mind 
                                      Yeah. I'm with you on that one. The current approach seems to have some sort of a REST based approach to an RPC architecture. Indeed, it would be nice to have both, I totally agree (and with WCF, this is possible). But, the current RPC approach seems too abstract to me.

                                       

                                      I'm curious about what the developers think of this!

                                        • Re: Some thoughts about PI Webservices

                                          Just so you know, the ones who are the most enclined to address your concerns/questions are in meetings with Microsoft in Redmond this week... chances are they'll be able to get back to you early next week. Don't worry, your feedback is appreciated and won't remain unanswered

                                            • Re: Some thoughts about PI Webservices
                                              MichaelvdV@Atos

                                              Steve Pilon

                                              Just so you know, the ones who are the most enclined to address your concerns/questions are in meetings with Microsoft in Redmond this week... chances are they'll be able to get back to you early next week. Don't worry, your feedback is appreciated and won't remain unanswered

                                               

                                               

                                              Allright. Thanks for the update!

                                                • Re: Some thoughts about PI Webservices
                                                  MichaelvdV@Atos

                                                  I'm really curious as to why there is not that much reaction to this topic.

                                                   

                                                  I can come up with two reasons:

                                                  • My argument is totally invalid, and not worth discussing (which I tend to not think, because of the reactions of some of the members in this topic)
                                                  • PI WebServices is a product that is not (yet) really much alive/needed (would account for the lack of reactions in the PI Webservices subforum)

                                                  Are we in a period of time where we (as PI developers) need PI Webservices to create 'nextgen' PI applications based on modern techniques (.NET, WPF, Silverlight) ? I like to think so! (personally, I know we are in this kind of period in time). It seems to me that this is not the general consensus.

                                                   

                                                  Maybe I'm stirring up things here, but I think this is a valid discussion point.

                                                   

                                                   

                                                    • Re: Some thoughts about PI Webservices

                                                      Michael,

                                                       

                                                      From my perspective I had a good "play" with PI Web Services when the CTP was first released and I could see how it could be used in quite a few scenarios.  However, I just don't sense the overwhelming demand just yet for the adoption of PI Web Services (possibly because I haven't fully immersed myself in to WPF/Silverlight...yet) - plus I did write some PI web services for someone about a year or so ago but no where near as sophisticated as OSI PI Web Services.  For majority of PI end users their question is always related to ProcessBook, Web Parts, PISDK, AF (AFSDK)...all the released products.

                                                       

                                                      For me personally, when I heard OSI won't reuse the PI WS technology within their own applications I started to wonder if I should use it in anything I develop - maybe they have a valid reason for this (I am sure we will hear from them soon).

                                                       

                                                      On a semi-related topic, I got excited by Event Frames but the lack of activity in that sub forum got me thinking I am the only one excited   Event Frames is a CTP so maybe the word needs to spread some more and when it is a released product it will pick up pace..?

                                                       

                                                       

                                                        • Re: Some thoughts about PI Webservices
                                                          MichaelvdV@Atos

                                                          I get what you are saying.

                                                           

                                                          I'm also really eager to learn how or if OSIsoft is going to incorporate this product in their own products.

                                                           

                                                          On the Event Frames subforum: I think it's about the same thing here. But, besides that: I still can't really grasp why this is the case. These are both pretty exciting new technologies, yet it seems nobody is rushing to get into it.

                                                            • Re: Some thoughts about PI Webservices
                                                              MichaelvdV@Atos

                                                              In light of our latest discussion point:

                                                               

                                                              Would it create greater enthousiasm and support for new products (or CTP's) if OSIsoft would provision ready-to-be-used VM's with the product + sample products installed? This would make it very easy for vCampus enthousiasts to try out new technology... This would mean more work for OSIsoft, but in return they (may) get a greater response to CTP releases.

                                                                • Re: Some thoughts about PI Webservices

                                                                  Michael @ Atos Origin

                                                                  if OSIsoft would provision ready-to-be-used VM's with the product + sample products installed
                                                                  It probably would... but then you get into licensing concerns with us distributing copies of Microsoft Windows, the .NET Framework, Microsoft Office, etc. outside of our organization

                                                                   

                                                                  What's your option #2 to get greater response to CTP releases?

                                                                    • Re: Some thoughts about PI Webservices

                                                                      Steve Pilon

                                                                      What's your option #2 to get greater response to CTP releases?

                                                                       

                                                                       

                                                                      Free vCampus t-shirts.

                                                                       

                                                                       

                                                                      • Re: Some thoughts about PI Webservices
                                                                        MichaelvdV@Atos

                                                                        Steve Pilon

                                                                        Michael @ Atos Origin

                                                                        if OSIsoft would provision ready-to-be-used VM's with the product + sample products installed
                                                                        It probably would... but then you get into licensing concerns with us distributing copies of Microsoft Windows, the .NET Framework, Microsoft Office, etc. outside of our organization

                                                                         

                                                                        What's your option #2 to get greater response to CTP releases?

                                                                         

                                                                        Yeah, that's true. But Microsoft does this thing all the time (with CTP's, think VS 2010).

                                                                         

                                                                        I will think of option #2

                                                                          • Re: Some thoughts about PI Webservices

                                                                            Michael @ Atos Origin

                                                                            But Microsoft does this thing all the time
                                                                            Well, Microsoft is Microsoft: they can distribute their own stuff at will. Third-parties (like OSIsoft) wanting to distribute Microsoft products implies licensing concerns. I'm not saying these cannot be resolved; I'm saying this is something to consider.

                                                                             

                                                                            So we preferred the option of providing A) a hosted version of the CTP  and B) the actual bits, on a per-demand basis. And keep in mind the CTP was the very first step of this product's lifetime; I'm sure you'll get more occasions to play with the software on your own system in the future. And given that most of the vCampus members already have their personal vCampus development PI System installed, we're almost there with your "ready-to-be-used" desire

                                                                              • Re: Some thoughts about PI Webservices
                                                                                MichaelvdV@Atos

                                                                                Steve Pilon

                                                                                So we preferred the option of providing A) a hosted version of the CTP  and B) the actual bits, on a per-demand basis. And keep in mind the CTP was the very first step of this product's lifetime; I'm sure you'll get more occasions to play with the software on your own system in the future. And given that most of the vCampus members already have their personal vCampus development PI System installed, we're almost there with your "ready-to-be-used" desire

                                                                                 

                                                                                Totally agreeing with you there. It was just a first thought about how the CTP could be distributed so that it would attract more attention and users. I can imagine the legal implications there.

                                                                          • Re: Some thoughts about PI Webservices
                                                                            smohr

                                                                            We are planning a beta release which would be available to vCampus subscribers (which is one reason why you are a subscriber in the first place) so you will be able to get the bits in the *mumble, mumble* time frame (yeah, don't press me on that!).  The installation is pretty friendly now and due to get better by beta.

                                                                              • Re: Some thoughts about PI Webservices
                                                                                MichaelvdV@Atos

                                                                                Stephen Mohr

                                                                                We are planning a beta release which would be available to vCampus subscribers (which is one reason why you are a subscriber in the first place) so you will be able to get the bits in the *mumble, mumble* time frame (yeah, don't press me on that!).  The installation is pretty friendly now and due to get better by beta.

                                                                                 

                                                                                Nice, I'm looking forward to that! I will take the time to have a very good look at it, so I can get back to you with better arguments and answers.

                                                                                  • Re: Some thoughts about PI Webservices
                                                                                    MichaelvdV@Atos

                                                                                    In light of our recent discussion I think I have to give in to my opinion a little bit. I can understand more and more why the current approach was taken, instead of an approach with more methods. Thank you for having this discussion.

                                                                                     

                                                                                    However, I do have a few (functionality) suggestions:

                                                                                    • Server Discovery. I think it would be a very good addition to add the posibility to request a server list. This could in it's simplest form be just the servernames, but idealy it would contain more information (specifically the information from the 'known server list' from PISDK 
                                                                                    • Tag Search. In addition to server discovery, it would be very good to have the ability to search for tags on a specific server. In it's simplest form this could be just the tagnames (paths), but ideally it would also contain some attribute information (engunits, description, pointtype, pointsource). My suggestion would be to have the possibility to use a string containing a whereclause (like the SDK functions) as a parameter for such a function.
                                                                                    • Point/Node (Meta) Information. It would be nice to have the possibility not only to request timeseries, but also the meta information about a pipoint or AF Node

                                                                                    I can understand that the current CTP/beta release will not contain this functionality. However, I do think that point 1 and 2 are needed to succesfully create (Silverlight) applications using PI timeseries data.

                                                                                      • Re: Some thoughts about PI Webservices
                                                                                        smohr

                                                                                        Search is a big topic.  We want to take the time to get it right, not to mention getting a consistent behavior across the PI platform.  Your last point is very interesting.  Something like this flitted across my brain the other day; input like this moves it up.

                                                                                          • Re: Some thoughts about PI Webservices
                                                                                            MichaelvdV@Atos

                                                                                            Stephen Mohr

                                                                                            Search is a big topic.  We want to take the time to get it right, not to mention getting a consistent behavior across the PI platform.  Your last point is very interesting.  Something like this flitted across my brain the other day; input like this moves it up.

                                                                                             

                                                                                             

                                                                                            Allright! Glad to hear you concur.

                                                                                             

                                                                                            For my understanding as a simple 'amateur' programmer (compared to you guys):

                                                                                             

                                                                                            It would seem all the provisions of creating such methods are in place. For server discovery you could just use the PISDK server list, and for tagsearch you could use the PISDK 'GetPoints' or 'GetPointsSQL' method.

                                                                                             

                                                                                            What am I missing here?

                                                                                              • Re: Some thoughts about PI Webservices
                                                                                                MichaelvdV@Atos

                                                                                                Steve (or another WebService developer):

                                                                                                 

                                                                                                It would be really helpfull if you reply to the above question.

                                                                                                 

                                                                                                Also, would it be possible to reply to another question earlier in this thread? I am refering to the one about OSIsoft not using PI WebServices as a datasource for (future) products (such as Silverlight webparts or the nextgen Visualisation tool).

                                                                                                  • Re: Some thoughts about PI Webservices
                                                                                                    smohr

                                                                                                    The problem with search is two-fold.  First, what is search on the PI platform?  We're giving this a lot of thought.  To date, it's meant tag search, but we're exposing lots of new stuff.  We want to get this right and not just introduce things piecemeal, especially if they are inconsistent across products.  Second, there is an issue of architecture.  We're built on top of PI Data Services.  We could introduce PI SDK code, but it would introduce the SDK at two different levels and might become a one-off that has to be re-written for a later release.

                                                                                                     

                                                                                                    I posted to the blog about a week ago regarding the Silverlight issue and cross-linked somewhere in here.  In case you missed it:

                                                                                                     

                                                                                                    Some comments on the discussion forum say that OSIsoft's Silverlight applications do not use PI Web Services for data access.  We have one forthcoming Silverlight application that could have used PI Web Services but does not.  Why?

                                                                                                     

                                                                                                    The main reason our Silverlight application is not using PI Web Services is that that data feed can be focused precisely on the needs of the classes consuming the data in the Silverlight application.  This is a good result  for the application, but a bad fit for a product, i.e., PI Web Services, that is intended as a general purpose product consumed by all sorts of clients.  Both the custom data layer and PI Web Services share an implementation layer in common; indeed, PI Web Services relies largely on this layer for its implementation.  The end result is that consumers of PI Web Services and the PI Silverlight application will receive the same behavior and data results.  Only the interfaces are different.

                                                                                                      • Re: Some thoughts about PI Webservices
                                                                                                        MichaelvdV@Atos

                                                                                                        Hi Steve,

                                                                                                         

                                                                                                        Thank you so much for taking the time to reply. I can certainly understand both points about the search functionality. This is certainly something to give a lot of thought. I didn't think of it that way. Thank you for the insight.

                                                                                                         

                                                                                                        Would it be an idea if OSIsoft is somewhat further in the thought process, to discuss the various options here on vCampus. I could imagine you guys maybe want some input or a fresh insight?

                                                                                                         

                                                                                                        I totally missed your blog post, sorry about that! Your blogpost explains it really well.

                                                                                                          • Re: Some thoughts about PI Webservices
                                                                                                            smohr

                                                                                                            I can't speak for other teams, but I fully expect to see more discussion of search here and on other forums in the future.  Not only do we have new sources to search (e.g., AF), but the size of some of our installations is amazing.  Searching for "*" on a server with a few hundred (or even thousand) tags is one thing, searching on an enterprise scale is another.  Throttling and estimating the scope of a search is something to consider.

                                                                    • Re: Some thoughts about PI Webservices
                                                                      smohr

                                                                      I've addressed this on the blog on the post Perhaps you've heard a rumor....  Okay, so it was a webinar answer not a rumor...

                                                                  • Re: Some thoughts about PI Webservices
                                                                    smohr

                                                                    Sorry about the delay in replying.  Your comments are always welcome, but a response on this scale deserves a thoughtful response.

                                                                     

                                                                    To answer the easy question first, we are aware of the interest in REST and it is definitely on our radar.  Due to the differences between REST and SOAP, not to mention the fact that REST is specific to one protocol and SOAP is not, we would likely create a completely separate, REST-centric interface should we decide to do a REST implementation.  That is to say you would not simply call the existing methods via REST, rather you would have methods better suited to REST.

                                                                     

                                                                    To move on to more difficult topics:

                                                                     

                                                                    Over time our interface has evolved from a very few methods designed to do a lot (using polymorphic parameters) toward more methods using much more specific types.  The type issue was needed to overcome the lack of reliable substitutionGroup implementations in various SOAP frameworks.  We are anxious to control this migration and avoid an interface with potentially dozens of methods.  One goal has been to make it easy to get started.  Of course, some expansion is necessary as we add new features.  In your opinion, is it worth doubling the number of methods to avoid the necessity to populating an array?  I'm not challenging you, BTW; that is an honest question.

                                                                     

                                                                    That said, we do value your input.  Obviously, it is easy for us to gravitate toward one solution around the office even if it is not optimal for the majority of customer-programmers.  Your post counts as the first "dissent" from the in-house orthodoxy!

                                                                     

                                                                    What do the rest of you say?  Is Michael on to something?

                                                                      • Re: Some thoughts about PI Webservices
                                                                        MichaelvdV@Atos

                                                                        Stephen Mohr

                                                                        Sorry about the delay in replying.  Your comments are always welcome, but a response on this scale deserves a thoughtful response.

                                                                         

                                                                        No problem. Thank you for taking the time to reply. Steve mentioned you guys where at Microsoft in Redmond (which made me a bit jealous by the way)

                                                                         

                                                                        Stephen Mohr

                                                                        To answer the easy question first, we are aware of the interest in REST and it is definitely on our radar. 

                                                                         

                                                                        Well, that's very good to hear. I will be looking forward to that (and the discussion surrounding creating a viable REST based interface)

                                                                         

                                                                        Stephen Mohr

                                                                        Due to the differences between REST and SOAP, not to mention the fact that REST is specific to one protocol and SOAP is not, we would likely create a completely separate, REST-centric interface should we decide to do a REST implementation.

                                                                         

                                                                        Are you refering to the transport protocol? Then indeed, REST is totally HTTP (verb) based, where as WCF also supports different transport formats. If you are refering to the message protocol. The message format of a REST service is pretty open to interpretation (POX, AtomPub, Json).

                                                                         

                                                                        Creating a seperate REST based approach would be a very wise choise (IMO). I like the ADO.NET Data Services (framework) for this.

                                                                         

                                                                        Stephen Mohr

                                                                        Over time our interface has evolved from a very few methods designed to do a lot (using polymorphic parameters) toward more methods using much more specific types.  The type issue was needed to overcome the lack of reliable substitutionGroup implementations in various SOAP frameworks. 

                                                                         

                                                                        We talked a little about this in SF. WCF has it's (understandable) technical limitations. I have personally bumped to that wall a few times. If only WCF services supported method overloading

                                                                         

                                                                        Stephen Mohr

                                                                        We are anxious to control this migration and avoid an interface with potentially dozens of methods.  One goal has been to make it easy to get started.  Of course, some expansion is necessary as we add new features. 

                                                                         

                                                                        I can certainly understand your reservations in this mather. API design is a beautiful but very tricky thing. I'm looking at this primarily from a (Silverlight) programmers' perspective. In my opinion API's should be easy to use, and they should offer complete access. So, if the product will be released with limited functionality, I would likely not be interested in it (at that time). I would rather implement my own, with the features I need. The big issue here will be that the OSIsoft Webservice will proberbly outperform my own service with a factor X.

                                                                         

                                                                        In this case, I would like to see the possibility to write/read tag metadata, tagsearch funcionality and server discovery functionality (maybe even user/group) information.

                                                                         

                                                                        Stephen Mohr

                                                                        In your opinion, is it worth doubling the number of methods to avoid the necessity to populating an array?  I'm not challenging you, BTW; that is an honest question.

                                                                         

                                                                        Well, yes and no. From an API design perspective this seems a bit nuts. After me starting this thread I have been busy with creating a WCF service (based on LinqToPi). I have taken the approach to create 'single' and 'range' functions for almost everything. So, this indeed increases my number of methods a lot. The direct result of this is that my (autogenerated) WSDL is bigger, and my (autogenerated) proxy code is bigger. That's it. I found this approach pretty nice to use in the (Silverlight) client side.

                                                                         

                                                                        The biggest concern with the OSIsoft Webservice was not primarly that 'I had to package it into arrays', but more that I got the idea that the API was maybe somewhat over-normalized. Only providing 'range' methods was one of the things that came to my mind.

                                                                         

                                                                        Well, to be honest: It first really came to me during your presentation on vCampus Live! You had a Silverlight example, where you called the webservice. I was a bit surprised by the amount of code in the example that was needed to call the functions and bind the returning values. I guess you created the example to be self-describing rather then efficient/clean code, so that reaction could be a bit biased.

                                                                         

                                                                        I started this topic not really to push my opinion, but really to start an in-depth discussion about the service. There hasn't been much action in this subforum, and (also from your reaction) the development team at OSIsoft could use some more input from the community.

                                                                         

                                                                         

                                                                          • Re: Some thoughts about PI Webservices
                                                                            smohr

                                                                            Michael @ Atos Origin

                                                                            Well, to be honest: It first really came to me during your presentation on vCampus Live! You had a Silverlight example, where you called the webservice. I was a bit surprised by the amount of code in the example that was needed to call the functions and bind the returning values. I guess you created the example to be self-describing rather then efficient/clean code, so that reaction could be a bit biased.

                                                                             

                                                                            Hmmm, this is a bit different.  Silverlight and WPF are much bigger on binding to declarative elements and want to minimize code.  I was looking at it from a programmatic standpoint.  Keep in mind that the vCampus Live demo code explicitly set some things (mostly the manner) that have defaults so you could see the switches.  What defaults would you like to see and what would make your life in Silverlight better?