Does Astoria Service Model only support
ATOM,JSON,XML,XML+HTTP
Are formats like SOAP,WSDL,ASMX outdated? .So when i wish to develop SOA can i ignore SOAP,ASMX,WSDL formats?
I would add to the above answer and say there is in-fact a way to discover the metadata about the Data Services (REST) endpoint. Every endpoint includes a service document (just do a GET on the root of the endpoint) that describes the sets exposed by the service. Further, going to the $metadata endpoint from the root of the service (i.e. http://mydomain/myservice.svc/$metadata) returns an XML metadata document that fully describes the service (the sets, types, properties on types, relationships between sets, and service operations).
No, most definitely not!
ASMX = ASP.NET webservices - this is outdated, it was introduced in .NET 1.0 and basically replaced with WCF in .NET 3.0.
BUT: WCF is definitely NOT outdated! WCF is the Microsoft standard way of communicating between two systems. It uses SOAP (including WSDL and XSD) by default, and this is mature and reliable technology which works well in enterprise scenarios where you need things like data integrity, (human and machine readable) service description through WSDL and service metadata, and so forth. SOAP also offers more advanced features like reliable messaging and transactional support.
REST / ADO.NET Data Services is a more lightweight, easier-to-get-at approach at exposing services, but it's lacking in many ways: there's no unified service description available, so you cannot really "discover" what methods and what datatypes the service offer; either you have knowledge yourself, or the service provider gives you a documentation in plain English, but there's no standard way of describing a REST service to the outside world (yet). Also, you don't really know ahead of time what kind of data that service might return - there's no XML schema to stick to - it's more of a "let's hit the service and see what comes back" approach which might work quite OK in some cases, but not really in larger scale, enterprise-style environments.
So to sum up: the SOAP (WSDL,XSD) vs. REST debate is ongoing, both have their reasons to be, and I don't see one of them replacing the other - they're supplanting one another.
Related
I have an ASP.NET MVC 3 application that I am currently working on. I am implementing a service layer, which contains the business logic, and which is utilized by the controllers. The services themselves utilize repositories for data access, and the repositories use entity framework to talk to the database.
So top to bottom is: Controller > Service Layer > Repository (each service layer depends on a single injectable repository) > Entity Framework > Single Database.
I am finding myself making items such as UserService, EventService, PaymentService, etc.
In the service layer, I'll have functions such as:
ChargePaymentCard(int cardId, decimal amount) (part of
PaymentService)
ActivateEvent(int eventId) (part of EventService)
SendValidationEmail(int userId) (part of UserService)
Also, as an example of a second place I am using this, I have another simple console application that runs as a scheduled task, which utilizes one of these services. There is also an upcoming second web application that will need to use multiple of these services.
Further, I would like to keep us open to splitting things up (such as our single database) and to moving to a service-oriented architecture down the road, and breaking some of these out into web services (conceivably even to be used by non-.NET apps some day). I've been keeping my eyes open for steps that might make make the leap to SOA less painful down the road.
I have started down the path of creating a separate assembly (DLL) for each service, but am wondering if I have started down the wrong path. I'm trying to be flexible and keep things loosely coupled, but is this path helping me any (towards SOA or in general), or just adding complexity? Should I instead by creating a single assembly/dll, containing my entire service layer, and use that single assembly wherever any services need to be used?
I'm not sure the implications of the path(s) I'm starting down, so any help on this would be appreciated!
IMO - answer is it depends on a lot of factors of your application.
Assuming that you are building a non-trivial application (i.e. is not a college/hobby project to learn SOA):
User Service / Event Service / Payment Service
-- Create its own DLL & expose it as a WCF service if there are more than one applications using this service and if it is too much risk to share the DLL to different application
-- These services should not have inter-dependencies between each other & should focus on their individual area
-- Note: these services might share some common services like logging, authentication, data access etc.
Create a Composition Service
-- This service will do the composition of calls across all the other service
-- For example: if you have an Order placed & the business flow is that Order Placed > Confirm User Exists (User Service) > Raise an OrderPlaced event (Event Service) > Confirm Payment (Payment Service)
-- All such composition of service calls can be handled in this layer
-- Again, depending on the environment, you might choose to expose this service as its own DLL and/or expose it as a WCF
-- Note: this is the only service which will share the references to other services & will be the single point of composition
Now - with this layout - you will have options to call a service directly, if you want to interact with that service alone & you will need to call the composition service if you need a business work flow where different services need to be composed to complete the transaction.
As a starting point, I would recommend that you go through any of the books on SOA architecture - it will help clear a lot of concepts.
I tried to be as short as possible to keep this answer meaningful, there are tons of ways of doing the same thing, this is just one of the possible ways.
HTH.
Having one DLL per service sounds like a bad idea. According to Microsoft, you'd want to have one large assembly over multiple smaller ones due to performance implications (from here via this post).
I would split your base or core services into a separate project and keep most (if not all) services in it. Depending on your needs you may have services that only make sense in the context of a web project or a console app and not anywhere else. Those services should not be part of the "core" service layer and should reside in their appropriate projects.
It is better to separate the services from the consumers. In our peojects we have two levels of separation. We used to group all the service interfaces into one Visual Studio project. All the Service Implementations are grouped into another project.
The consumer of the services needs to reference two dll but it makes the solution more maintainable and scalable. We can have multiple implementations of the services.
For e.g. the service interface can define a contract for WebSearch in the interfaces project. And there can be multiple implementations of the WebSearch through different search service providers like Google search, Bing search, Yahoo search etc.
The intent is to create a set of web services that people can reuse. These services mostly interact with a backend DB creating, retreiving and processing data.
We want to expose services so that people can use to create data mashups and other applications.
End users are webpages that can be within our domain or outside our domain. For pages outside the domain we plan to release widgets that would be configured to retreive and display the data.
One requirement - application should be extremely scalable in terms of the number of users it can handle.
Our code base is .net and we are looking at ASPX webmethods (or ASHX), ASMX webmethods and WCF (starting to read up on WCF).
In terms of security/access I found that maintaining sessionid, memberships is doable in all three. WCF seems a bit complicated to setup. I could not immediately see the value of asmx when we can get all done just using a webmethod in aspx (with a little tweaking).
Also, assuming that with the ASP.NET MVC2 I might be able to get clean urls as well for these webmethods.
Questions
Which one will be the most effective in terms of performance and scalability?
Any reason why I should choose WCF or ASMX?
Thank you for taking the time to read through this post and apologies for the naive questions since I am new to .net.
EDIT I kind of understand that WCF is the way to go. Just to understand the evolution of the technologies it would be good if someone can throw light on why a aspx webmethod is different from an asmx when similar things (apart from discovery) can be accomplished by both. The aspx webmethods can be made to return data in other formats (plaintext, json). Also, it seems that we can build restful services using ashx. Apologies again for the naive questions.
You should use WCF for developing webservices in .Net. WCF is highly configurable with many options for security, transport protocols, serialization, extensions etc. Raw performance is also significantly higher. Also WCF is being actively developed and many new features being added in version 3.5 and 4. There are also variations like WCF data services and WCF RIA services. WCF 4.0 also has better REST and JSON support which you can directly use in ASP.Net / JQuery.
ASMX is considered deprecated technology and replaced by WCF. So if you are going to start new development which requires exposing reusable services, WCF is the way to go.
I am not necessarily disagreeing with previous answer. But, from a different perspective, WFC is tricky to configure. It requires bindings, endpoints, packet sizes, a lot of confussing parameters, etc in your configuration files, and there are many serialization/deserialization issues reported. Also WCF is a relatively new technology (therefore still exposed to bugs and patches needed).
The client-generated [Reference.cs] files might have unwanted interfaces, and each public property client class exposed in the WSDL gets generated with the same observer pattern that LINQ to SQL or Entity Framework uses ( OnChanged, OnChanging, etc) so this adds a lot of fat to the client code, as opposed to the traditional SOAP Web client way.
My recommendation, if you aren't using Remoting over TCP or if you don't need the 2-way notification mechanism for remote changes - all these are very cool features of WCF - you don't need to use it.
I've read lots of articles about Service Oriented architecture.
Is there any real world sample application which is imeplemented in ASP.NET?
Thanks
The short answers is: not that I know of.
The other thing to keep in mind (which you're probably already aware of) is that the level of abstraction is very important.
One one level, the "Service" in SOA is Business Service - not a technicial service like a web service; in fact at this level the idea of implementation is completely irrelevant. This is more at the Enterprise Architecture and Buisness Architecture level.
Lower-down, there's what you might call Service Orientated Design, where software systems are built in a way that is service based - it offers something that is easily consumed by other systems (or consumes a service in much the same way). Even at this point we're not talking about implementation specific things like technologu - it's just more of a mindset - how the system is arranged (the architecture).
The next level down is where software systems offer services as physical end-points that are defined by an address, binding and contract (The ABC of SOA).
At this level you will be able to find implementations; NServiceBus comes to mind (not that I have used it) - but you don't need a service bus to do "Service" orientated architecture.
Finally, I'm not sure exactly how you view ASP.NET in the context of your question. If you're .Net based then WCF is the place to start looking; one of the binding types is a web-service, which being web-based kind of comes under the umbrella of ASP.NET. Alternatively if you're building a website or web-application then the services that the application offers or consumes would be located in a data access or services layer - loosely-coupled to the Business Logic (BL) layer - so they aren't actually directly related to the fact you're doing a web-application at all, as this architecture woudl work for different kinds of application (not just web).
I am aware of Web Services and WCF but I have generic question with services.
I have a ASP.NET MVC Application which does some basic functionality. I just have a controller in which I am passing it the records and serializing the information to XML using XML Serializer. Then I return this information to the browser and it displays me the XML i got from the Controller Action. So I get the XML representation of my Class(Database Object) in XML and I am to give the URL of this application to the client and access and pull the information.
Is this a Service then?
I mean in the end all the Clients need is the Xml representation through services also right? I am not that experienced and probably being very silly but please help me out...if I provide xml this way to the client is that a Service? Or is there something I need to understand here?
Don't let all the buzz about "web services" fool you; the basic idea behind a web service is very, very simple. It is simply a matter of providing data in response to a request over standard web transport protocols (i.e., HTTP/HTTPS). Everything else (XML, SOAP, WSDL, etc.) is just layered technology to augment the basic functionality of a service. REST-based services are very basically the simplest services that you can build--they are built on the core HTTP/S transport protocol and not much else.
The main differentiator between a service and traditional web site is that a service is data-focussed rather than presentation-focussed; that is, services typically are not concerned with how data is formatted and displayed (that is up to the client), but rather what data is returned. So...you are delivering XML data over HTTP? Check. You have a service. Congratulations!
Yes, it is a service, returning an XML resource. Also it seems that it is accessible throught standard HTTP verbs such as GET, so one might assume it is RESTful. The difference with a standard SOAP XML service is that you don't have a WSDL that describes it, so you might need to provide a good documentation to clients wishing to consume your service.
I used to create normal webservices in my websites, and call these services from javascript to make ajax calls.
Now i am learning about Ado Data Services,
My question is:
Does this Ado Data Services can replace my normal webservice in new sites i will create?
And if Yes,
Can i put these Ado Data Services in a separate project "local on the same server" and just reference from my website? "to use the same services for my websites internal use and also give the same services to other websites or services, the same as twitter for example doing"
depends what you want to do , I suggest you read my conversation with Pablo Castro the architect of Ado.Net Data Services
Data Services - Lacking
Here is basically Pablo's words.
I agree that some of these things are quite inconvenient and we're looking at fixing them (e.g. use of custom types in addition to types defined in the input model in order to produce custom result-sets). However, some others are just intrinsic to the nature of Data Services.
The Data Services framework is not a gateway to a database and in general if you need something like that then Data Services will just get in the way. The goal of Data Services is to create a resource model out of an input data model, and expose it with a RESTful interface that exposes the uniform interface, such that every unit of data in the underlying model ("entities") become an addressable resource that can be manipulated with the standard verbs.
Often the actual implementation of a RESTful interface includes more sophisticated behaviors than just doing CRUD over the data under the covers, which need to be defined in a way that doesn't break the uniform interface. That's why the Data Services server runtime has hooks for business logic and validation in the form of query/change interceptors and others. We also acknowledge that it's not always possible or maybe practical to model absolutely everything as resources operated with standard verbs, so we included service operations as a escape-hatch.
Things like joins dilute the abstraction we're trying to create. I'm not saying that they are bad or anything (relational databases without them wouldn't be all that useful), it's just that if what's required for a given application scenario is the full query expressiveness of a relational database to be available at the service boundary, then you can simply exchange queries over the wire (and manage the security implications of that). For joins that can be modeled as association traversals, then data services already has support for them.
I guess this is a long way to say that Data Services is not a solution for every problem that involves exposing data to the web. If you want a RESTful interface over a resource model that matches our underlying data model, then it usually works out well and it will save you a lot of work. If you need a custom inteface or direct access to a database, then Data Services is typically not the right tool and other framework components such as WCF's SOAP and REST support do a great job at that.