Monday, April 25, 2005

Day 1, Microsoft Zirvesi 2005

Here's about the sessions I attended on the first day of the event. This is very rough. It is just a sketch of my memoirs. I'll try to finish it later and improve it so that it can be useful for someone else me. Beware!

Service Orientation and interoperability
Clemens Vesters

As always, Clemens is impressive. This is a brief summary of the talk:
Many applications are silos. We write applications and frameworks because we dont trust others with our data. No super

framework exists and never will be that would work for all problems and situations. The reason is that business keeps

changing and that is because everyone wants to be wiser tomorrow than today. Silos make sense to software vendors but not to

users. For example, a medical professional at a hospital may have to enter patient data into four differnet applications.

This may seem necessary to the IT department because they bought four different applications for different purposes. But this

doesnt make sense to the user. Productivity is suffering and productivity enhancement is the software developer's job, not

the users. Information gathering is error prone and in this situation replicated information gathering is bound to cause

A CEO can request a quarterly report of how well his business is doing, but can not expet an answer if he asks this question

at any arbitrary time of year. The goal of interoperability is users talking to applications and applications talking to each

other at the same time.
Services: Services are a deployment level reuse, not just source code reuse. An application becomes unusable in a maximum of

3 to 5 years, because of all the hacks and quickfixes that we apply on it to fix problems which makes it unmaintainable. It

is easier to just throw it out the window and re-write it.
Where did the word application come from? An application of certain technology to a certain problem.
A System wires applications together.
A Service exposes functionality/capability of an application allowing programatic access. The word service has many different

meanings, which you can discover by asking different people what it means or doing a web search for it and you will find many

different definitions. A service is about evolution and coupling.
Elements of architecture:
These are all independent of each other
Edges: Everything talking to the outside world, e.g., SOAP, RPC, DCOM, RMI DCE etc.
Protocols: The rules governing the communication.
Platforms: For example, Biztalk Server, implementation languages like C#, and the runtime.
Control Flow: Request response etc.

The art of architecture is to find the right mix of the above elements. Service orientation only talks about the edges.
Every object oriented thing has three layers, the public methods, the implementation, and the other things that the

implementation talks to.
Tenets of service orientation:
PEACE(Policy-based compatibility, Explicitness of boundaries, Avoid coupling, Contract and schema Exchange.
Services control the contract, they can change and evolve. Tip: Never expose a .NET dataset as the only interface to a web

service. .NET clients would be very fast, but a Java client, for instance, would not be able to use it easily.
SOA Service:
Explicit boundaries
Contract and Schema
Autonomy is an architectural idea, autonomous computing relies on state management. Service orientation and architectre are

two different things. There is no such thing as Service Oriented Architecture. For example, you can put a web service on top

of a legacy system, exposing it as a service, but it would be a bad architecture.
Monologue: WS, WSDL are always a command-like thing. One software entity tells another what to do and it does it. It is not a

For service orientation, there is a design time contract and a runtime contract. Internal policies on two different

organizations may be different and a common ground would need to be found, for example, using Kerberos for authentication if

it is supported on both sides. The programmer does not have to worry about that. The total contract is the design-time

contract and the runtime contract.
SOAP has a header and a body. The applications deal with the SOAP body and the infrastructure deals with the SOAP header.

Contract exchange can be peer-to-peer or UDDI based (which is rare). AUtonomous services dont pass around references or

primary keys to tables so that the other side can query data on its own, but pass the actual data.
Stacking is another architectural issue, where you have a federator and several data stores, for example. The federator

contains nothing but the partitioning logic. Services can be moved around easily.

.NET vs J2EE comparison by Abdel Malek Kemmou
The comparison can be done at various level. At the language level, you can compare any .NET language with Java. The speaker

chose C#. Attributes are a way for you to evolve the language on your own. For example, you can have an attribute above a

string variable that defines that the string can only have alphabets in it and can be a minimum of 5 characters and a maximum

of 24.
Check out .NET Powered for an independent comparison between Java and C#.
As far as J2EE platform independence is concerned, there are some minor issues such as threading can not be dealt with cross

platform, because different platforms deal with threading differently. Also, rendering and event management is different. If

you are using EJBs, these are less platform independent because vendors always do extensions beyond the specifications, so it

depends on your application server etc and porting from one application server to another is not transparent. If you are

doing something like distributed transactions, you are tied with one application server.
On ASP.NET vs JSP, the idea of MVC or Model, View, Controller is there on ASP.NET as optional to some extent, with the code

behind file. The UI Process Application Block from Microsoft implements the complete MVC.

Indigo by Clemens Vesters

Channel architecture is an abstraction over all different transport protocols such as MSMQ and web services.
Service Programming Model is built over the channel architecture, which means that one consistent API whether you use

reliable messaing or whatever other mechanism.
System.Services is the namespace to use. Indigo comes with WSE 2.0. Indigo is going to make it really difficult for average

developers from making mistakes.
WSDL contains:
PortTypes, which has to do with "I need these inputs and I give these outputs"
Binding: Protocol such as SOAP
Services: Deployment thing
Binding properties: Transport, timeouts etc.

Endpoint: ABC (Address, Binding, Contract)
System.ServiceModel is the new namespace to work with.
How to work with Indigo?
Define an interface, implement it in a class such as
class Math : IMathWizard
On the interface definition use the [ServiceContract] attribute, on the methods use [OperationContract] attribute. Without

this, the method will not be exported to the outside world.

ChannelFactory generates channel/proxy

Proseware by Clemens Vasters
Proseware is another book merchant. It is different in the way it is implemented from Duwamish. It demonstrates a number of

conepts such as service orientation, web services, messaging etc. It is not a free download. It is Microsoft property and is

only given to those who attend a three day workshop designed around Proseware.
A catalog service owns the WSDL only, the inventory service implements the WSDL. Catalog and inventory services all push data

only and work better with a queue instead of request/response. Some parts of the system work request/response.

Then we attended the INETA Turkey meeting, which was mostly in the Turkish language so we couldnt do much, but we did participate here and there and gave our email addresses for a mailing list.
After that, we went to a concert nearby for the conference delegates. Microsoft gave this funny looking orange blanket type thing to the delegates as it was getting very very cold. Most songs were in Turkish or French, but some were in English, too. People smoke too much here and I cant stand that. Even in the open stadium, I was bothered and just snuck out for the maghrib prayers. After I returned, I took my sandwich, which Edgar had kept for me and the Coca Cola and we hit the road back to the hotel to surf for a while at StarBucks.
End of day.

No comments: