Services vs Web Services

A comon misconception  is that SOA == Web Services or Services == Web Services. As clemens puts it, Web Services provide the P, E & CE of PEACE. If we design a web service with A then it becomes a Service. So simple isin’t it. Provided you understand Autonomy 😉

 

http://staff.newtelligence.net/clemensv/PermaLink,guid,0339fe35-2328-44be-93e6-f004bd869a84.aspx

 

SOA Tenets – Contract Exchange

Services exchange Schema and Contract. This one is easier to grasp like the Policy based negotiation one. Services could be implemented and a variety of platforms and consumed in a varierty of platforms. So when it comes to sharing the contract or the data to be exchanged between them, which "type system" should one use.

 

Type System??? Should it be the Provider’s or should it be the Requester’s? Should it be System.DateTime or should it java.Utils.Calendar.

 

SOA means that use contracts and schmea instead of assemblies / types etc. WSDL / XSD help in this area. 

SOA Tenets – Service are autonomous

From channel 9 Wiki http://channel9.msdn.com/wiki/default.aspx/Channel9.ServicesAreAutonomous

• Services should be deployed, managed and versioned independently of other services and / or applications that depend upon them. 
• Services should not trust any incoming messages. All messages should be validated for integrity and appropriate credentials.
• High availability of services should be ensured using a fully redundant network infrastructure that supports automatic failover etc. 
• Careful consideration for capacity planning should be made to ensure appropriate provisioning of resources necessary to support services.
• Services expect that the consuming application can fail without notice and often without any notification. To maintain system integrity techniques such as transactions, durable queues, and redundant deployment and failover should be utilized. (The same applies to services used by the service as well)

Does Autonomy mean that a service should never depend on other service (Isolated). The very idea of services is colloboration, this tenet seems to contradict it. But actually it doesn’t

Turner says it all here:

http://blogs.msdn.com/richardt/archive/2005/05/20/420650.aspx

 

Say a service that you use is down, you should be able to use an alternate service which could do the job for you. Or you could queue the requests till the service is up etc. In other as Truner puts it "services wont be welded together, they are better of if they are plugged together".

SOA Tenets – Service Boundaries are Explicit

Well this one is slightly harder to understand, anyway here is my take:

One interpretation is, Crossing service boundaries may be costly, depending upon geographic, trust, or execution factors. This is mainly due to

• The physical location of the targeted service may be an unknown factor.
• Security and trust models are likely to change with each boundary crossing.
• Marshalling and casting of data between a service’s public and private representations may require reliance upon additional resources—some of which may be external to the service itself.
• While services are built to last, service configurations are built to change. This fact implies that a reliable service may suddenly experience performance degradations due to network reconfigurations or migration to another physical location.
• Service consumers are generally unaware of how private, internal processes have been implemented. The consumer of a given service has limited control over the performance of the service being consumed.

Since crossing service boundaries is explicit, services should make this explicit by using messages for communication instead of trying to hide the boudary crossing by imitating a distributed RPC. RMI, Remoting, DCOM take the later route.

A message style communication looks like this (via Rich Turner):

Channel chan = new ChannelFactory.CreateChannel(endpointAddress);
ActionInvocationMessage msg = new ActionInvocationMessage();
msg.Action = "SayHello";
msg.Parameters.Add(new StringParameter("Forename", "Rich"));
msg.Parameters.Add(new StringParameter("Surname", "Turner"));
Console.WriteLine(chan.SendMessageSync(msg, new SayHelloCallback(HandleResponse)));

An RPC Style communication looks like this:

HelloWorldProxy proxy = new HelloWorldProxy(endpointAddress);
Console.WriteLine(proxy.SayHello("Rich", "Turner"));

Obviously a hello world doesn’t need to be a service and hence the messaging style communication looks awkward. But you should understand explicit message passing now 😉

A corrollary to this tenet or another interpretation of the tenet is "A service with well defined boundaries should provide no visibility to the internal implementation of the service. This allows a services implementation to be versioned without breaking external systems."

For Example "Service implementation details such as internal database row identifiers commonly found within a dataset should not leak outside the boundary of the service. "

More stuff here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/SOADesign.asp

http://channel9.msdn.com/wiki/default.aspx/Channel9.BoundariesAreExplicit

SOA Tenets – Policy based negotiation

Today as you develop components which are going to used by others lot of the assumptions are implicit or they communicated by out of the band techniques.

 

Suppose your component requires Kerberos authentication it is an implicit assumption most of the times.

Or in most of the cases it is spread through the word of the mouth or stated some where in the documentation.

 

Say your app server exposing the components is down today midnight 12:00 till tomorrow morning 12:30 AM, you probably send out an e-Mail to the users of the component stating the fact. This works if you are using the component within the organization and you know all the users of your component.

 

If your service is hosted on the WWW and you don’t know who the hell is using it. How do you communicate such an information to all the users of the service. How do you make it clear to the service users that your service requires Kerberos authentication tickets.

 

These need to be negotiated using standard means if you are thinking services.

WS-Policy* specs are trying to fill this void.

 

WSPL by OASIS and WSDL 2.0 Properties and Features are other approaches to fill the void. Soon the Service community will converge on to a single standard.

 

So WS-Policy helps the Service Provider and the Requester to negotiate stuff like:

• The endpoint is down for maintenance each Sunday morning from midnight until 2:00 AM.
• Orders must be received within 30 minutes of their timestamp. Orders delayed in transmission more than 30 minutes will be discarded, and the application may return a Fault.
• US dollars and euros are the currencies supported by the service.

Hope this makes the ‘P’ of PEACE clear. Bye till we talk about the ‘E’ in the PEACE.

 

SOA Tenets

The core tenets of OOP are

Abstraction

Encapsulation

Inhertiance

Polymorphism

 

Likewise the core Tenets of SOA are

Policy based negotiation

Explictness of service boundaries

Autonomous services

Contract Exchange

 

PEACE – Easy to remember. The PEACE acronym was coined by Clemens.

We’ll see each these tenets in the coming entries.

SOA, The next stage in the evolution

Well SOA is one topic which you cannot keep away from long enough, if you are blogging on technology.

SOA is a natural evolution in the mainstream development.

 

Early days: When systems were seldom connected and used to function in isolation

Ad Hoc programming

Structured Programming

Object Oriented Programming

 

And then:

When systems were connected through LANs and applications used to colloborate within organization boundaries. The systems made a lot of assumptions about each other. Most these assumptions were implied and not stated explicitly.

Component Based Programming – MTS/COM+, EJB etc

 

The future:

When systems are connected through the WWW and aplications colloborate across orgranization boundaries, It is natural that Services hit the mainstream.

 

Service Oriented Architetcure:

Service Oriented Architecture is an architectural style which provides the ability to provide functionality in the form of services. These services communicate by messages and contracts, and implement business functionality, policy and hold state.

Well that’s so abstract isn’t it. We’ll refine this as we go along.

 

The SOA shift was explained by Don Box using a very simple example. Simon Guest has blogged Don Box’s words in a nice blog entry. Instead of going through it all over again, lemme just link to it.

 

So SOA is all about removing the intimacy between systems and  making assumptions and boundaries explicit.

 

 

 

Data Transfer across tiers in .NET

My cyber pal was speaking about Datasets and Typed Datasets. I had used these material as reference till date.

May be its a good idea to book(blog)mark them in this entry.

 

I found this comparison on Typed Datasets, Datasets and Custom DTOs helpful.
Choosing Data Containers for .NET Parts 1, 2, 3, 4 and 5.
http://www.informit.com/articles/printerfriendly.asp?p=31099
http://www.informit.com/articles/printerfriendly.asp?p=31325
http://www.informit.com/articles/printerfriendly.asp?p=31457
http://www.informit.com/articles/printerfriendly.asp?p=31672
http://www.informit.com/articles/printerfriendly.asp?p=99034

I agree that it’s a slightly longer read, but worth the time.

 

In essence this was his conclusion:

	Performance in AppDomain/Cross- Machines	Scalability in AppDomain/Cross- Machines	Productivity	Maintainability	Interoperability
DataReader DataSet	5/1	4/1	2	1	1
	3/3	3/3	4	3	4
Typed DataSet	2/2	2/2	5	4	5
Wrapped DataSet	3/3	3/3	3	5	4
Hashtable	5/5	5/5	2	2	2
Custom Classes	5/5	5/5	2	5	3

 

What MS says :
Designing Data Tier components and passing data through tier
http://msdn.microsoft.com/practices/Topics/arch/default.aspx?pull=/library/en-us/dnbda/html/boagag.asp
.NET Data Access Architecture Guide touches upon the topic
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daag.asp

 

Hope you can find the answers there.

Answers to Scott’s questions – What Great .NET Developers Ought To Know

http://weblog.arkane-systems.net/2005/03/04/How+Great+Am+I+I+Of+III.aspx via Amit

Software Factories again

Software Factories EMEA Seminar session videos

http://weblogs.asp.net/israelio/archive/2006/03/22/440761.aspx