måndag, september 26, 2005

Superplattformen

Enligt Anne Thomas Manes på Burton Group kommer satsningarna på tjänsteorienterade arkitekturer dela upp marknaden mellan leverantörer av superplattformar, medan resten gör sig icke besvär.

Hon menar att de få (IBM, MS, Oracle och BEA) som kan stoltsera leverantör av superplattformen kommer att slå undan fötterna på mellanskiktet (Sybase, Iona, mfl) och låsa upp kunderna mot respektive leverantör för lång framtid.

Superplattformen är "sammanhållande" (cohesive) och måste bl a innehålla teknik och produkter för:
  • Portal Management
  • Process Management
  • Integration Management
  • Database Management
  • Operation Management
  • Registry Management
  • Security Management
  • Service Distribution Management

Jag vet inte hur väl det rimmar med att SOA ska vara en löst kopplad arkitektur av tjänster baserade på standardiserad teknik. Men det finns ju en verklighet att ta hänsyn till.

måndag, september 19, 2005

Implementera datatjänster med SQL Server 2005

I SQL Server 2005 kan du enkelt skapa en HTTP endpoint till dina lagrade procedurer. Varför inte ha tjänsterna så nära datat som möjligt? Nu finns ju även CLR och .NET Framework till förfogande även i SQL Server.

Anta att du ska implementera en tjänst som returnerar kundinformation. Då måste du först ha en lagrad procedur.


CREATE PROC dbo.spGetCustomerInfo
@CustomerId varchar(10)
AS
SELECT Name, Address, Phone
FROM tblCustomer
WHERE CustomerId = @CustomerId


Sedan skapar man bara en HTTP endpoint enligt:

