Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

What is "service virtualization" as used in the MSDN WSS custom web

  Asked By: Keaton    Date: Dec 20    Category: Sharepoint    Views: 2511

In msdn.microsoft.com/.../odc_sp2003_
ta/html/odc_writingcustomwebservicesforsppt.asp, "Writing Custom Web
Services for SharePoint Products and Technologies", this white paper uses
the term "service virtualization" in several places:

1. Modify the .disco and .wsdl files to support service virtualization.

2. To modify the Service1disco.aspx file and the Service1wsdl.aspx file to
support service virtualization.

3. This Web service uses service virtualization to determine the site
context, and then uploads the document to the Shared Documents document
library folder.

The term doesn't appear anywhere else on the Internet (except for a few SOA
references), no where in MSDN and no where in the WSS SDK.

What exactly are the authors (Rahul Sakdeo, Rohit Puri, Brett Stallman)
refering to when they usee the term "service virtualization"?

Share: 

 

11 Answers Found

 
Answer #1    Answered By: Jagdish Joshi     Answered On: Dec 20

I presume that they mean that the service  can be discovered externally.
However, I'm not familiar with the term  either.

I do have a contention with their supposition that the Web Service must
be running on a different port. I would swear that I've created custom
SharePoint Web Services that run on the same port (80) but under a
different host header.

If I'm wrong (and I could be here), any idea why the need for a unique
port when a unique host header or a unique IP address (post SP2 of
course) should suffice?

 
Answer #2    Answered By: Christop Mcfadden     Answered On: Dec 20

Re: I've created custom  SharePoint web  Services that run on the same port (80) but under a different host header.
I generally agree with your comment. I've always thought of using different ports vs. host headers as somewhat interchangeable. ...i.e. whatever it takes to get IIS to map an incoming request to a virtual directory (IIS web site). 85%certainty.


Re: What is "service virtualization"?

 
Answer #3    Answered By: Victoria Bell     Answered On: Dec 20

I think that I understand and that is more or less what I meant by the
"service can be discovered externally".

But just to be sure, by adding the appropriate information to the .disco
and .wsdl files, the Web service  can be deployed to just one of the Web
front ends and the other Web servers in the sharepoint  farm will
discover and use it. Is that correct?

I always thought that you had to deploy a custom  Web Service equally to
all Web servers in the farm. So, this is good news. The remaining
question is: What is the appropriate information to put into the .disco
and .wsdl files?

 
Answer #4    Answered By: Cassidy Sharpe     Answered On: Dec 20

Re: What is the appropriate information to put into the .disco and .wsdl files?
Checkout msdn.microsoft.com/.../...omwebservicesforsppt.asp for the details. ...and it just occured to me how the wp solution works.

In the section of the wp, "To create and edit a .disco file  and a wsdl", they have you turn the .disco and .wsdl into ASP.NET pages ...and hence, turn them into "dynamic" disco and wsdl  files.

Checkout the white  paper.

 
Answer #5    Answered By: Linda Mason     Answered On: Dec 20

reply to question about: "I always thought that you had to deploy a custom  Web service  equally to all web  servers in the farm. So, this is good news": (short answer: The physical files  need to be deployed to all the servers in the farm though (manually))

