We have a SOA Service Registry with in our organization. This is a custom build web application. We ask different teams to register their developed services in the Service Registry. But we are not able to ensure that every team is registering all their services in the service registry. To enable better SOA governance, we want to enforce automatic service registration in the service repository by application teams, the idea is when ever they create a web service proxy on data power xg45 appliance, we want to invoke a web service call which will automatically create the service in the custom registry.
Our team is using IBM Data power xg45.
Is it possible to integrate IBM Data Power XG45 with the custom registry?
There is a few management interfaces to DataPower. What you can do is to poll those interfaces on a regular basis to extract any info regarding deployed web service proxies. It's pretty easy to setup a web service call from whatever app have you. If you poll the management interface often, it's pretty much the same as if DP would have created the registry entry itself.
A good e-book (although a bit old) is: http://www.redbooks.ibm.com/redpapers/pdfs/redp4446.pdf
For instance, the AMP interface can query available WSGateway services in a domain called RIV. The response will include info about referenced WSDL files, service names and referenced HTTP protocol handlers. For some details, you may need to query further and for some details, you may be able to figure out what to enter into the registry from the export.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.datapower.com/schemas/appliance/management/3.0">
<soapenv:Header/>
<soapenv:Body>
<ns:GetReferencedObjectsRequest>
<ns:Domain>RIV</ns:Domain>
<ns:ObjectClass>WSGateway</ns:ObjectClass>
<ns:ObjectName></ns:ObjectName>
</ns:GetReferencedObjectsRequest>
</soapenv:Body>
</soapenv:Envelope>
Related
I created web service in visual studio 2010 three years back. I use this Web service in my winform project for performing some online functions. Now I want to create web service in visual studio 2013. Here I see web api instead of traditional web service. So my question is that what is the difference between traditional web service and Web api? And can I achieve the same thing in web api which I do in traditional web service?
Web Service in ASP.NET
A Web Service is programmable application logic accessible via standard Web protocols. One of these Web protocols is the Simple Object Access Protocol (SOAP). SOAP is a W3C submitted note (as of May 2000) that uses standards based technologies (XML for data description and HTTP for transport) to encode and transmit application data.
Consumers of a Web Service do not need to know anything about the platform, object model, or programming language used to implement the service; they only need to understand how to send and receive SOAP messages (HTTP and XML).
WCF Service
Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application. An endpoint can be a client of a service that requests data from a service endpoint. The messages can be as simple as a single character or word sent as XML, or as complex as a stream of binary data.
In what scenarios must WCF be used
A secure service to process business transactions.
A service that supplies current data to others, such as a traffic report or other monitoring service.
A chat service that allows two people to communicate or exchange data in real time.
A dashboard application that polls one or more services for data and presents it in a logical presentation.
Exposing a workflow implemented using Windows Workflow Foundation as a WCF service.
A Silverlight application to poll a service for the latest data
feeds.
Features of WCF
Service Orientation.
Interoperability.
Multiple Message Patterns.
Service Metadata.
Data Contracts.
Security.
Multiple Transports and Encodings.
Reliable and Queued Messages.
Durable Messages.
Transactions.
AJAX and REST Support.
Extensibility.
Difference between Web Service in ASP.NET & WCF Service
WCF is a replacement for all earlier web service technologies from Microsoft. It also does a lot more than what is traditionally considered as "web services".
WCF "web services" are part of a much broader spectrum of remote communication enabled through WCF. You will get a much higher degree of flexibility and portability doing things in WCF than through traditional ASMX because WCF is designed, from the ground up, to summarize all of the different distributed programming infrastructures offered by Microsoft. An endpoint in WCF can be communicated with just as easily over SOAP/XML as it can over TCP/binary and to change this medium is simply a configuration file mod. In theory, this reduces the amount of new code needed when porting or changing business needs, targets, etc.
ASMX is older than WCF, and anything ASMX can do so can WCF (and more). Basically you can see WCF as trying to logically group together all the different ways of getting two apps to communicate in the world of Microsoft; ASMX was just one of these many ways and so is now grouped under the WCF umbrella of capabilities.
Web Services can be accessed only over HTTP & it works in stateless environment, where WCF is flexible because its services can be hosted in different types of applications. Common scenarios for hosting WCF services are IIS,WAS, Self-hosting, Managed Windows Service.
The major difference is that Web Services Use XmlSerializer. But WCF Uses DataContractSerializer which is better in Performance as compared to XmlSerializer.
Key issues with XmlSerializer to serialize .NET types to XML
Only Public fields or Properties of .NET types can be translated into XML.
Only the classes which implement IEnumerable interface.
Classes that implement the IDictionary interface, such as Hash table cannot be serialized.
Important difference between DataContractSerializer and XMLSerializer
A practical benefit of the design of the DataContractSerializer is better performance over Xmlserializer.
XML Serialization does not indicate which fields or properties of the type are serialized into XML whereas DataCotractSerializer.
Explicitly shows the which fields or properties are serialized into XML.
The DataContractSerializer can translate the HashTable into XML.
http://www.codeproject.com/Articles/139787/What-s-the-Difference-between-WCF-and-Web-Services
What is the benefit to keep the WCF project having - WEB HOST PROJECT and Service Implementaiton project separately.
Service contract library
Service implementation library
Service Host project
I understand Contract and Implementaiton to keep separate will helpful for SOC principal and allow to use into other application also if require to implement interfaces.
But,I am not understand why to keep - Service Host and Service Implmentation project separately.
I went through below link, but not understand the benefit of keeping this separate.
http://www.devx.com/codemag/Article/39837 (Page 4,5)
If any one guide here then, it is helpful.
Thank You
As the article said:
Decoupling the services from the host lets you host your services in whatever type of host you want, and to change that host any time. Now, the host could be an IIS application, Windows Activation Services, or any self-hosting application including console applications, Windows Forms applications, Windows Services, etc. - WCF the Manual Way…the Right Way : Page 3
Test mocking, though important, arguably applies to most things programming wise. What is more useful here however is how service separation helps to deploy said services in production, not how it helps developer-level testing. The latter is only useful for a short time period compared to the operational life of the system in production where operations staff may change how the service is hosted. Operations, from an ALM perspective, continues way after SDLC completes.
Though off topic here, one can go further and decouple service logic itself not only from the service's contract but also from anything WCF-related. As mentioned in Thomas Erl's book SOA Design Patterns -
Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract. - Service Façade
Keeping the WCF implementation and WCF host process separate allows you to change how it is hosted later
Advanced: Keeping the WCF implementation and service processing logic separate ensures the latter is free to change without impacting users of the exposed service contract
In addition to Micky's answer, I give you some examples of deployment.
1. If you are going to host the service in IIS, you don't need the Service Host project, since IIS/WAS/.NET runtime will created a service host for you upon the first client request.
2. If you want to host the service in Windows service or a console app, you may create the service host in the Window service project or the console application project, because there will be just a few lines of codes for creating Service Host, unless you have complex logic of managing service host.
This may not be new, but I hope some one can put me on right track as its bit confusing during azure deployment. I'm in the process of planning for deployment on Azure. This is what I have
A Public facing ASP.Net MVC app (web-role) + WCF Service (web-role) to be accessible only to this asp.net app + WCF Service (worker-role) again accessible to 1. over message-queue
An Custom STS i.e. ASP.NET MVC app (web-role) acting as Id-Provider (for 1. which is a Relying Party) + WCF Service (web-role) to expose some of STS funcionality to RP's such as 1.
SQL Azure: accessed by 1 and 2
Note: 1. will eventually grow to be come a portal, with multiple wcf-services hosted on web and worker roles for both internal and external access.
My question is if 1. is going to be the app exposed to public, and 2. is for 1. to Federate the security (internal), how should I plan my deployment on azure keeping in mind 1. will require scale-out sometime later along with the two wcf services? Do I publish to one cloud service or how?.
My understanding is that A Cloud Service is a Logical Container for n-web/worker roles.
But when yu have 2 web soles like in this case both asp.net apps, which one becomes the default one?
Best Regards
Satish
By default all web roles in the solution are public. You can change this by going into the service definition and remove HTTP endpoints, if you wish; you can also define internal HTTP endpoints that will only be available to cloud services, nothing will be exposed to the load balancer. The advantage to having all web roles in the same project is that it's easy to dynamically inspect the RoleEnvironment and each web role -- in other words, all roles in a solution are "aware" of other roles and their available ports. It's also easy to deploy one package.
All roles share the same DNS name (.cloudapp.net) (however you could use host headers to differentiate), but they are typically exposed by using different ports via the load balancer on your .cloudapp.net service. You can see this when the service is running in the cloud, there are links in the portal that point to each role that has a public HTTP endpoint that specifies the port. The one that is port 80 (as defined by the external HTTP endpoint) is the "default" site.
You could also create multiple cloud projects, and deploy them separately. In this case, each would have its own DNS name, and each is managed separately. Whether this is a good thing or not depends on how tightly coupled the applications are, and if you will typically be deploying the entire solution, or just updating individual roles within that solution. But there's no cost or scalability difference.
If you are going to frequently redeploy only one of the roles, I'd favor breaking them out.
To deploy multiple Web Roles under the same cloud instance have a look at this:
Best practice for Deployment of Web site into a cloud service
Multiple worker roles will be trickier to implement:
Run multiple WorkerRoles per instance
I have an existing set of singleton WCF services. They are long-running processes that do a lot of work on an ongoing basis and expose themselves with WCF service contracts for communication with other processes.
When the WCF Web API was being developed I was excited because it was looking like I'd finally be able to do away with all of the annoying contract stuff and simply provide a platform-agnostic REST API for each service and have the processes communicate via HTTP requests and JSON responses.
Now it looks like the Web API has become an IIS-hosted ASP.Net feature, leaving me trying to figure out if I'm just missing something or if my WCF services will no longer have the opportunity to provide a REST interface.
If the Web API is no longer really targeted at my scenario, what has the ASP.Net team envisioned with respect to non-terminating singleton processes that wish to provide an HTTP/JSON-based API to other consuming processes?
You do not have to host ASP.NET Web API services in IIS. There is an option called "Self Hosting" that will allow you to host your API services in another process (such as a Windows Service) if you would like. I imagine that your current architecture would work just fine as a self-hosted app.
You can self-host using ServiceHost as in this MSDN example. See related SO post. Essentially - IIS is not a requirement for WCF hosting.
If you are using webHttpBinding - you just need to create the WebServiceHost which extends from ServiceHost to support REST.
I'm new to .Net and do not understand the difference. Can someone point me in the right direction?
ASP.NET Web services was developed for building applications that send and receive messages by using the Simple Object Access Protocol (SOAP) over HTTP.
WCF is for enabling .NET Framework applications to exchange messages with other software entities. SOAP is used by default, but the messages can be in any format, and conveyed by using any transport protocol.
You can view ASP.NET web services as a subset of WCF services.
Here is a link comparing the two frameworks.
it is quite easy to know the differences.
ASP.NET Web Method is called ASMX [because of the file extension] (check 4GuysFromRolla about this, they have a good tutorial)
That technology makes you expose functions as a Web Service so you can connect it from everywhere and use it. But... you can't protect the data between server and client, you can send big files clear and know what happend, etc...
[Note] you can protect the access to the web service using certificates, but it is complicated but normally, in ASMX we use username / passsword.
in WCF, you are in the different world about Web Services,and this s the best technology in .NET to expose Services (can you see the difference... Services! not Web Services), WCF does not need IIS to run, it can run as a System Service on the server, using a console ambient (like command line), etc, so we say that WCF is a Service not Web Service. Remember ASMX need IIS to run.
with WCF you can use SSL to encrypt the communication (to do that in ASMX you need to use WSE - Web Services Enhancements), you can send big files and securely (to do that in ASMX you need to use MTOM - Message Transmission Optimization Mechanism).
you can set the transmission preferences just changing one line of code, the security is much higher, etc, etc :)
hope you get a better general overview with this, but there is much more.
bottom line: to expose Web Services that you do not need to protect, you can use ASMX, no problem at all, but if you need to protect the communication somehow, do it in WCF!
link: you can read here some performance comparative between the 2 services
They are two different frameworks for writing services. WCF is generally more flexible and provides configurable options for what protocols are used, how the service is hosted and a variety of security options. ASMX offers SOAP based services. Generally WCF is also more performant. In general ASMX is easier to use and generally has less of a learning curve.
Here is a MSDN forum discussion on the topic.
Here are the getting started pages for ASMX and WCF.
In addition to the above responses, WCF was created to replace .NET Remoting in .NET 3.0 and beyond. In addition to SOAP, REST, POX, etc. web services in various formats (e.g. XML and JSON), WCF also offers MSMQ and Named Pipes. ASMX, as mentioned above, provides only SOAP-based XML web services.
You would need to delve into .NET Remoting for other types of communication protocols. For additional information, you should check out Pro C# 2008 and the .NET 3.5 Framework. It's a great resource, and you can get the chapters from the previous books that cover .NET Remoting, and other replaced features.
Here's a new, big, difference: Microsoft now considers ASMX web services to be "legacy" technology. See "XML Web Services Created Using ASP.NET and XML Web Service Clients".
Web Services
It Can be accessed only over HTTP
It works in stateless environment
WCF
WCF is flexible because its services can be hosted in different types of applications. The following lists several common scenarios for hosting WCF services:
IIS
WAS
Self-hosting
Managed Windows Service
They are two different things all together. WCF is a more generic framework through which you can write one service type component and deploy it in many ways (even as an Asp.Net Web Service).
Here's a brief thread about this http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/2d6a7ff2-f15c-4599-a389-a81cfffcc852/
I had the same problem.
I found the book Microsoft Windows Communication Foundation Step by Step to be really good.
If you just want to do the traditional webservice thing using WCF, then Chapter 1 of that book will show you exactly how to do that (write service, test, deploy, use service).
Its written for VS2005, but I'm using vs2008 and found it even easier.
There's a lot more to WCF, but that book is a good start.
Main Differences between Web service and WCF are listed below.
Web Service : Web Service is an application that is designed to interact directly with other applications over the internet.
1) [WebService] and [WebMethod] attributes defines a web service and methods.
2) It Can be accessed only over HTTP.
3) Hosted in IIS.
4) Support security services.
5) Can not be multithreaded.
6) Only Used Soap or XML.
7) System.Xml.serialization name space is used for serialization
WCF :Windows Communication Foundation (Code named Indigo) is a programming platform and runtime system for building, configuring and deploying network-distributed services.
1) [ServiceContract] and [OperationContract] attributes defines a web service and methods.
2) Accessed through HTTP, TCP, MSMQ, P2P, Named pipes
3) Hosted in IIS, Self-Hosting ,WAS and Windows Service.
4) Can be multithreaded via service behavior class.
5) System.Runtime.Serialization namespace is used for serialization
6) Supports different type of bindings like BasicHttpBinding, WSHttpBinding,WSDualHttpBinding etc.
7) Support security services, reliable messaging, transactions, AJAX and REST Support