CREATE ENDPOINT GetCustomerInfo
STATE = STARTED
AS HTTP
(
PATH = '/CRM',
AUTHENTICATION = (INTEGRATED),
PORTS = (CLEAR),
SITE = 'localhost'
)
FOR SOAP
(
WEBMETHOD 'GetCustomerInfo'
(NAME='CRM.dbo.spGetCustomerInfo),
BATCHES = DISABLED,
WSDL = DEFAULT,
DATABASE = 'CRM',
NAMESPACE = 'urn:local/crm'
)
GO


WSDL-filen hittar man under http://localhost/crm?wsdl som innehåller schema information som mappar till SQL:ens interna typer.

Workflow-motorns stöd

Antag exemplet i föregående blog. Det som karrakteriserar dessa flöden var att:

  • de spänner över tiden, ibland månader innan en lead resulterar i en leverans
  • anropar eller blir anropade från underliggande tjänster
  • består av tillståndsfulla instanser med egen information (exempelvis ett Lead)
  • kopplar samman delprocesser och mappar direkt till affärsflödet i verksamheten

Att implementera flödet utan hjälp från en workflow-motor är tidskrävande och svårt. En workflow-motor supporterar all den funktionalitet som implementationen av flöden kräver.

  • Flödesmodellering
  • Assynkrona anrop till/från tjänster
  • Tillståndshantering

Flödesmodellering
För att enkelt kunna jobba med processmodellen erbjuds gränssnitt där man enkelt kan skapa flöden, koppla samman dem med andra tjänster och även möjligheten att ändra beteendet i drift.

Assynkrona anrop till/från tjänster
För att stödja verksamhetens processer måste en workflow-motor kunna ta emot meddelande både vid start av en process, men även som händelser inne i en process. Ex. då en betalning i fakureringsprocessen kommer från en betalningstjänst.

Tillståndshantering
En workflow-motor måste kunna hantera tillstånd över tiden. En process ska kunna släckas ned för en tid och plockas upp då en händelse inträffar. Flödet bevaras med tiden och kan aktiveras av andra tjänster.

Stödet i en workflow-motor är bara en del av det som stöds i en ESB. Där ingår bland annat även support för:

  • Distributionshantering
  • Aktivitetsmonitorering
  • Transformeringar
  • Schemavalidering
  • Säkerhet
  • Skalbarhet

Exempel på processorienterad utveckling

Ett företag som säljer varor skulle kunna ha följande affärsprocess definierad för sin verksamhet.


En sådan process börjar med ett prospekt på en potentiell försäljning och slutar med en leverans. Processen är nedbruten i 4 andra processer; försäljning-, order-, fakturering- och leveransprocess. Anledningen till att man vill bryta ned processen i mindre delar är att skapa en flexibilitet i lösningen. Om verksamheten väljer att exempelvis byta ut en del mot en annan process så ska de andra inte drabbas av det.

Faktureringsprocessen är en delprocess i sammanhanget och definieras enligt flödesdiagrammet nedan. Varje process har ett gränssnitt, som i en SOA även kallas för en tjänst. Processen är alltså en tjänst och kan exponeras som t ex en web service. Indata till ett flöde är tjänstens anropsparametrar. För faktureringsprocessen blir det faktureringsunderlaget som är parameter. Faktureringsunderlaget kommer från orderprocessen.


I faktureringprocessen används bland annat en utskickstjänst. Den implementeras enligt flödet nedan. Innan en faktura skickas iväg så ska kundinformationen kompleteras. Därför anropas en tjänst som hämtar kundinformationen. Den tjänsten är en datatjänst, tillskillnad från en processtjänst som de två ovan är.

Flödet från försäljning ned till leverans och fakturering hanterar information och data som relaterar till entiteter i processen. Viss information hör till respektive instans av en process, medan annan information är global för alla instanser. Kundinformation kan förändras utanför processerna och ska därför inte ingå i processinformationen. Samma sak gäller varor, som också kan förändras med tiden. Därför så hämtar utskickstjänsten kundinformationen från en datatjänst (som exempelvis kan exponeras från ett CRM).

Det finns information som hör till en instans av en process. Fakturainformation är ett exempel på det. I den ingår kund- och produktinformation enbart som en relation (foreign keys), medan pris och fakturarader är exempel på information som verkligen hör till processinstansen. Nedan är kopplingen mellan processen och den information som hör till respektive instans:

Försäljningsprocess -> Lead
Orderprocess -> Order
Faktureringsprocess -> Faktura
Leveransprocess -> Leverans

fredag, september 16, 2005

Implementera datatjänster med LINQ

Project LINQ har fått enormt mycket uppmärksamhet efter PDC05. Med LINQ tar Microsoft ett steg närmare object-relational mapping och lämnar DataSet och tabeller som projektion på en relationsdatabas. Med LINQ kan man på lika smidigt sätt implementera en data service som du kunnat med DataSet, fast nu även med typinformation i kontraktet.

Har du skickat ett DataSet från en web service någon gång så kanske du lagt märke till att bara klienter som kan skapa just ett DataSet kan anropa din tjänst. Så här ser nämligen WSDL kontraktet ut:
<s:element name="GetMeetingRequestDSResponse">
<s:complexType>
<s:sequence>
<s:element
minOccurs="0" maxOccurs="1" name="GetMeetingRequestDSResult">
<s:complexType>
<s:sequence>
<s:element ref="s:schema" />
<s:any />
</s:sequence>
</s:complexType>
</s:element>
</s:sequence>
</s:complexType>
</s:element>

 


[WebMethod]
public DataSet GetMeetingRequestDS()
{
return new DataSet();
}
Typinformationen kommer i runtime och kan enbart konsumeras av ett DataSet. Det gäller även typade DataSet, vilket självfallet inte borde vara fallet eftersom typinformationen är känd i o m att det finns ett schema definierat.

DataSet är det idag enklaste och mest effektiva sättet att med Visual Studio och .NET Framework (Out Of the Box) skapa en datastruktur med innehåll från en relationsdatabas. Tyvärr så är det inte lämpligt att använda i en tjänstebaserad arkitektur, eftersom man inte bygger tjänster för att de ska konsumeras av en viss typ av plattform. Man vill ju ha ett teknikoberoende vilket man bara får om typerna som ska skickas över nätet kan definieras enligt WSDL.

En objektstruktur i .NET kan serialieras till en datastruktur som är kompatibel med WSDL. LINQ ger samma stöd som du får från DataSet för att populera en datastruktur fast för en godtycklig objektstruktur.

torsdag, september 15, 2005

WWF och BizTalk

Windows Workflow Foundation har äntligen sett ljuset och kommer att ge .NET-utvecklaren nya möjligheter att jobba processorienterat. Fördelarna med WWF är att den inte kräver varken SQL Server för persistens eller BizTalk Server, utan ingår som en del av .NET Framework. WWF är en BizTalk light och kommer enligt MS passa för att utveckla processorienterat på applikationsnivå.

I en SOA-värld så flyter applikationsmodellen ihop och blir inte lika tydlig som den varit. Tidigare har man kunnat definiera en applikation som en isolerad mängd moduler som enbart fungerar tillsammans i en helhet. I en SOA raderas applikationsbegreppet ut och ersätts av tjänster som kan byggas samman mha processer/workflows. Den konstruktionen har från flera håll i branschen definierats som en Enterprise Service Bus.

Så om applikationer inte är en del av en SOA, varför säger man då att WWF är anpassat för applikationsnivån. Förmodligen så kommer vi från olika håll se exempel på samma kritik mot MS för WWF och BizTalk som IBM fått för sin WebSphere ESB.

torsdag, september 08, 2005

Varför workflows?

Ingen säger det (och det) bättre eller så väl-timat som David Chappell.

Workflow workflow workflow

Den här web casten är en sammanfattning av vad Don Box och Dharma Shukla kommer att prata om på PDC. Missar du PDC men vill ändå vara uppdaterad i höst så är det här den Web Cast du inte får missa. Nu är process-centric development en nära verklighet för alla .NET-utvecklare.

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032280583&EventCategory=4&culture=en-US&CountryCode=US

Fler web casts i samma ämne hos Paul Andrew ...

måndag, september 05, 2005

Sammanfattning av BPEL

Den här artikeln rekommenderas från The Server Side .COM.

BPEL Learning Guide

Jag hittad en bra BPEL-guide som kan rekommenderas.

fredag, september 02, 2005

SOA och Data

SOA består av ett antal olika typer av tjänster. Själv ser jag tre stycken som är tydligare än andra, processer, data och interaktiva. Processer är tjänster som kopplar samman de övriga typerna och låter dom samspela (orchestrate). Datatjänster ger åtkomst till informationen som bearbetas i applikationen. Interaktiva tjänster är de som kräver männsklig dialog. För att dra en parallell till produktvärlden så är BizTalk Server ansvarig för processerna, SQL Server för datatjänsterna och Sharepoint/Exchange/InfoPath för interaktiva tjänster.

Processerna i sig hanterar också data. Men det datat är enbart information som är kopplat till processen och resten är nycklar till data som görs åtkomligt via daatjänsterna. En orderprocess skulle därför hantera orderinformationen, men ha nycklar till exempelvis kundinformationen som ligger åtkomlig genom datatjänster. BizTalk och andra produkter som kan agera processmotor kan hantera informationen som är knuten till processen genom stödet för persistens och long running transactions.

En SOA applikation som består av de tre delarna har sina egna tjänster för att fungera som exempelvis ett Customer Relational Management (CRM). Eftersom SOA kan skala till ett Enterprise så kan applikationen styra om sin dataåtkomst till att lagra datat centralt eller i en annan applikations dataservices. I en Enterprise SOA skulle det kunna finnas en Unified Data Model (UDM) som hanterar all dataåtkomst från alla applikationer. En UDM är även intressant i samband med Business Intelligence (BI) för att kunna skapa analyser av den totala informationsmängden. Tillsammans med information i processerna och Business Activity Monitoring (BAM) kan effektiva Key Performance Inidicators (KPI) ge aktuell och tidskritisk information som är viktig för verksamheten.



Samspelet mellan SOA och Business Intelligence kommer genom BAM och UDM skapa helt nya sätt att dra nytta av en flexibel arkitektur.

Människa datorinteraktion i en SOA

Även i en SOA kommer den människliga dialogen vara närvarande och kanske mer än någonsin. Människor kommer vara naturliga delar av de processer som ingår i applikationerna. Det kan antingen vara en användare som ska sätta igång en process, eller bara som en deltagare i ett steg i en process.

Vi är vana vid att skriva klientapplikationer i antingen Web-miljö eller som feta eller smarta klienter. Men det som delas mellan alla dessa är att de är mycket smartare än de borde vara. Ofta kodar man in flödeslogiken i klientapplikationer och inte bara de delar som interagerar med användaren. Det kan vara ett antal ASPX-sidor som anropar varandra med valideringsregler och ett flöde för att t ex mata in en kundorder eller uppdatera en kundpost. I en SOA så kommer vissa tjänster att exponeras till människor. En arkitektur där man flyttat logiken till processer kommer kräva ett nytt sätt att se på GUI.

Web Services for Remote Portlets (WSRP) är en OASIS standard som kommer att få stort genomslag bland GUI-utvecklare. WSRP definierar hur man ska bygga gränssnitt ovan på tjänster som ska interagera med användare. I en vanlig applikation är det interaktiva och flödeslogiken starkt ihopkopplat medan i en SOA är det löst kopplat. Antag en process för inköpsorderhantering. En anställd vill köpa något och hans chef ska attestera. Processen är flödeslogiken och är representerad av en tjänst, medan attesteringen hanteras av en annan tjänst.

Just nu byggs det portalservrar som är WSRP kompatibla för att kunna bygga upp snygga paketeringar av tjänster som kräver dialog med användaren. Microsoft har t ex Sharepoint Portal Server och InfoPath för att möta behoven i portalsammanhang. InfoPath kan även användas tillsammans med Exchange för att nå användarna då det kanske är mer bråttom i dialogen med användaren.

Vishet

Web Service Distributed Management (WSDM som uttalas 'wisdom') är en OASIS standard som kommer att få en stor betydelse i en SOA. Det mesta som har med tjänster i affärssammanhang att göra är på något sätt kontrakterat med ett avtal. Avtalet reglerar leverantörens och klientens skyldigheter och rättigheter. I IT-världen kallas det för Service Level Agreement (SLA) där leverantören deklarerar sina skyldigheter att kunna leverera tjänsten.

I en SOA kommer behovet att bli stort av den här typen av avtal eftersom systemen går från monolitiska komplexa applikationer där leverantören kan garantera en SLA för allt som händer inom applikationen till en arkitektur av sammankopplade mindre tjänster där många leverantörer ansvarar för sina tjänster. I en SOA måste en tjänst som inte kan hålla sin SLA, på grund av att en annan tjänsteleverantör inte levererar, styra om sin process mot en annan leverantör istället.

WSDM handlar om att administrera tjänster för att möte ett SLA. Ett exempel kan vara en leverantör av datorer som underkontrakterar leverantörer av komponenter. Datorleverantören har ett avtal med sin kund om kunna leverera produkten inom 10 dagar. Om då komponentleverantören inte hinner leverera måste en annan leverantör användas istället. Annars hinner man inte leverera inom 10 dagar.

torsdag, september 01, 2005

HelloBPEL

Många har säkert sett The Evolution of a Programmer och tyckte det var komiskt hur mycket kod man kan skriva för att få ut "Hello World" på skärmen. Här är Hello BPEL.

En SOA bygger på meddelanden, tjänster och processer och det gäller även om man ska implementera något så simpelt som Hello World. För att köra det här exemplet krävs en ESB (ex. CapeClear, ActiveBPEL).

Meddelandet
Vi börjar med att definiera meddelandetyperna i XML Schema även om man normalt sett börjar med processen och därefter meddelandena.

Hello.xsd



<?xml version="1.0" encoding="utf-8" ?>
<xsd:schema targetNamespace="http://swenug.com/bpel-demo/Hello.xsd"
xmlns="http://swenug.com/bpel-demo/Hello.xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">


I schemat skapar man typerna som ska ingå i ett meddelande.


<xsd:complexType name="HelloRequestType">
<xsd:sequence>
<xsd:element name="Name" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>


I det här fallet så definierar vi en typ för anropet och ett för svaret.


<xsd:complexType name="HelloResponseType">
<xsd:sequence>
<xsd:element name="Greeting" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>




Tjänsten
Tjänsten som deklareras i WSDL innehåller en import av meddelandetyperna, meddelandena själva, port, operation, address och bindning som tillsammans skapar tjänstekontraktet.

HelloService.wsdl



<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
targetNamespace="http://swenug.com/bpel-demo/HelloService.wsdl"
xmlns:tns="http://swenug.com/bpel-demo/HelloService.wsdl"
xmlns:htd="http://swenug.com/bpel-demo/schema"
xmlns:imp="http://swenug.com/bpel-demo/Hello.xsd"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">


Ett WSDL-kontrakt börjar alltid med en typdeklaration.
Här importeras typerna från schemat.


<wsdl:types>
<xsd:schema
targetNamespace="http://swenug.com/bpel-demo/schema"
xmlns:imp="http://swenug.com/bpel-demo/Hello.xsd"
xmlns:htd="http://swenug.com/bpel-demo/schema"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="HelloRequest" type="imp:HelloRequestType"/>
<xsd:element name="HelloResponse" type="imp:HelloResponseType"/>
<xsd:import
namespace="http://swenug.com/bpel-demo/Hello.xsd"
schemaLocation="http://swenug.com/bpel-demo/v.0.2.1/Hello.xsd"/>
</xsd:schema>
</wsdl:types>


Sedan deklareras själva meddelandena som ska användas i operationerna.
Typerna ovan är delar (parts) av ett meddelande.


<wsdl:message name="HelloRequestMessage">
<wsdl:part element="htd:HelloRequest" name="Salut"/>
</wsdl:message>
<wsdl:message name="HelloResponseMessage">
<wsdl:part element="htd:HelloResponse" name="Greeting"/>
</wsdl:message>


I WSDL är PortType som ett Interface är i C# eller Java.
Operation kan liknas vid en metod.


<wsdl:portType name="HelloPortType">
<wsdl:operation name="sayHello">
<wsdl:input message="tns:HelloRequestMessage"/>
<wsdl:output message="tns:HelloResponseMessage"/>
</wsdl:operation>
</wsdl:portType>


Bindningen anger till den fysiska delen av kontraktet,
på vilket sätt som meddelandena ska paketeras när de passerar porten.


<wsdl:binding name="HelloBinding" type="tns:HelloPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="sayHello">
<soap:operation soapAction="urn:Hello#sayHello">
<wsdl:input>
<soap:body parts="Salut" use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body parts="Greeting" use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>


Den här delen av kontraktet binder porttypen/interfacet till en fysisk port.


<wsdl:service name="HelloService">
<wsdl:port binding="tns:HelloBinding" name="HelloPort">
<soap:address location="http://servername/Hello"/>
</wsdl:port>
</wsdl:service>

</wsdl:definitions>



Processen
Det är processen som ska göra jobbet, d v s implementera tjänsten. Innan vi skapar arbetsflödet i BPEL så måste vi ha en länk till kontraktet. Den skapas i en ny WSDL-fil.

HelloPartnerLinks.wsdl


<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
targetNamespace="http://swenug.com/bpel-demo/HelloPartnerLinks.wsdl"
xmlns:tns="http://swenug.com/bpel-demo/HelloPartnerLinks.wsdl"
xmlns:ns="http://swenug.com/bpel-demo/HelloService.wsdl"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">

<wsdl:import namespace="http://swenug.com/bpel-demo/HelloService.wsdl"
location="http://swenug.com/bpel-demo/v.0.2.1/HelloService.wsdl"/>


Här knyter vi ihop BPEL med kontraktet.


<plnk:partnerLinkType name="HelloLink">
<plnk:role name="ServiceProvider">
<plnk:portType name="tns:HelloPortType"/>
</plnk:role>
</plnk:partnerLinkType>

</wsdl:definitions>



Nu är det dags för själv processen att beskrivas i BPEL.

HelloBPEL.bpel


<?xml version="1.0"?>
<bpws:process name="Hello"
targetNamespace="http://swenug.com/bpel-demo/HelloBPEL.bpel"
xmlns:tns="http://swenug.com/bpel-demo/HelloBPEL.bpel"
xmlns:plt="http://swenug.com/bpel-demo/HelloPartnerLinks.wsdl"
xmlns:hs="http://swenug.com/bpel-demo/HelloService.wsdl"
xmlns:htd="http://swenug.com/bpel-demo/schema"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/">


Importera information om länken till kontraktet.


<bpws:import
location="http://swenug.com/bpel-demo/v.0.2.1/HelloPartnerLinks.wsdl"
namespace="http://swenug.com/bpel-demo/HelloPartnerLinks.wsdl"
importType="http://schemas.xmlsoap.org/wsdl/">
</bpws:import>


Nu är det dags att sätta namn på länken till tjänstekontraktet
så det kan användas för åtkomst senare.


<bpws:partnerLinks>
<bpws:partnerLink myRole="ServiceProvider" name="HelloClient"
partnerLinkType="plt:HelloLink">
</bpws:partnerLink>
</bpws:partnerLinks>


Processen behöver definiera variabler. De här två i scopet av hela processen.


<bpws:variables>
<bpws:variable messageType="hs:HelloRequestMessage"
name="HelloRequestMessage" />
<bpws:variable messageType="hs:HelloResponseMessage"
name="HelloResponseMessage" />
</bpws:variables>


Nu till själva flödet.


<bpws:sequence>


Receive är starten på processen som även deklarerar
att en ny instans av arbetsflödet ska skapas.
Varje anrop in som inte görs till en existerande instans,
skapar istället en ny.


<bpws:receive partnerLink="HelloClient" portType="hs:HelloPortType"
operation="sayHello" variable="HelloRequestMessage" createInstance="yes">
</bpws:receive>


Det här är själva logiken bakom tilldelningen av svarsmeddelande.
Här används ett uttryck som hämtar upp namnet ur meddelandet och
bygger upp ett svar.


<bpws:assign>
<bpws:copy>
<bpws:from expression="concat('Hello ',
bpws:getVariableData('HelloRequestMessage',
'Salut', '/htd:HelloRequest') )"></bpws:from>
<bpws:to variable="HelloResponseMessage" part="Greeting"/>
</bpws:copy>
</bpws:assign>


Det sista som behöver göras är att returnera svaret.


<bpws:reply partnerLink="Hello" portType="hs:HelloPortType"
operation="sayHello" variable="HelloResponseMessage">
</bpws:reply>
</bpws:sequence>
</bpws:process>


Vägen till tjänstebaserad arkitektur

En artikel om lite historik i samband med SOA.

Ensam är stark

Microsoft står på sig här och här om definitionen av en ESB. Nu verkar dock Redmond vara nära att bestämma sig för att en ESB kanske ändå är en produkt. Man säger iofs att BizTalk + WCF är en supermängd till ESB och att det bättre matchar kundernas krav. Det är ju sant, om man pratar integrationslösningar. Men roligt tycker jag det är med alla ESB:er som följer nya OASIS och W3C standarder till punkt och pricka för att driva SOA framåt utan att fastna för mycket i vad behoven är just idag. Men MS verkar idag och kommer säkert ha en produkt som matchar en ESB någon dag efter morgondagen.