Never Mind

Vector vs. ArrayList

Matyi — Thu, 01 Apr 2010 15:13:33 +0000

Ki használ manapság Vektort? Szerintem senki. Mégis állásinterviewkon gyakran felteszik a kérdést, hogy mi a különbség a Vektor és az ArrayList között? Erre persze mindenki azt válaszolja, hogy a Vektor az szinkronizált, az ArrayList viszont nem.

Részletesebben: http://geekexplains.blogspot.com/2008/05/difference-between-vector-and-arraylist.html

Csak hogy össze legyen foglalva kicsit:

Vektor:

egy olyan tömb aminek mérete az elemszámtól függően nő/csökken.
Az elemeket indexekkel érjük el.
Az első JDK verzió óta létezik.
Áttervezték, a Java 2 Platformtól implementálja a List Interface-t.
Kiterjeszti az AbstractList class-t. Implementálja a Cloneable, Collection, List, RandomAccess, Serializable interfaceket.
Az vektor iterátora “fail-fast” jellegű: ha a vektor struktúrája változik (bármilyen iterátor biztosította módon kívül), akkor ConcurrentModificationException-t kapunk. (Elbukik és gyorsan, nem valami non-determinisztikus viselkedéssel…)
A vektor enumerátora viszont nem “fail-fast” jellegű.

ArrayList:

Szintén egy átméretezhető 1 dimenziós tömb.
A Java 1.2-es verzióban jelent meg.
Az AbstractList-ből származik. Implementált interface-ek: Cloneable, Collection, List, RandomAccess, Serializable.
n db elem hozzáadása O(n) ideig tart (tehát egy elem hozzáadása konstans idő).
Nem szinkronizált. Ha több szállal szeretnénk használni egyszerre, akkor szinkronizálnunk kell (Ha nem tesszük, könnyen kaphatunk IndexOutOfBoundsException-t).
List synchronizedArrayList = Collections.synchronizedList(new ArrayList(…));
Mivel nem szinkronizált, gyorsabb mint a Vektor.

Concurrency Control – Optimistic vs. Pessimistic lock

Matyi — Thu, 18 Mar 2010 12:54:12 +0000

Az előző poszthoz kerestem dolgokat a neten, és találtam egy nagyon jó kis leírást az optimistic és a pessimistic lock-ról (miközben olvasgattam, eszembe jutott, hogy ez az egyik kedvenc kérdés az állásinterjúkon ). Úgy gondoltam megpróbálom összefoglalni magyarul is a dolgot (az eredeti jobb egyébként).

1. Ütközések (collisions) típusai

A tranzakció izolációs szinteknél már volt szó róluk, ezért csak felsorolnám őket:

Dirty read
Non-repeatable read
Phantom read

2. A lock-olás

A lock más userek/alkalmazások hozzáférését limitálja egy adatbázis entity-hez (rekordhoz, táblához, page-hez, …). Két típusa van:

Write lock: Ebben az esetben a lockoló user vagy alkalmazás szeretné updatelni/törölni az adott entity-t, ezért nem enged read/update/delete hozzáférést senki másnak.
Read lock: Itt a lock holder csak olvassa az adott entity-t, nem fogja módosítani. Ezért mások is olvashatják az adott entity-t, de senki nem updatelheti vagy törölheti azt.

3. Pessimistic lock

Ebben az esetben az entity lockolva lesz egészen addíg, amíg az alkalmazás memóriájában van (általában objektumként). Tehát amikor az alkalmazásnak szüksége van pl.: egy user objectre, akkor az alkalmazás lockolja az adott user rekordját a DB-ben. A lock mindaddig megmarad, amíg a user object az alkalmazás memóriájában van, és az alkalmazás műveleteket végezhet vele. Így nem lehet ütközésünk.

4. Optimistic lock

Az optimistic lock-nál előzetesen azt feltételezzük, hogy nem lesz ütközés. Tehát az alkalmazás beolvassa a memóriába az objectet, de nem lockolja amíg commitolni nem akar. A commit előtt megnézi hogy az adott record változott-e, és ha kiderül hogy igen, tehát ütközés van, akkor ezt a helyzetet a kódban kezelnünk kell (csak logolja, kísérletet tesz az ütközés feloldására, …). Ábra (based on http://www.agiledata.org/essays/concurrencyControl.html):

Alapvetően 2 módszer van az ütközések meghatározására:

Egyedi azonosító: A rekordot egyedi azonosítóval látjuk el – A forrás rekordnak lesz egy egyedi azonosítója, amely minden updatekor változik.
- Timestamp: A DB-nek kell updatelnie, mert mi kódból nem tudjuk megfelelően…
- Incremental counter: Növeljünk egy számot…
- User Id: Ha az ütközések csak különböző userek tranzakcióikor fordulhatnak elő.
- Generated UUID: Minden updatekor új egyedi azonosítót kap.
Összehasonlítós módszer: Újra lekérjük az adott objectet a DB-től és összehasonlítjuk a property-jeit az eredetileg lekérttel.

5. Overly optimistic lock

Abban az esetben ha biztosan tudjuk, hogy soha nem lesznek ütközések (pl mert csak 1 user/alkalmazás használja a DB-t vagy csak olvasható tábláink vannak a DB-ben), akkor egyáltalán nem kell foglalkoznuk sem az ütközések detektálásával sem a kezelésével.

Java – Tranzakció kezelés és tranzakció izolációs szintek

Matyi — Wed, 17 Mar 2010 10:23:12 +0000

1. Tranzakció kezelés

Akkor lehet rá szükség ha több logikailag öszefüggő SQL utasítást szeretnénk egyszerre (közvetlenül egymás után, egy tranzakcióként) végrehajtani. Ezeknek az SQL utasításoknak általában van egy logikai sorrendje. Ha bármelyik SQL utasítás bukik akkor a logikailag ráépülő többi eljárás is bukik. Például:

Több oldalas regisztráció, ahol minden oldalhoz tartozó adat külön SQL utasítással bekerül az adatbázisba. Ha az x. oldal után a felhasználó nyom egy cancel-t, akkor az eddig végrehajtott SQL insert-eket is érvénytelenítenünk kell
Banki tranzakciók – átutalás egy számláról egy másikra, vagy kézpénzfelvét az autómatából: Először megterhelődik az egyik számla a kívánt összeggel, ezután jóváíródik a másik számlán, vagy kiadja az autómata. Ha a második lépés meghiúsul (pl.: Az autómata technikai okok miatt nem tud pénzt kiadni) akkor az első tranzakciót is vissza kell vonni.

Ezekben az esetekben az SQL utasításokat egy tranzakcióban kezeljük. Ez a teljes tranzakció csak akkor hajtódik végre, ha mi erre a programunkból direkt felszólítjuk, egészen addig az adatbázis-kezelő elkülönítve kezeli őket. A tranzakció közben bármikor lehetőség van arra, hogy az addig kiadott SQL utasításokat érvénytelenítsük, ezzel az adatbázis visszaáll az eredeti állapotához.

A tranzakciók kezelésének módját a Connection object-en a setAutoCommit() metódussal tudjuk megváltoztatni:

connection.setAutoCommit(true): Az új adatbázis kapcsolatok esetén ez a default beállítás. Ha az AutoCommit mód be van kapcsolva akkor minden SQL utasítás különálló tranzakcióként lesz kezelve és végrahajtva.

connection.setAutoCommit(false): Ebben az esetben (AutoCommit mód kikapcsolva), az SQL utasítások csoportokba rendezhetőek, és csak akkor hajtódnak végre/fejeződnek be, ha a connection-ön meghívjuk a commit() vagy rollback() metódusokat. A commit() hatására a módosítások véglegesen bekerülnek az adatbázisba, míg a rollback() visszaállítja az adatbázist a tranzakció kezdetekori állapotába.

2. Tranzakció izolációs szintek

Azt határozzák meg, hogy hogyan kezelje a szerver az egyidejű hozzáférési kérelmeket (read, update, insert) ugyanahhoz az objektumhoz (tábla, rekord, …).

TRANSACTION_NONE: A tranzakciók nem támogatottak, nincs tranzakciókezelés.
TRANSACTION_READ_UNCOMMITED: Olvasáskor mindig az aktuális (módosított) értéket kapjuk, még akkor is, ha az adott insert/update tranzakciót a kezdeményező nem commit-olta. A következő problémák léphetnek fel:
- Dirty reads: A kiolvasott rekord változhat más tranzakciók által a mi tranzakciónk ideje alatt. Tehát előfordulhat, hogy a tranzakciónk elején és végén az adott rekordban más értékek szerepelnek, holott mi nem is változtattuk, csak olvastuk…
- Non-repeatable reads: A tábla egy adott sora törlődhet a mi tranzakciónk közben. Így amikor mi a tranzakciónk elején és végén futtatunk egy-egy select-et, akkor a második esetben hiányozhatnak sorok az eredményből.
- Phantom reads: Hasonló az előzőhöz, csak insert-tel. A táblába új sor (fantom sor) kerülhet egy másik tranzakció által miközben a mi tranzakciónk még fut. Így a tranzakciónk végén több sor lesz az adott táblábam, mint amivel számolhattunk az elején…
TRANSACTION_READ_COMMITED: Olvasáskor mindig az adott rekord véglegesített értéket kapjuk. Ez az esetek 99%-ra használható, a tranzakcióink mindig csak olyan rekordokat olvasnak, amik kommittálva vannak, azaz nincs nyitott tranzakció, ami dolgozna rajtuk. A baj ezzel az, hogy ha sokan írják és olvassák az adott rekordot vagy táblát akkor könnyen kialakulhat az a helyzet, hogy az olvasó tranzakciók arra várnak hogy az írás (pl egy nagy tábla update-je) befejeződjön. Ez a főleg a rekordokra vonatkozik így csak a dirty read-től véd, probléma lehet:
- a non-repeatable read
- és a phantom read
TRANSACTION_REPEATABLE_READ: Ez annyival jobb a READ_COMMITTED-nél, hogy már a non-repeatable read hibát is képes kiszűrni a tranzakcióból. Egyszerűbben: csak a recordok commit-olt értékeit használja és a recordok tranzakció közbeni törlése nem befolyásolja a select-eket. Ebben az esetben csak egy probléma marad:
- a phantom read
TRANSACTION_SERIALIZABLE: Annyival több a REPEATABLE_READ-től, hogy más tranzakció nem írhatja felül a mi tranzakciónk által olvasott értékeket, azaz addig várakoztatja azokat míg be nem fejeződik a tranzakciónk. Így nem fognak tranzakció közben fantom sorok keletkezni a táblában. Itt elég problémás lehet, ha több résztvevő folyamatosan olvas egy táblát, amíg az updatelő szál várakozik, mert a tábla lock-olva van és nem tud bele írni…

Ezek szintek föntről lefelé egyre költségesebbek lesznek az adatbázisnak, így a tranzakciók végrehajtási sebessége lassul. Az izolációs szinteket a Connection objektumon a setTransactionIsolation() metódussal állíthatjuk be a tranzakció megkezdése előtt. Például:

con.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);

C# WS Client Generálása (Service Reference solution)

Matyi — Fri, 12 Mar 2010 11:27:22 +0000

Ez az újabb megoldás WS Client készítésére C#-ban. A régi “Web Reference” megoldás megtalálható itt. A .NET 3.0-ás verziójában már Service Reference-eket tudunk hozzáadni a project-hez. A lényeg, hogy itt egyszerűbb lesz a SOAP Header-t módosítani az authentikáció érdekében. Egy nagyon jó leírás a Web reference és a Service Reference közötti különbségről: http://andrewtokeley.net/archive/2008/07/10/the-difference-between-ldquoadd-web-referencerdquo-and-ldquoadd-service-referencerdquo.aspx

1. Készítsünk egy új projectet a Visual Studióban.

Legyen ez egy egyszerű Konzolos alkalmazás:

2. Adjuk hozzá a Service Reference-t a Projectünkhöz:

Ekkor a Solution Explorerben megjelenik a behivatkozott Service.

3. A kliens létrehozása:

Az autómatikusan legenerált Program.cs-t egésszítsük ki a következőképpen:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using ServiceReferenceTest.AtlasServiceReference;
namespace ServiceReferenceTest
{
class Program
{
static void Main(string[] args)
{
ATLASWServicePortClient client = new ATLASWServicePortClient();
AWSProduct[] products = client.findAllProducts();
foreach(AWSProduct product in products) {
Console.Out.WriteLine("-> " + product.wkProductId);
}
Console.In.ReadLine();
}
}
}

Ez csak egy teszt a WS methodok meghívására. Ez így már működne is, ha nem kérne a WS Server SoapHeader authentikációt. Viszont a mi szerverünk a következő formátumú Soap Header-t kér:




WebService_User
WebService_Password
WebService_Group

4. A LoginCredentials class

Csinálnunk kell egy Data class-t a login credentials -hoz. Legyen benne userid, password és groupid property (Ezek szükségesek a header-be). Ez a LoginCredentials class származzon a SoapHeader ősosztályból (Ahhoz, hogy ez így működjön, hozzá kell adnunk a System.Web.Services referenciát). Vigyázni! A LoginCredentials class legyen publikus, különben nem lehet serializálni.


public class LoginCredentials : SoapHeader
{
private string useridField;
...
public LoginCredentials() { }
...
[System.Xml.Serialization.SoapElementAttribute(IsNullable = false)]
public string userid
{
get { return this.useridField; }
set { this.useridField = value; }
}
...
}

5. A “behavior” class

Egy jó leírás a következő linken: http://weblogs.asp.net/jdanforth/archive/2008/10/27/wcf-client-calling-asmx-service-with-soap-headers.aspx.

Kell csinálnunk egy ServiceBehavior classt, amivel manipulálni tudjuk a kimenő SOAP messageket. Ehhez a következők kellenek:

BehaviorExtensionElement: Ezen osztály segítségével tudjuk módosítani a kliens végpont tulajdonságait.
IClientMessageInspector: Messagek módosítására.
IEndpointBehavior: Kiterjeszthető vele a végpont viselkedése.

Példa:


public class SoapHeaderBehaviour : BehaviorExtensionElement, IClientMessageInspector, IEndpointBehavior
{
#region IClientMessageInspector Members
public void AfterReceiveReply(ref Message reply, object correlationState)
{
}
public object BeforeSendRequest(ref Message request, IClientChannel channel)
{
LoginCredentials login = new LoginCredentials("username", "password", "group");
MessageHeader messageHeader = new MessageHeader() { Actor = "Anyone", Content = login };
request.Headers.Add(messageHeader.GetUntypedHeader("LoginCredentials", "atlas"));
return null;
}
#endregion
#region IEndpointBehavior Members
public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters) { }
public void ApplyClientBehavior(ServiceEndpoint serviceEndpoint, ClientRuntime behavior) { behavior.MessageInspectors.Add(this); }
public void ApplyDispatchBehavior(ServiceEndpoint serviceEndpoint, EndpointDispatcher endpointDispatcher) { }
public void Validate(ServiceEndpoint serviceEndpoint) { }
#endregion
#region BehaviorExtensionElement Members
protected override object CreateBehavior() { return new AtlasSoapHeaderBehaviour(); }
public override Type BehaviorType { get { return GetType(); } }
#endregion
}

6. Az app.config: EndPoitBehavior beállítása:

Ha megvan a “behavior” class-unk, akkor már csak be kell állítanunk az app config-ban, hogy az alkalmazás használja is ezt az osztályt:






...














behaviorConfiguration="MyEndpointBehaviors" binding="basicHttpBinding" bindingConfiguration="AWServicePort" contract="ServiceReference.AWServicePort" name="AWServicePort" />

Mostmár futtathatjuk is az alkalmazást. A kliens által elküldött SOAP message-eknek mostmár lesz header-je és a header tartalmazni fogja a credentials-t.

Property validálás Java-ban

Matyi — Wed, 10 Mar 2010 11:16:06 +0000

Az egész ott kezdődött, hogy a Kanadaiak kedvéért kénytelen voltam megnézni hogyan validálja az Amerikaiak indiaiakkal íratott csodarendszere a first/last name property-ket. És kicsit megrémültem:

Rossz példa, ne használd!


private static Vector getFirstLastNameAlphaChars(Vector inputvectors){
for(int i=65; i < 91; i++){
char[] charbuff	= new char[1];
char ch = (char) i;
charbuff[0]	= ch;
String letters = new String(charbuff);
inputvectors.add(letters);
}
for(int i=97; i < 123; i++){
char[] charbuff	= new char[1];
char ch = (char) i;
charbuff[0]	= ch;
String letters = new String(charbuff);
inputvectors.add(letters);
}
String exStr = new String(new char[]{'!'});
inputvectors.add(exStr);
String aposStr = new String(new char[]{'\''});
inputvectors.add(aposStr);
String dotStr = new String(new char[]{'.'});
inputvectors.add(dotStr);
String plusStr = new String(new char[]{'+'});
inputvectors.add(plusStr);
String hypenStr = new String(new char[]{'-'});
inputvectors.add(hypenStr);
String underScoreStr = new String(new char[]{'_'});
inputvectors.add(underScoreStr);
String apos1Str = new String(new char[]{'`'});
inputvectors.add(apos1Str);
String atStr = new String(new char[]{'@'});
inputvectors.add(atStr);
String spaceStr = new String(new char[]{' '});
inputvectors.add(spaceStr);
return inputvectors;
}
public static boolean validateString(String inputString) {
boolean result = true;
Vector allowedchars = getFirstLastNameAlphaChars(new Vector());
allowedchars = getNumericChars(allowedchars);
if(inputString!=null && inputString.trim()!=null)
{
inputString = inputString.trim();
for(int i = 0; i < inputString.length(); i++)
{
char letters 	= inputString.charAt(i);
char[] charbuff	= {letters};
if(!allowedchars.contains(new String(charbuff)))
{
result = false;
break;
}
}
}
return result;
}

Nem is részletezném a hibákat, amik első ránézésre látszanak. Az hogy ez a kód lassú, az egy dolog. De! Ha engedélyezni kellene egy új karaktert, akkor rögtön kód módosítás + új release kell. Ami sok idő.

Aztán felmerült bennem hogyan is kellene ezt megoldani gyorsabban.

1. Property validálás Regexp-pel:

Egy jó leírás a regexpekről: http://www.regular-expressions.info/java.html


public class RegExpValidation {
private static String disabledCharacters = "[^A-Za-z0-9!.+-_'`@ ]+";
private static Pattern pattern = Pattern.compile(disabledCharacters);
private static boolean result = true;
public static boolean validateString(String inputString) {
result = true;
Matcher matcher = pattern.matcher(inputString);
if (matcher.find()) {
result = false;
}
return result;
}
}

2. OVal (Object Validation) Framework:

Nagyon jó kis cucc, a Java objectek property-jeire és a method-ok argumentumaira tudunk annotációkban feltételeket tenni. Itt találhatunk bővebb leírást róla. Csak annyit kell tenni, hogy az OVal jar file-ját felvesszük a projectre. Rögtön két lehetséges megoldást találtam a fenti problémára:

a.) Business Object Property validálása:

Kell egy Business Object, amit annotációkkal preparálunk:


public class BusinessObject {
@MatchPattern(pattern="[A-Za-z0-9!.+-_'`@ ]+")
private String inputString;
public BusinessObject(String inputString) {
this.inputString = inputString;
}
}

Majd amikor ezt létrehozzuk egy másik class-ban, a következő képpen tudjuk validálni:


public boolean validateString(String inputString) {
result = true;
bo = new BusinessObject(inputString);
violations = validator.validate(bo);
if (!violations.isEmpty()) {
result = false;
}
return result;
}

b.) Method Argumentum validálása:

Egy kicsit bonyolultabb a helyzet ha a methodok argumentumait szeretnénk validálni. Ehhez az Eclips-es projectet kicsit preparálnunk kell. Ehhez nem árt elolvasnunk a következő leírást: http://oval.sourceforge.net/userguide.html#d4e183 (Telepítsük az AspectJ plugin-t, Konvertáljuk a projectet AspectJ projectre, hozzunk létre egy új Aspect-et a projecten, amely a net.sf.oval.guard.GuardAspect -ből származik. )

A validálni kívánt methodunk a következőképpen néz ki:


public void validateStringDirectly(@MatchPattern(pattern="[A-Za-z0-9!.+-_'`@ ]+") String inputString) {
}

Ha a project megfelelően van preparálva, akkor ha ezt a method-ot egy invalid (pl.: “ááá”) stringgel hívjuk meg, akkor ConstraintsViolatedException-t fog dobni a method.

3. Statisztikák:

14 db különböző (valid/invalid vegyesen) string-et validáltam mind a 4 megoldással 10.000-szer egymás után. Az idők ms-ben a következők lettek:

Bad Solution: 2000 ms
RegExp validation: 312 ms
OVal property validation: 1844 ms
OVal method argument validation: 1813 ms

Tehát a papírforma bejött. A RegExp a leggyorsabb.

4. Miért lehet mégis jó választás az OVal:

Egy nagyon jó leírás található az OVal használatáról a következő blogon: http://jee-bpel-soa.blogspot.com/2008/12/jsr-303-and-oval-validation-framework.html

A validációs hibákat nagyon jól tudjuk kezelni, mivel minden feltételre különböző error code-okat tudunk definiálni:


@MinLength(value=2, errorCode = "Customer.lastName.error.minLength")
@MaxLength(value=20, errorCode = "Customer.lastName.error.maxLength")
private String lastName;

Természetesen az OVal esetében is van lehetőség kölső XML fileban definiálni a validációs szabályokat, így elég konfigurálhatóvá válik a validálás…

Tárolt eljárás meghívása C# és Java kódból

Matyi — Wed, 03 Mar 2010 16:09:09 +0000

1. Feladat:

Az ügyfél csodálatos alkalmazása Back Office adatok szinkronizálásra biztosít tárolt eljárásokat. (Eredetileg úgy wolt, hogy a WS getter metódusai szarok, hibásak és lassúak voltak. Erre kitalálták, hogy úr isten, itt nagyon nagy mennyiségű adat van, meg hogy milyen nehéz már a WS-t kijavítani, és mennyivel egyszerűbb írni néhány tárolt eljárást. A business unit érje el közvetlenül a DB-t, és hívja meg az erre gyártott tárolt eljárásokat. Advanced Architecture!) A verzióváltás miatt ezeket is le akartam tesztelni. Még a végén nem működik az új rendszeren valamelyik, és a BU jön nekem sírni, hogy de miért…

2. A tárolt eljárás

A tárolt eljárás egy kicsit egyszerűsítve következőképpen van létrehozva:


CREATE PROCEDURE [bosuser].Bos_GetData @RequestType VARCHAR(32), @RequestFlag VARCHAR(5) OUTPUT
AS
BEGIN
DECLARE @xmlOut	XML
IF @RequestType='Accounts'
EXEC Bos_GetAllAccounts @RequestType, @xmlOut OUTPUT, @RequestFlag OUTPUT
ELSE IF @RequestType='Groups'
EXEC Bos_GetAllGroups @RequestType, @xmlOut OUTPUT, @RequestFlag OUTPUT
ELSE IF @RequestType='Users'
EXEC Bos_GetAllUsers @RequestType, @xmlOut OUTPUT, @RequestFlag OUTPUT
ELSE
RAISERROR('Invalid RequestType %s.',16,1,@RequestType)
SELECT @xmlOut AS 'XmlData'
END
GO

Ahogy látható, a tárolt eljárásunk belső tárolt eljárásokat hív meg. A paraméterei:

“RequestType” input paraméter: Melyik belső SP-t hívja meg.
“RequestFlag” in/out paramétere: Pager megoldás. Ha több mint X record van amit vissza kellene adni, akkor visszaadja az első X-et, és a “RequestFlag” false lesz. Ilyenkor akkor újra meg kell hívni az SP-nket az előzőleg használt “RequestType”-pal és erre visszatér a következő X recorddal.
XML visszatérési érték.

3. C# megoldás

Először lefuttattam azt a C# kódot, amit még az előző verzióhoz csináltam a business unitnak. (Igen, kicsit kézi vezérlésűek, meg kell nekik mutatni, hogy hogyan kell csinálni.) A pagerrel (“RequestFlag”) most nem foglalkozunk. Ez a következőképpen néz ki:


string connect = System.Configuration.ConfigurationManager.AppSettings["connection"];
SqlConnection sqlConnection = new SqlConnection(connect);
sqlConnection.Open();
SqlCommand sqlCommand = new SqlCommand("Bos_GetAtlasData", sqlConnection);
sqlCommand.CommandType = CommandType.StoredProcedure;
sqlCommand.Parameters.Add("@RequestType", SqlDbType.VarChar, 32);
sqlCommand.Parameters["@RequestType"].Value = requestType;
sqlCommand.Parameters.Add("@RequestFlag", SqlDbType.VarChar, 5);
sqlCommand.Parameters["@RequestFlag"].Direction = ParameterDirection.Output;
XmlReader xmlReader = sqlCommand.ExecuteXmlReader();
xmlDocument.Load(xmlReader);
xmlReader.Close();
if ("FALSE".Equals(sqlCommand.Parameters["@RequestFlag"].Value.ToString()))
{
// Skip this case
}
sqlConnection.Close();

Ne felejtsük el az App.config-ba betenni a DB connection részleteit:

Ha lefuttatjuk pl.: “Users” requestType-pal, akkor az XmlDocument-ünk tartalmazni fogja a usereket.

4. A Java megoldás

Kis naívan azt hittem, hogy a Connection-ön meghívom a prepareCall() metódust ami ugye létrehozza nekem a CallableStatementet, ezen beállítom a paramétereit, hívok rajta egy execute()-ot, és a ResultSet-ből kiolvasom a végeredményt. Csak hogy ez így nem működik. Futottam vele néhány kört, mire debuggolás közben rájöttem, hogy ha sikerül feltartanom a programot az execute és a ResultSet processzálása között, akkor a ResultSet-ben feltűnik egy “XmlData” property amiben benne van a várt eredmény. Megpróbáltam az MS jdbc drivere helyett a JTDS jdbc drivert is használni, de azzal is hasonló lett az eredmény.

A következző thread segített megérteni mi is a probléma: http://dbaspot.com/forums/ms-sqlserver/223916-problem-boolean-return-parameter-callablestatement-execute.html (Thanks to Joe Weinstein @ BEA Systems).

A mi esetünkben a példa Java kód a következő:


CallableStatement callableStatement = null;
ResultSet resultSet = null;
Connection con = null;
try {
con = getConnection();
String sql = "{call Bos_GetData(?, ?)}";
callableStatement = con.prepareCall(sql);
callableStatement.setString(1, requestType);
callableStatement.registerOutParameter(2, java.sql.Types.VARCHAR);
boolean getResultSetNow = callableStatement.execute();
int updateCount = -1;
DocumentBuilderFactory dbfac = DocumentBuilderFactory.newInstance();
DocumentBuilder docBuilder = dbfac.newDocumentBuilder();
Document doc = null;
while (true) { // handle all in-line results from any procedure
if (getResultSetNow) {
resultSet = callableStatement.getResultSet();
while (resultSet.next()) {
InputStream is = resultSet.getAsciiStream(1);
doc = docBuilder.parse(is);
}
resultSet.close();
} else {
updateCount = callableStatement.getUpdateCount();
// if (updateCount != -1) {
// process update count if desired
// }
}
if ((!getResultSetNow) && (updateCount == -1))
break; // done with loop
getResultSetNow = callableStatement.getMoreResults();
// go to next return if a Callable statement, get any output
// parameters after the loop.
}
boolean hasAllElementRetrived = Boolean.parseBoolean(callableStatement.getString(2));
callableStatement.close();
return new AtlasDataResult(hasAllElementRetrived, doc);
} catch (Exception e) {
log.error(e);
throw new RuntimeException(e);
} finally {
if (con != null) {
try { con.close(); } catch (SQLException e) {
log.error(e); }
}
}

Némi magyarázat: Azért van erre az egészre szükség, mert a tárolt eljárás végrehajtása elég sokáig is eltarthat. A CallableStatement getMoreResults() metódusa true-val tér vissza, ha a következő result egy ResultSet object. Az getUpdateCount() -1 -gyel tér vissza, ha befejeződött a tárolt eljárás. Tehát a kilépési feltételünk: nincs több result (a getMoreResult() false-sal tért vissza), és nincs is több updatelendő sora az SP-nek (a getUpdateCount() -1-et adott.)

A szép az egészben hogy a coding standards alapján ezért a while(true)/break megoldásért minimum nyilvánosan kivégeznének (De ahogy Joe@BEA írja, ez a legjobb kód feldolgozni bármilyen statementet).

WSDL file verziók összehasonlítása

Matyi — Fri, 26 Feb 2010 14:00:42 +0000

Feladat: Hasonlítsam össze mi változott az ügyfél két WS Interface-én a verzióváltás során. Tulajdonképpen a különböző alkalmazás verziók WSDL filejait kellene összediffelni. Mivel a WSDL file-ok rohadt nagyok, ráadásul generáltak, ezért kézzel (WinDiff, AraxisMerge) összehasonlítgatni elég unalmas lett volna. (Az egyik WSDL file-t a build-ben egy ant taskkal generálják axis segítségével, a másikat wiszont a JAX-WS -es wsgen taskkal.)

Mivel ezt minden verzióváltáskor el kell majd játszani (ugyanis a fejlesztők nem szeretnek Release Note-ot/Change Logot írni), igy célszerűnek tűnt írni rá egy kis programot.

Amit össze kell hasonlítani:

Az elérhető függvények listája (van-e új WS method, töröltek-e belőle)
Az egyes függvények paraméterei változtak-e?
Az WS által használt összetett típusok változtak-e?

1. WSDL file szerkezete:

Hivatalos leírás itt.

A számomra lényeges node-ok a WSDL file-ban:

portType node: Az operation-ok listáját tartalmazza.
- operation nodes: A távolról meghívható függvény neve, egy imput és egy output message. (elvileg lehetne több output message is)
message nodes: Absztrakt leírása az infónak ami a kliens és a szerver között utazik. Az “függvények” imput és output üzenetei itt vannak kibontva. Az AXIS-os WSDL esetén itt már egyszrű vagy összetett típusok szerepelnek, míg a JAX-WS es WSDL-ben element hivatkozások a típusokra.
types node: Adat típus definíciók
- complexType node: Az összetett adattípusok definíciója.

2. XPath használata:

Először is kell egy Document (org.w3c.dom.Document) object ami az XML-ünket fogja tartalmazni a memóriában.


DocumentBuilderFactory docBuilderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder docBuilder = null;
try {
docBuilder = docBuilderFactory.newDocumentBuilder();
xmlDocument = docBuilder.parse(ClassLoader.getSystemResourceAsStream(filePath));
} catch (ParserConfigurationException e) {
log.error("ParserConfigurationException ", e);
} catch (FileNotFoundException e) {
log.error("FileNotFoundException ", e);
} catch (SAXException e) {
log.error("SAXException ", e);
} catch (IOException e) {
log.error("IOException ", e);
}

Ezután kell egy XPath (javax.xml.xpath.XPath) object amiben a kereső kifejezést definiáljuk. (Megjegyzés: Az xsd namespace-t azért definiáljuk mert a komplex type-ok ebben a namespace-ben vannak. Ha nem adjuk meg az XPath-nak, nem fogja megtalálni. Bővebb leírás a NamespaceContext-ről itt.)


XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new NamespaceContext() {
@SuppressWarnings("unchecked")
@Override
public Iterator getPrefixes(String namespaceURI) {
return null;
}
@Override
public String getPrefix(String namespaceURI) {
return "xsd";
}
@Override
public String getNamespaceURI(String prefix) {
return "http://www.w3.org/2001/XMLSchema";
}
});

Végül szükség van egy XPathExpression (javax.xml.xpath.XPathExpression) objectre amit az XPath segítségével hozunk létre és kiértékelünk az XML documentünkön:


try {
XPathExpression  expr = xpath.compile("/definitions/portType/operation/@name");
Object exprResult = expr.evaluate(xmlDocument, XPathConstants.NODESET);
} catch (XPathExpressionException e) {
log.error("XPath error!", e);
}
NodeList methodNameNodes = (NodeList) exprResult;

Az XPathExpression evaluate() methodusa egy objecttel tér vissza. Ennek az objectnek a típusát az evaluate method második paraméterében tudjuk meghatározni (boolean, string, nodeset, …). A mi esetünkben ezt símán kasztolhatjuk NodeList-re, amit aztán egy for ciklussal végigjárhatunk.

3. WS Methodok kilistázása a WSDL file-ból:

A fenti példa épp ezt csinálja. A “/definitions/portType/operation/@name” xpath kifejezés kilistázza a wsdl fileból az összes elérhető WS method nevét.

4. WS methodok Input és Output paraméterei

A portType node-on belül a method absztrakt definíciója a következőképpen néz ki:

Itt van leírva, hogy az adott WS method meghívásakor a kliens milyen input messaget küld a szervernek és a szerver milyen output üzenettel válaszol. A konkrét paraméterlista viszont a megfelelő messagek-ben van ledefiniálva (az AXIS esetén), vagy hivatkozva elementként a Type definícióknál (a JAX-WS -es WSDL-nél).

Példa Axis-os message definíció:


type="partns:string" name="string" />


type="partns:string" name="string0" />

Példa JAX-WS message definíció:

Ahol az element a types-on belül van definiálva:


name="authWSReq" type="tp:AuthWSReq" />

Tehát először kikeressük a message nevét a portType/operation-ból, majd ezzel a névvel kikeressük az üzenetet. (JAX-WS-nél az üzenet neve ugyanaz mint az element-é amire az adott message hivatkozik, így a message helyett rögtön kereshetjük az elementet, ezzel egy lépést megspórolva.) Példa egy függvény imput paramétereinek kikeresésére:


private ArrayList getInputParameters(String wsMethodName) {
ArrayList resultInputParameters = null;
String expression = "/definitions/portType/operation[@name='" + wsMethodName + "']/input/@message";
try {
expr = xpath.compile(expression);
exprResult = expr.evaluate(xmlDocument, XPathConstants.NODESET);
} catch (XPathExpressionException e) {
log.error("Can't find input message for this method!", e);
}
NodeList inputParamMessageNames = (NodeList) exprResult;
if (inputParamMessageNames.getLength() > 0) {
// it has only one input message definition under the portType node
String inputParamMessageName = inputParamMessageNames.item(0).getNodeValue();
// cut off the tns: namespace
inputParamMessageName = inputParamMessageName.substring(4);
if (isAxisWSDL) {
expression = "/definitions/message[@name='" + inputParamMessageName + "']/part/@type";
} else {
expression = "/definitions/types/schema/element[@name='" + inputParamMessageName
+ "']/complexType/sequence/element/@type";
}
try {
expr = xpath.compile(expression);
exprResult = expr.evaluate(xmlDocument, XPathConstants.NODESET);
} catch (XPathExpressionException e) {
log.error("Can't find message deffinition for this type!", e);
}
NodeList inputMessageParameterTypes = (NodeList) exprResult;
if (inputMessageParameterTypes.getLength() > 0) {
String paramType = null;
resultInputParameters = new ArrayList();
for (int i = 0; i < inputMessageParameterTypes.getLength(); i++) {
paramType = inputMessageParameterTypes.item(i).getNodeValue();
if (isAxisWSDL) {
// cut off the partns: namespace value
paramType = paramType.substring(7);
} else {
// cut off the "tp:" namespace value
paramType = paramType.substring(3);
}
resultInputParameters.add(paramType);
}
}
}
return resultInputParameters;
}

Megjegyzés: Az, hogy substringgel levágom a namespace-t az egyes attribútumokról, csúnya megoldás. Megfelelően kellene kezelni a namespace-eket. Viszont a célnak éppen pont megfelelt.

5. Complex type-ok összehasonlítása

Az összetett típusok a definitions/types/xsd:schema xml node alatt vannak definiálva. Például:


minOccurs="1" maxOccurs="1" />


minOccurs="1" nillable="true" maxOccurs="1" />


minOccurs="1" nillable="true" maxOccurs="1" />


minOccurs="1" nillable="true" maxOccurs="1" />

Itt 2 dolog fontos:

Változott-e a komplex type-ok listája (jött-e új, vagy töröltek-e meglévőt)?
Az egyes komplex type-ok property-jei változtak-e?

Tehát egyrészt kell az összetett típusok neveinek a listája, amelyet a következő xpath kifejezéssel kérhetünk le:


"/definitions/types/schema/complexType/@name"

Ezen kívül minden egyes komplex típusra meg kell néznünk a property-ket. Először lekérjük a property-k listáját:


String expression = "/definitions/types/schema/complexType[@name='"
+ complexTypeName + "']/sequence/element";
try {
expr = xpath.compile(expression);
exprResult = expr.evaluate(xmlDocument, XPathConstants.NODESET);
} catch (XPathExpressionException e) {
log.error("XPathExpressionException: ", e);
}
NodeList nodes = (NodeList) exprResult;

Majd beolvassuk a property-k tulajdonságait egy általunk definiált osztályba (ParameterObject), hogy később össze tudjuk hasonlítgatni őket:


String name = null;
String type = null;
String minOccurs = null;
String maxOccurs = null;
boolean nillable = false;
for (int i = 0; i < nodes.getLength(); i++) {
name = nodes.item(i).getAttributes().getNamedItem(
PARAMETER_NAME_PROPERTY).getNodeValue();
type = nodes.item(i).getAttributes().getNamedItem(
PARAMETER_TYPE_PROPERTY).getNodeValue();
minOccurs = nodes.item(i).getAttributes().getNamedItem(
PARAMETER_MINOCCURS_PROPERTY).getNodeValue();
maxOccurs = nodes.item(i).getAttributes().getNamedItem(
PARAMETER_MAXOCCURS_PROPERTY).getNodeValue();
if (nodes.item(i).getAttributes().getNamedItem(PARAMETER_NILLABLE_PROPERTY) != null) {
nillable = Boolean.parseBoolean(nodes.item(i).getAttributes().
getNamedItem("nillable").getNodeValue());
}
resultMap.put(name, new ParameterObject(name, type, minOccurs, maxOccurs, nillable));
}

