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
trouble.
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.
State:
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:
Policy
Explicit boundaries
Autonomy
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
dialogue.
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:
Types
Messages
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.
ServiceHost