SOA defined

We can define Service-Oriented Architecture as an architectural style for building systems based on interacting coarse grained autonomous components called services. Each service expose functionality and behavior through contracts. Contracts are composed of messages at discoverable addresses called Interfaces.

Service. A Service should provide a high cohesion and distinct function. Services should be coarse grained pieces of logic. A Service should implement at least all the functionality promised by the contracts it exposes. One of the characteristics of services is service autonomy. Autonomy means the services should be self-sufficient, at least to some extent, and manifest self healing properties.

Contract. The collection of all the messages supported by the Service is collectively known as the service's contract.

Interface. The Interface is a URI, a specific place where the service can be found and consumed.

Messages. The communication mechanism in SOA is the message. Messages can for instance be

• http GET messages
• SOAP messages
• JMS messages
• and even SMTP messages

Messages must have both a header and a body. The header is usually more generic and can be understood by infrastructure and framework components without understanding, and consequently coupling to, every message type.

Service Consumer. This is the user of the Service. A service consumer is any software that interacts with a service by exchanging messages with the service. Consumers can be either client applications or other "neighboring" services their only requirement is that they bind to an SOA contract.

© Copyright 2007, Tomas Elfving

New to WSS 3.0 development?

Patrick Tisseghem has written a great introduction to Windows SharePoint Services 3.0 outlining the differences between traditional ASP.NET and WSS 3.0 development. He explains the required development environment, and the steps to build a Windows SharePoint Services solution with Visual Studio 2005 Extensions for Windows SharePoint Services 3.0.
Enjoy step 1 on http://msdn2.microsoft.com/en-us/library/bb530302.aspx and step 2 on http://msdn2.microsoft.com/en-us/library/bb530301.aspx!

© Copyright 2007, Tomas Elfving

MOSS Audiences aren't security objects

Don't use MOSS 2007 audiences as security objects. They are to be used for audience targeting only. You can target any list item or web part directly to a rule based audience. This enables rule based audiences to be created and maintained in the Shared service provider, while letting an individual site owner use these defined audiences on individuel sites.

Audiences are a global concept, whereas MOSS(Sharepoint) Groups are a relatively local concept. You might reuse the same audience across multiple portals, which will each have their own groups. There is sadly no way to define an audience rule based on groups. On most of the places where you use audience targeting, you can also use SharePoint Groups to target audiences.

Audiences are not used to assign rights and permissions. MOSS uses site groups to assign rights and permissions to users within the portal. Audiences are used to manage how content is distributed, not to enforce security. They push information to a user, not restrict or permit access to information.

© Copyright 2007, Tomas Elfving