Szinte készen is vagyunk. Már ami a WSDL feldolgozását illeti. Az összehasonlítgatást (method paraméterek, complex type property-k esetén) én az erre definiált osztályok equals() methodjának felüldefiniálásával oldottam meg…

Java és a speciális karakterek

Matyi — Wed, 17 Feb 2010 16:42:24 +0000

Feladat: Kellett tesztelnem az ügyfél csodálatos alkalmazását. A WS API-n keresztül kellett olyan entityket létrehoznom amelyek neve/description-je tartalmazza a következő karaktereket:

“éèùàäëïöüâêîôûçÉÈÙÀÄËÏÖÜÂÊÎÔÛÇ«»”

Leguttattam a tesztet és gyönyörűen működött minden.

Probléma: Egy héttel később fel szerettem volna taggelni a tesztjeimet, így újrafuttattam őket. Közben az eredeti linuxos szerver environment helyett egy windowsosra kellett váltani. A speciális karakteres tesztjeim a következő exceptiont dobták:

Invalid byte 2 of 3-byte UTF-8 sequence

Méghozzá a response SOAP message feldolgozása közben. A Weblogic server logjában semmilyen exception-t nem találtam.

Megoldás:

Amikor a google-lal kerestem a problémára, mindenütt azt olvastam, hogy ilyen hiba XML fileoknál fordul elő, amikor pl.: az XML file enkódolása nem egyezik meg a definícióban szereplővel.

A linux default character encoding-ja UTF-8, míg a windows-é iso-8859-1. Ebből jött az ötlet, hogy az env-en levő Java valószínűleg az Oprendszer default encoding-ját használja… Tehát utánanéztem hogyan tudom átállítani a Java default character encoding-ot.

Kiderült hogy ezt nem lehet System property szinten konfigurálni, csak környezeti változó szintjén. A következő pagen találtam rá a megoldásra: http://stackoverflow.com/questions/361975/setting-the-default-java-character-encoding

Csinálnunk kell egy JAVA_TOOL_OPTIONS környezeti változót. (Leírás a Windows környezeti változókról.) Az értéke ennek a változónak a következő lesz:

-Dfile.encoding=UTF8

(A JAVA_TOOL_OPTIONS környezeti változóról bővebb leírás itt.)

Ezt a környezeti változó a JVM induláskor olvassa fel. Amikor ujraindítottam a Weblogic servert, megjelent a következő sor a logban:

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8

Jó, tehát a Java már UTF-8 char encodinggal megy. Lefuttattam a teszteket és láss csodát, mind működött

Software Requirements – 5. fejezet: Establishing the Product Vision and Project Scope

Matyi — Sat, 06 Feb 2010 21:09:12 +0000

Áttekintés: Ez általában egy Vision and Scope doksiban testesül meg. Ez tartalmazhatja a business requirementeket is (bár általában ezt job külön doksiba kitenni). Ha nincs egy közös kép a software-ről és egy hatáskör definiálva a projectről, akkor a résztvevők soha nem fognak megállapodni a követelményekben. Ezen kívül a Vision and Scope doksi nagyban segítheti a Requirement Change Control Process-t (csak rápillantunk a scope-ra, és könnyebben eldönthetjük, hogy a change in scope vagy out of scope).

A product vízió definiálása Business Requirementeken keresztül

A Product Vision:

közös nevezőre hozza a project résztvevőit
mi a product, és mivé válhat
teljes egésszében tekinti a productot
általában nem vagy lassan változik

A Project Scope Statement:

meghatározza, hogy a hosszú távú product víziónak mely része tartozik az adott projectbe
meghúzza a határokat (mi kerül be az adott projectbe és mi nem)
meghatározza a project limitjeit
a részletei a Requirement Baseline-okban vannak definiálva
sokkal dinamikusabban változhat mint a Product Vision.

Ütköző Business Requirementek

Mivel a követelmények több különböző forrásból származnak így lehetnek köztük ütközőek. A Project Sponsor feladata, hogy feloldja ezeket az alapján, hogy project alapvető céljai szerint mi hordozza a maximális üzleti értéket. Ugyancsak a Sponsor feladata, hogy feloldja a konfliktusokat a project különböző résztvevői között…
Ha a project résztvevői szabadjára vannak engedve, akkor túl sok lesz a követelmény, túl komplikált a rendszer.

Business Requirements and Use Cases

A business requirement-ek meghatározzák:

A business task-okat (Use Cases)
A mélységet vagy szintet, ahol ezek a Use Casek implementálva lesznek (pl.: manuális, automatikus)

(Itt nagyon high level Use Casek-re kell gondolni)…

Vision and Scope Document

Tulajdonosa (irója/szerkesztője) a project szonzor. (Persze Requirement Analyst is dolgozhat rajta). Template:

1. Business Requirements

leirja az előnyöket amiket amiket az új rendszer biztosít. (Projects are launched in the belief that the new product will make the world a better place in some way for someone.)

1.1. Background

általános leírás a helyzetről ami az új projecthez vezetett.

1.2. Business Opportunity

market opportunity, solution for a problem, complete customer solution

1.3. Business Objectives and Success Criteria

Összefoglalja az előnyöket, megszámlálható/mérhető módon.

Pl.: Pénzügyi célok, Nem pénzügyi célok, %-ok, etc.

1.4. Customer or Market Needs

Tipikus ügyfél szükségletei az adott piacon. Kiemelve azok, amelyeket az uj product fog biztosítani.

1.5. Business Risks

Piaci verseny, fejlesztési idő, fogadtatás, fejlesztési problémák, negatív hatások a business-re, kompatibilitás, migráció.

Ezeknek a kockázatoknak a valószínűsége.

2. Vision of the Solution

Strategic vision for the system that will achieve the business objectives.

2.1. Vision Statement

For  [target customer]

Who  statement of the need or opportunity]

The  [product name]

Is  [a product category]

That  [key benefit, compelling reason to buy or use]

Unlike  [primary competitive alternative, current system, or current business process],

Our product  [statement of primary differentiation and advantages of new product].

2.2. Major features

hangsúlyozni azokat, amik megkülönböztetik a versenytársaktól/legacy producttól.

2.3. Assumptions and Dependencies

A résztvevők feltevéseit rögzíteni, hogy a többi project member is át tudja nézni.

Rögzíteni a külső függőségeket amik befolyásolhatják a project időtartamát, stb.

3. Scope and limitations

“The System is and what is not.”

Definiálja az elképzelést és a tervezett megoldásokat.

A limitek meghatározzák, hogy mikre nem lesz képes a rendszer.

3.1. Scope of the Initial Release

Major feature set of the initial release.

Koncentráljunk azokra a feature-ökre amelyektől a legnagyobb business value-t remélünk.

3.2. Scope of the Subsequent Releases

Mint az initial release-nél. De hangsűlyosabb a timing.

3.3. imitations and Exclusions

A határvonal definiálása – mi esik kívül az adott producton.

A kizárt feature-ok, amelyek nem lesznek megvalósítva.

4. Business Context

Business Issues

Project résztvevő kategóriák

Management hierarchy

4.1. Stakeholder Profiles

Stakeholders are the individuals, groups, or organizations who are actively involved in a project, are affected by its outcome, or are able to influence its outcome

Szerintem itt lehetne definiálgatni az egyes projectek vezetőit, a CCB tagjait, a project sponsorokat, stb.

4.2. Project Priorities

A hatékony döntéshozáshoz a project résztvevőinek meg kell egyezniük a prioritásokban.

A software project 5 dimenziója:

features

quality

schedule

cost

staff

Mindegyikhez kell egy értéket rendelni a következőkből:

constraint (show stopper)

driver (must have)

degree of freedom (nice to have)

A project manager dolga, hogy meghatározza prioritásokat. Nem lehet minden constraint of driver, kell egy bizonyos fokú szabadság a projecthez…

4.3. Operating environment

availability, reliability, performance and integrity requirements

Defining System Architecture.

A kontextus diagram

A Scope leírja a határokat és kapcsolatokat a fejlesztett rendszer és a külvilág között (Külső rendszerek, End Userek, stb.). A kontextus diagram ugyanezt teszi grafikusan. Ez a legmagasabb szintű folyamatábra a productról. Példa a könyvből: (nekem nem igazán tetszik…)

A lényeg az átláthatóság. Így könnyebb tisztázni a project részleteit a project résztvevői között.

Tartsuk a Scope-ot fókuszban!

Új requirementek esetén mindig ellenőrizzük, hogy ez belül van-e az eredeti Scope-on. A scope módosítható, de csak nagyon indokolt esetben. Amennyiben a scope módosul, általában a project egyéb tényezőinek is módosítanunk kell (pl.: schedule vagy resourcing).

Web Service Error – Permission issue

Matyi — Sat, 19 Dec 2009 21:24:22 +0000

Tanulság: Ha linuxon fut az appserver/webserver akkor a bug keresése közben sose felejtsük ki a jogosultságokból adódó problémákat.

A sztori:

Résztvevők: Ubuntu Linux, Weblogic AppServer, Apache Weblogic plugin, és a csodálatos alkalmazásunk egy generált Web Service interface-szel.

A Probléma: Application maintanance és partial upgrade után az ügyfél Web Service Kliense a createProduct(Product product) WS methoddal nem működött. A findAllProduct() -tal viszont igen. A hibaüzenet a következő volt:

The remote server returned an unexpected response:
     (400) Bad Request. --->  System.Net.WebException:
     The remote server returned an error: (400) Bad Request..

1. Tesztelés saját klienssel: Kipróbáltam saját C# WS klienssel, és minden WS method tökéletesen működött. A saját és a kliens environmentjén egyaránt. Megírtam nekik, hogy frissítsék a WSDL file-t, generálják újra a WS Kliens Stub-ot, és próbálják újra.

2. Újrapróbálták. Nem ment.

3. Csináltam nekik példaprojectet. Ők visszaküldték az ő példájukat, ami tényleg nem működött. De csak a kliens environmentjén nem működött.

Az én C# kliensem a régi módszerrel Web Referenciaként importálta a WSDL file-t, míg az övéké Service Reference-ként. Egy ideig azt hittem, hogy a Service reference megvalósítás a hibás. De a mi env-ünkön ment…

4. Hozzáfogtam összehasonlítani a mi rendszerünket az ügyfélével. Minden tökéletesnek tűnt. A generált WSDL file megegyezett. A domain logig nem jutott el a kérés… Közben kiderült, hogy csak a paraméteres függvényhívások buknak el. Az Apache access logjában a következőt találtam:

Invalid URI in request (- SOAP message -)
                     GET /bridge_error.html HTTP/1.1

Ez még ok, mert nincs bridge_error.html bekonfigurálva. De mitől jön bridge error?

5. Az Apache Weblogic pluginon bekonfigoltuk a logozást. Ebből az derült ki, hogy “/tmp/_wl_proxy/”-ban lévő temp file-t nem tudja írni az apache mert nincs hozzá jogosultsága, ezért bukik el a request.

- Going to get the post data of size=2419 clength=0
- getWLFilePath: Complete File name =
               [/tmp/_wl_proxy/_post_9929_0]
- Cannot open TEMP post file '/tmp/_wl_proxy/_post_9929_0'
               for POST of 2419 bytes
- Redirecting the error response to the errorPage =
               [/bridge_error.html]
- IO error reading client POST data; sys err#:
               [13] sys err msg [Permission denied]

Az ok: Amikor az ügyfél rendszergazdája karbantarotta a servert, létrehozott egy új usert/groupot az Apache server futtatásához. Mivel az Apache ezzel az új userrel futott, az előzőleg létrehozott “_wl_proxy” könyvtárhoz nem volt hozzáférése. A POST HTTP requestek esetén az Apache proxy temp fileba menti a paramétereket, amiket jelen esetben nem tudott lementeni.

- Az ügyfél C# kliensével (Service Reference based) a paraméter nélküli függvényhívások azért működtek, mert nem kellett az Apache-nak semmit lementenie.

- Az én C# kliensemmel (Web Reference based) azért működött, mert az GET HTTP requesteket használt…

Megoldás: Rendszergazdaként töröltük a “_wl_proxy” mappát. A következő paraméteres HTTP POST requestnél az Apache újrakreálta ezt a mappát, és ezek után minden tökéletesen működött.