nope this does not relate to files being automatically deployed to all the servers in the form but just like how the layouts page (are deployed to all the servers in the fram and can be called from any site URL

for ex: one page at can be called from :

http://localhost/1033/_layouts/settings.aspx;

http://localhost/sites/site1/1033/_layouts/settings.aspx;

http://localhost/sites/sites1/web1/1033/_layouts/settings.aspx;

similarly for your web service you should be able add reference from any of the site locations. (and use the Context.GetSite() calls in your code to find out which site were you called from)

The physical files need to be deployed to all the servers in the farm though (manually)

 
Answer #6    Answered By: Hans Weiss     Answered On: Dec 20

I now think that I understand the term  "service virtualization" based on
the work I'm currently doing running Web Services as Web Part class
resources. I still don't fully understand it but here is what I believe
to be true.

Web Services can typically dynamically generate a Web service  Definition
Language (WSDL) that not only defines the operations, types, and
bindings that can be used with that Web Service but also location (URL)
from which it can be called. For instance a Todd Web Service running on
a Bleeker Virtual Server could return its wsdl  using the following URL:
http://Bleeker/Todd.asmx?WSDL

Similarly, a disco file  can also be used to discover a Web Services
location (URL). I've not used a disco file recently. I think that
technology is dead.

If you look at all the sharepoint  Web Services in the ISAPI folder  of
the 60 hive you will see static WSDL and DISCO files  represented as ASPX
pages (very odd - or so I thought). These files are apparently used to
call a Web Service from any Web as if it is a local Web Service. This is
the dynamic section near the bottom of the AlertsWsdl.aspx for the
Alerts Web Service:

<service name="Alerts">
<port name="AlertsSoap" binding="s0:AlertsSoap">
<soap:address location=<%
SPEncode.WriteHtmlEncodeWithQuote(Response,
SPWeb.OriginalBaseUrl(Request), '"'); %>
/>
</port>
</service>

Notice that the address location will return a URL based upon the
current requests URL. This in this way, every Web Service appears as if
it is running within the context of the Web where it was requested. This
concept of using static files for wsdl and disco that look like they are
running from the URL of the request rather than a value based upon where
the service is actually running from (the ISAPI folder of the 60 hive)
is what the MSDN authors  must mean by "service virtualization".

 
Answer #7    Answered By: Alison West     Answered On: Dec 20

BTW, I've created some batch files  that do 90% of tweaking of the disco.exe created wsdl  and DISCO files to create the dynamic aspx  versions ...eliminating all the potential manual/copy+past typos. I'll try to re-write the MS wp to describe these but I'm not sure when I'll get to them.

Another best practice is that we designed our WSS web  services to have a "thin web services layer on top of a think business object layer". The business object layer issued all of the WSS OM/API calls and were designed to be testable with a standard Winforms test harness. The business object methods accepted SPSite objects as a key parameter. This helped reduce the code in the Web ASMX to the 3-4 lines needed to established the security context and resolve the SPSite needed to call the business objects. This design was important because it is difficult to interactively debug the Web service  code once deployed into the ISAPI folder.

BTW, be careful to NOT re-use the build.bat batch file  that comes with the sample. It will clobber the Global.asx file in the WSS ISAPI folder. Here is a copy of our do_deploy.cmd batch file:

-----
set MYWSEDIR="C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\ISAPI"

set MYSERVER=XXXXsrv
set MYPORT=80XX
set MYPROJECT=XXdatasrv-0-5-6
set MYWS=XXDataServices

echo Don't copy Global.asax!

copy /y SPDisco.aspx %MYWSEDIR%
copy /y %MYWS%.aspx %MYWSEDIR%
copy /y %MYWS%disco.aspx %MYWSEDIR%
copy /y %MYWS%wsdl.aspx %MYWSEDIR%

copy /y bin\%MYPROJECT%.dll %MYWSEDIR%\BIN
copy /y bin\%MYPROJECT%.pdb %MYWSEDIR%\BIN

copy /y psnvulture-1-0-44JTS\bin\Debug\*.dll %MYWSEDIR%\BIN
copy /y psnvulture-1-0-44JTS\bin\Debug\*.pdb %MYWSEDIR%\BIN

pause

iisreset.exe
pause

 
Answer #8    Answered By: Freddy Heath     Answered On: Dec 20

s/think business object layer/thick business object layer/

 
Answer #9    Answered By: Joanna Dixon     Answered On: Dec 20

I'm not actually using the sample at all (I haven't looked at it yet). I
discovered I had a similar need when trying to encapsulate a web  Service
as a Web Part resource. I'd rather deploy my custom  Web Services as an
embedded class resource rather than in the ISAPI folder.

I'm still researching three questions:
1. Why doesn't ?WSDL on the QueryString work for a Web Services running
within the SharePoint Virtual Server (it works in an excluded managed
path)? I get a generic SharePoint error page that says "File Not Found"
but I cannot determine  what page/file the QueryString method is
dependant upon. I've proven that I can relocate and alter the
DefaultWsdlHelpGenerator.aspx so that isn't the culprit. This is just my
lack of understanding about how ?WSDL works. That would be my preferred
solution to service  virtualization when the Web Service is a class
resource to a Web Part.

2. How does the web.config in the physical wpresources directory of a
SharePoint extended Virtual Server get generated? Can it be altered
programmatically? Why does it forbid certain verbs and why doesn't the
forbidding work? For instance, I frequently put ASCX controls and ASPX
pages into a Web Part's class resources without issue. So, how do they
execute when the web.config says they shouldn't?

3. What is the best code to dynamically determine if an assembly is
deployed locally in the \bin using wpresources or deployed globally in
the GAC using _wpresources? Right now I'm using
ClassResourcePath.IndexOf but there must be a better way. I want to
obtain a root relative reference and I can't seem to find any .NET code
that returns that. The URI's AbsolutePath (see example) is close but it
fails when the Web Part is running in a managed path:
string url = new Uri(this.ClassResourcePath +
"/resource.jpg").AbsolutePath;

Do let me know if you have any insight...

 
Answer #10    Answered By: Damon Garner     Answered On: Dec 20

I don't have specific answers but the general answer relates the fact the WSS v2 is not a native ASP.NET 1.1 application ...contrary to what most people think.

In the 2003 release, the SPPT 2003 product group needed to use a SharPoint custom  ISAPI filter to front-end all the WSS calls, pre-processes them and then programmatically calls the ASP.NET handler when appropriate. See the attached SPPT 2003 architecture diagram.

In WSS "12", using ASP.NET 2.0, the SharePoint custom ISAPI filter is *not* needed (i.e. WSS "12" is a native ASP.NET 2.0 application). ...I don't know (yet) how it affects creating custom SPPT Web Services.

I think this help explain most the questions you have (at a high level).

 
Answer #11    Answered By: Sharonda Mcfarland     Answered On: Dec 20

I am familiar the the STSFLTR ISAPI application that all
included managed path SharePoint requests must pass thru. However, a
ghosted page (Web Service) is supposed to be processed by the CLR and ASP.NET parser.

So, if I knew what file  that the ? WDSL QueryString parameter was looking for I could help SharePoint find it.

 




Tagged: